On the one hand, Agile is based around inspection and adaptation. It acknowledges that every company, product and team is unique, and that to achieve high efficiency we have to fine-tune our methodology to our particular context.
On the other hand, some Agile frameworks may seem very prescriptive at first. Scrum, for example, defines what meetings should be run, how often, what’s their maximum duration and so on.
Is it contradictory? How should we adopt Agile: by the book, or through experimentation?
Two paths to successful Agile implementation
I see two main ways to implement Agile. Both can possibly work, but they are associated with different trade-offs.
Implement a framework by the book, then start to adapt
The first way is revolutionary. Implement all the artifacts and ceremonies a framework prescribes from the get go – potentially changing a lot of existing procedures in the process.
Such a change can be very disruptive and result in a lot of resistance, thus it may be hard to implement. On the other hand, it may work quite well even if only a few people in an organization understand Agile principles in depth. It also makes possible learning Agile principles during, or even late in, the implementation process.
Only after you achieve full, almost by the book implementation of a framework, and understand how all its parts work together, you start to adapt it to your unique context.
Gradually adapt your current process, without implementing a framework
The second way is evolutionary. You start with your current process and gradually adapt it, in small steps.
The big benefit of such an approach is that it’s not disruptive. Change is slow and smooth. The drawback is that there are no prescriptions, so reaching similar point as in the case of a revolutionary change requires a lot of time and deep knowledge of Agile principles.
Of course, there is no end state – the process is adapted infinitely.
Two paths to failure
I also see two common approaches to implementing Agile that usually fail.
Implement a framework by the book, but never adapt
This is a common symptom of Agile adoption forced “from the top”. Our goal is to implement a framework, so we blindly introduce all the ceremonies and artifacts, but when they are in place, we’re “done”. The project is finished and we don’t feel the need to introduce any further improvements.
If the Agile process stagnates at some point and stops being further fine-tuned, it is a clear sign that you don’t really understand Agile principles. It will lead to a cargo cult implementation that will induce all the costs of using Agile without almost any benefits.
Implement only easy parts of a framework, because other “don’t fit our unique context”
Another common syndrome is to say that we’re implementing an Agile framework, but to cherry-pick only some of its elements. The rest gets discarded with an argumentation that the primary Agile principle is adaptation, and that by discarding them we’re adapting the framework to our unique context.
Personally, I’m very opinionated about this: Yes, adaptation lies at the heart of Agile. And yes, you should never stop to fine-tune your process to your particular (and constantly changing!) context. But let me state this clearly: making software for telecom switches is a unique context; working in the computer games industry is a unique context; but “we can’t cut out a vertical slice of a requirement” or “our business analysts, developers and QAs don’t talk to each other” is NOT a unique context. It’s the lack of skill, which should be learned.
Frameworks are designed as a coherent whole. By adapting a framework to our lack of skill, we lose all of the benefits and opportunities for learning it provides.
How did you implement Agile in your organization? Are you still adapting? Please leave a comment and share your opinion!