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:
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.
*The word “reasonably” is doing a lot of work here.
Published November 23, 2021