Doing Agile

I am a proponent of Agile methodologies. I start all projects with a process that is basically Extreme Programming. I’m not dogmatic about that process; I just think it’s a good starting point to rapidly get started on a project and explore its constraints.

The goal of using any methodology or process (not just Agile ones) is to produce some kind of outcome. Teams typically want to move faster or ship fewer defects or generally be more effective. Agile processes include a mechanism for evaluating the effectiveness of the process and adjusting it to fit the needs of the team and organization.

It’s important to keep this perspective: processes are tools for achieving outcomes, not ends in themselves. That’s partly why I really appreciate the Agile Fluency® Model; it seeks to provide a framework for evaluating the effectiveness of an Agile process in order to determine where effort should be spent to get more of it.

The other day I encountered a conversation between two people who were discussing the software development processes at a company that one of them worked at. As they discussed the process, it was remarked that neither of them had ever encountered an organization that did “Agile by the book”.

This got me thinking; what is “doing Agile by the book”?

The Agile Manifesto is a short document that encodes a set of value judgements. It is credited with popularizing Agile software development and is the most widely accepted description of Agile software development.

The manifesto was written by a group of software development practitioners who sought to encode some fundamental ideas about what their preferred methodologies had in common. At a ski resort in Utah in 2001, they produced the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Beyond this statement, there are twelve principles which extend these values into more concrete statements. The principles are as follows:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Here we have something actionable that you could call “doing Agile”. The principles roughly fit all the Agile methodologies like XP, Scrum, and Kanban. They’re not specific about any particular technical practices (like TDD or CI), but instead focus on priorities, communication, and iteration.

Rather than talking about “doing Agile”, I use the term “Agile” as a descriptor to mean, “in line with the Agile Manifesto’s value judgements”. Almost all teams I encounter do something that is, broadly speaking, Agile.

If your organization isn’t getting the expected value out of its process and you feel like you aren’t “doing Agile” correctly, take a look at the details of your process. The twelve principles from the Agile Manifesto and frameworks like the Agile Fluency® Model give you the vocabulary to evaluate your current processes and explore where it can be improved.

We’re all here to create software as effectively as we reasonably* can. Whether what you’re doing fits a particular label isn’t the conversation to have. Instead lets talk about outcomes and how we might improve them.