The Zen of Agile Product Development
One of the phrases that Enthiosys consultants use is “The Zen of Agile”. Although the meaning of Zen is associated with Buddhism, we don’t mean this to mean someone who has become a “religious” convert or zealot for Agile Product Development. Instead, we mean it to mean someone who comes to understand the deeper meaning of Agile and the principles that drive Agile through their own direct experience.
This distinction is important as it helps to get past the trivial questions Enthiosys consultants often get when we’re helping product teams adopt agile practices. One such trivial question deals with the kind and level of documentation needed for a successful Agile project. The proper answer, whether you’re a consultant or not, is “it depends”. Embracing that this is the proper answer is part of the Zen of Agile.
Consider this question in the context of one of the most discussed documents associated with product development: The Market Requirements Document, or MRD. (Lots of people are discussing the pros/cons of MRDs, and the role of MRDs in Agile Product Development; a few include Roger Cauvin and Tyner Blain).
A simplistic, Waterfall-influenced development process simply mandates that you create MRDs for every project/release, and, more than likely, similarly mandates that you follow a rigid format. An Agile process, on the other hand, would state you create an MRD when needed, and include the information required to answer the questions and/or document the problems that your team needs to address.
But getting there in one step is really hard for teams that haven’t got any experience with Agile. A better result is achieved when teams come to this realization through their own experience and then, through the Zen of Agile, decide what to do about this.
To illustrate this concept I’ll use a story from a client team that is well along the path of getting the Zen of Agile. This team was in the process of trying to reconcile the tension of their traditional “You must build an MRD for every release” (Waterfall-centric development with their new experience of Agile development (“We value working software over comprehensive documentation”). In a shared meeting, they rather quickly realized that they don’t always need an MRD. They sometimes need an MRD. And they had pretty good ideas on knowing when they did, and didn’t, need an MRD.
Funny thing, though. This team was composed of smart, experienced, and hard-working people. They already knew that they don’t always need an MRD. But, they were working in a system that didn’t really allow for them to act on this knowledge.
The Zen of Agile—their direct experience with Agile—allowed them to embrace this idea by simply stating that they, as a team, will decide when they need an MRD, and that they will trust their shared social processes to ensure that no one person can avoid creating an MRD when one is needed or force one as a process step when one isn’t. And yes, they even created a process for dealing with the inevitable “we’re not sure if an MRD is needed” by creating a time-boxed\ inquiry process for handling such situations.
The results include better MRDs when they are needed, and faster, more agile development when they’re not. This is a powerful expression of the Zen of Agile
Special thanks to Peter, a client who inspired this post, and who has indeed acquired the Zen of Agile.
