This past Thursday marked the 20th anniversary of the Agile Manifesto. And yet, 20 years later, there still seems to be a lot of confusion around what exactly it means to be “Agile.” Plainly speaking, Agile is defined by 4 values and 12 principles. How you align with those 4 values and 12 principles, however, is (intentionally) open-ended.
One would think that the implementation of Agile might be where the confusion lies. And indeed, in many cases that’s true. The lack of a prescriptive dogmatic process can and does create confusion. But in some cases, the confusion is even more foundational - it’s a disagreement on the very definition of Agile. I’ve even witnessed one executive go as far as to say “Agile is whatever I say it is.” That’s no more true than O’Brien’s claim that 2+2=5 in Orwell’s novel, 1984.
So, let’s be clear. Agile is defined by 4 values and 12 principles. How you align with those 4 values and 12 principles can be subjective. However, embracing the 4 values and 12 principles of Agile means making a concious decision to be Agile. Similarly, discarding them means making a conscious decision to NOT be Agile.
How Do You Do "Agile?"
They can copy our process, but they cannot copy our culture.
- Taiichi Ohno
In Beyond The Phoenix Project, Gene Kim and John Willis discuss Taiichi Ohno’s decision to allow US automakers to tour the Toyota Production System (TPS). Ohno was questioned by some of his colleagues about why he let the competition view their manufacturing process. To which Ohno responded, They can copy our process, but they cannot copy our culture.
Why is that relevant? Aside from it coming from Ohno, who was a huge influence for Lean, ToC and Agile, it speaks to the heart of what Agile is. It’s not a process; it’s a culture bound together by a commonly held set of values and principles. Oh sure, there are Agile methodologies that can help align the “how” to the “what.” But any process agreed upon by Agile teams is there to support alignment with the Agile principles and values.
As a side note, when TPS was published, Hitachi attempted to copy the process. However, while Toyota was incredibly successful using TPS, Hitachi failed with their implementation of TPS. This speaks not only to process specialization, but also as Ohno said, to “culture.”
When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained.
Several posts could be easily written on different Agile methodologies: Scrum, Kanban, etc. In effect, Agile methodologies are templates for teams to help align how they work with the principles and values of Agile. If that seems a little ambiguous, it is intentionally so. Different methodologies may work better for different teams in different environments. Finding out how to work together, establishing a team culture and empowering teams and team members to make decisions about how they work are all part of Agile.
A methodology can help accelerate a team’s Agile journey right out of the gate by establishing a reference point, and an agreed upon process for working together. However, that process, and those rules are subject to change as discussed in the 12th principle of Agile: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile at Scale
There are several frameworks that attempt to address the issues faced when trying to scale Agile across multiple teams: SAFe, Spotify, Less, etc. There are many who see value in the alignment provided by scaled Agile frameworks. And there are others who feel that scaled Agile frameworks are inherently anti-Agile as they feed the Agile Industrial Complex and invert the first value of Agile: Individuals and interactions over process and tools.
This post will not make a case for or against scaled Agile frameworks, nor will it take an opinion for or against any individual scaled Agile framework. It is, however, important to note the existence of scaled Agile frameworks since they are becoming increasingly prevalent.
An alternative to scaled Agile frameworks is discussed in the white paper Agile Doesn’t Scale-It Multiplies.
Are You Doing Agile Right?
Right and wrong are themselves dogmatic terms, which really don’t compliment Agile well. With that being said, as Ron Jeffries put it, Agile ideas can be implemented poorly to the detriment of progress. So, how do you know if you are implementing Agile ideas poorly or not?
Here are some suggestions.
- Write down the goals of the organization, the team, and the needs of its members as a working agreement.
- Benchmark all processes against the working agreement (1), and the 4 values and 12 principles of Agile.
- Regularly solicit feedback w/actionable results - and hold each other accountable at all levels.
Some organizations move faster than others. Some organizations measure their progress better than others. Perfection is not and should never be the goal; continuous improvement should be. And that can only happen when every person in the organization agrees on the same values, principles and goals and when everyone works toward upholding them. It’s not enough to say the words. The actions of the organization and of the individuals within it must reflect them.
If as a team and as an organization, you can do that, then you are moving in the right direction.
Agile is defined by 4 values and 12 principles. They are essentially the axioms of Agile. Much like a mathematician must accept mathematical axioms as foundational, so must Agile practitioners accept the defining values and principles of Agile. Of course, you could always decide to set aside some or all of them. But in that case, you wouldn’t really be practicing Agile. You would be practicing something else and calling it “Agile.”
The defining values and principles of Agile are intentionally non-prescriptive. Agile isn’t a process. It’s a shared understanding that guides how teams and individuals work together for the purpose of consistently producing working software. The specific implementation is left to the organizations, teams and individuals who practice Agile. And to that end, an established Agile methodology can provide some great direction.