November 12th, 2014 by inflectra
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.
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.
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:
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.