This article examines the Agile myth that constant process improvement is imperative. It discusses the fact that if you need to continuously observe your process, you should wait for the pauses between iteration to perform process improvement.
Paul Raymond, Inflectra Corporation, http://www.inflectra.com/
In days gone by, when projects were slow, lumbering proceedings, process improvement could only be implemented once a project was finished. Trying to evolve a methodology midstream was too disruptive because processes were overly complex, excessively detailed and heavily documented. In theory, following the process was mandatory but, rules don’t always work in practice and so people found alternative ways to do their jobs regardless. These many undocumented variations to the formal process, employed just to get the job done, further complicated any attempts at process improvement. Projects succeeded (or frequently did not) despite process, not because of it.
Iterative Development, Iterative Improvement
Agile development methods almost always involve some form of iterative development which provides an ideal opportunity for process improvement. Iterations are self-contained so that rules applied in one cycle do not have to be the same as the rules used in the next. At the beginning of each iteration, a new set of requirements or user stories will be selected and the cycle begins again, but before this happens, work pauses, just momentarily, creating the perfect opportunity for change.
Process improvement requires an understanding of what is, and is not, working well. This can be deduced formally through measurement or informally through observation and anecdotal evidence. From this data, changes are made to working practices. In some methodologies this is called a feedback loop or retrospective. There are numerous documented techniques for these procedures but it not our intention to explore them here in this article.
Improving Reviews
Without examining the various feedback loops themselves, it is worth mentioning a couple of principles that make them more valuable. The effectiveness of process improvement can be enhanced if you:
* Focus on just a few changes in each review,
* Consider what works well, not just what works poorly,
* Provide true measurement during each iteration because gut feel is sometimes wrong,
* Keep review meetings light and informal using traditional agile tools such as sticky notes and index cards for suggestions,
* Encourage every team member to propose improvements because ideas can come from anywhere, and
* Vary the retrospective method used to keep it interesting and prevent the activity becoming rote.
As we said, process improvement in Agile projects should only be attempted between iterations; it is very risky to make changes mid-iteration. While change during a traditional project can be disruptive, those projects are usually long enough that delays can be made up. Agile iterations however, are very short so that disruptions during an iteration can easily lead to failure to complete that cycle on time.
So, perhaps it is playing with words, but constant process improvement is unsettling; it is a bad idea. What should be constant is the measurement and observation that feeds into the reviews without which, change would be for change’s sake, not for any expected gain in efficiency or likelihood of success. Constant change is a myth, constant scrutiny is not.
About the Author
Paul Raymond is a successful software program manager with Inflectra Corporation. He has extensive experience working with requirements management systems, including DOORS from Telelogic and SpiraTeam from Inflectra. Paul has helped customers in multiple industries take control of their requirements and develop actionable plans for the delivery of software projects on-time and on-budget. This article was originally published on http://www.inflectra.com/Ideas/Entry/236.aspx and is reproduced with permission from Inflectra.