If you have a look around at job postings for software engineering roles, after glossing over all the terms like “ninja rockstar developer” you’ll find nearly every job listing details a desirable skill that looks like “Familiarity with Agile software development methods and working as part of an Agile Team”.
Recently, I’ve had the pleasure of interviewing a few software engineers for roles at Capital One. In a similar way to how nearly every job advert says ‘agile’ on it somewhere, every CV that has come across my desk mentions how familiar with agile methodologies they are. I tend to run a code pairing interview, so I don’t really get to quiz the candidate on these things, but it made me wonder how much we really know about ‘agile’. I’ve been working in teams claiming to be agile, working using kanban or scrum to manage our work, but is that all there is to it? Is all the fuss that we need to work in sprints, do standups, retros, refinement and do some planning every now and then? I’ve picked this up mostly from being part of these teams, but I guess that’s not all there is to it.
So, I reviewed the agile manifesto; and there are twelve principles and four values that are the core of what we should mean by agile. I think before we claim to be agile, or work in agile teams, we should take a good look at those values and principles, and understand them. I don’t claim myself to be the fount of agile knowledge, but if we are going to talk about it we need to be familiar with what it actually is!
The four values from the agile manifesto
1. Individuals and Interactions Over Processes and Tools
People respond directly to business needs, tools and processes are less responsive. Communication is often cited as a good example, as people generally communicate as and when necessary. If we were to wrap this up in a process where communication is scheduled, requires planning in, and requires specific content then the value is drastically reduced. Counter to how some people may view agile methodologies, being agile isn’t about creating lots of meetings and striking the right balance is important. Whilst we value process and tools, we value individuals and interactions more.
2. Working Software Over Comprehensive Documentation
The agile manifesto values comprehensive documentation, but it values working software more. A software development team’s focus should be on making working software. Writing comprehensive documentation for a system, particularly upfront often leads to rigidity when considering change. It gets in the way of being able to pivot, as large amounts of documentation requires maintaining. As someone on my team regularly points out, the agile manifesto doesn’t say no documentation. There is value in documentation (Particularly when you have consumers of your work!), but we value working software more.
3. Customer Collaboration Over Contract Negotiation
Contract negotiation straight away rings bells of big design documents up front which will inevitably make assumptions about a product or end goal, these assumptions regularly end up being wrong. Contract negotiation involves setting period s of time where a product manager or consumer can work out the details of what will be delivered. Collaboration is entirely different, it involves working together with product owners and stakeholders and engaging them in the process. It makes it far more likely that the end product will be what the end user actually wanted at the end of the project (Rather than what they said they maybe wanted at the start of the project).
4. Responding to Change Over Following a Plan
When we plan everything up front, create large amounts of documents and get everything approved and signed off by every stakeholder and their dog, we end up with a project designed by committee and becomes very difficult to change. We do have a plan, and perhaps sometimes we might find halfway through that we might be better doing things in a different order, or perhaps altering some bits. What a pain that can be. Oh, if you want to change that then it’ll need approving by x, y and z again and we’ll have to re-draw up the estimated timeline to keep the product owners happy. That small change which was meant to be an improvement suddenly becomes more costly than it’s worth, and subsequently won’t happen. Instead, the agile manifesto rates change over following a plan. It recognises that change is positive (If it’s not, what are we suggesting changing?).
The twelve principles from the agile manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The 17 Manifesto Authors
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- Robert C. Martin
- Steve Mellor
- Dave Thomas
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Ken Schwaber
- Jeff Sutherland