Measuring the flow

An Agile team’s focus on delivering software means that retro meetings are vital in highlighting possible improvements to the delivery process. Retrospectives can take two forms where nearly everyone has an opinion and it results in lots of potential ideas and action points for the next week. On the other hand they become very mountainous and uninspiring. The net result is despite changes in process it is difficult to put your finger on the improvements made.
Just like any self respecting marketing guru wouldn’t dare claim to have been a success without the sales figures to back it up, the improvements or lack thereof to an Agile team should be measured in a similar quantifiable manner.

Cumulative flow diagrams are probably the best way to measure deliver-ability of an Agile team , visualising your cycle time gives clear indications of bottle necks and the like. Cumulative flow can also highlight if particular stories (work items) are taking a lot longer to complete than they should. This will of course initially raise more questions than answers as to why. However through tweaking not only the development and testing of items but also their planning and scope real improvements to delivery can be made.

There are many great resources for Kanban, Scrum and the use of Cumulative flow on the internet. The key thing to remember is to always measure in quantifiable terms no matter how you do it. Like anything in life stubbornly sticking to the old way of doing things is just as dangerous as changing process haphazardly just for the sake of it.