Today it is time to dig into the calculations of flow for sprints made in Agile development.
As we stated in earlier blog posts, Value Stream Mapping, VSM, measures the Flow Efficiency by looking on the Critical Path for a value stream. The Critical Path has been generated transdisciplinary and iteratively with the project team and its sub-teams, common experts, stakeholders, centralised resources etc., i.e. taking also resource constraints for the total organisation into account.
Of course, VSM can be done on any value flow, but the whole idea with achieving a high Flow Efficiency, is to reduce the lead time, which means that we always need to concentrate on the current Critical Path. And if we can remove waste on the current Critical Path, maybe other activities will form the new Critical Path.
And once again, remember that all efficiency work in knowledge work areas, has a very high risk of sub-optimisation, when we look at parts of our organisation, like a single team.
Karen Martin, at The Karen Martin Group, Inc [1], is a prominent VSM expert, and has written many books about VSM, where she is concentrating on service and office. She makes the following distinction between different activities within a value flow and the resulting calculations with the terms:
- PT for Process Time, the time the process needs to refine the product
- LT for Lead Time, which is the waiting time plus the PT for a process
- Total PT, which is the total process time for the value flow/Critical Path analysed
- Total LT, which is the total lead time for the value flow/Critical Path analysed
- AR for Activity Ratio, the Flow Efficiency, for the value flow/Critical Path analysed; Total PT/Total LT
In VSM, the formula for Flow Efficiency (AR) calculations on the value stream/Critical Path look like this:
Flow Efficiency = Total PT on Critical Path/Total LT on Critical Path
A normal value for AR in production/service/office is about 1-10% flow efficiency Karen states, normally depending on waiting times between the processes. But, if the team members continuously work on the activities in the processes, the team is still efficiently used. Here is an example of this.
The actual work adds up to 240 minutes and the waiting time is 8 days. The Activity Ratio, Flow Efficiency is AR = 240 min/(240 min + 8 days) = 2%. And if the processes’ work is efficient, the team members maybe only have ten minutes inactivity, which means they have been highly efficient*.
2% seems like a very bad Flow Efficiency. But, if the Flow Efficiency in this case is not critical, 2% is not a problem, if the resources instead are used efficiently, which they are in the above example. And remember our earlier blog post about Overlapping Concurrent Sequences/Disciplines, which still gives a continuous output that many times are preferred by subsequent team(s). But, if everything over 240 minutes lead time is critical, then 2% Flow Efficiency of course is a huge problem, even though the resources are used efficiently. So, as always, it depends on the context.
Time critical or not is utterly important to understand. If high Flow Efficiency is important, then we concentrate on the Critical Path to the next Integration Event, and try to remove waste and make the Critical Path shorter. If high Flow Efficiency is not important, we are satisfied with the size of the current time box and instead concentrate on efficient use of our team members.
The statement above is valid for whatever a company is doing; production, service or products, and does not change depending on the way of working; Agile, Lean Product Development, waterfall, etc.
How about calculations of flow in the value stream for Agile development? This is an interesting question, since many times when transforming to Agile software development, the different values streams within the company are the first thing to look for. If the company has not done VSM before, it can really be an eye-opener, according to above example, with the waiting times painfully visible. At the same time as the company tries to reduce the waiting times, also the processes are examined for waste reduction. For a traditional waterfall project, the same would be done on the time plan and all the activities, usually divided into swim lanes per function/phase. But, there is one interesting part with Agile software development and frameworks using Agile software development, and it is that the Agile team or team of teams are never part of the continued search for waste to remove when using VSM. How come? We need of course to elaborate on this.
We say that an Agile team has a 2-weeks sprint. The team members agree about how much work they can fit in the sprint. If they do the work successfully with accomplishing what they have promised within the sprint, and no resources had any waiting time and they did not encounter any big problems, it means that their planning was good as well. For me as a technical project leader, sub-project leader, project leader, program leader for traditional waterfall projects, Agile projects and Lean Product Development projects and combinations of them, for the last two decades, I would say to the team; “Great work everybody, the total promised scope has been done, with only small problems that were easily solved! 100% Flow efficiency and 100% Resource efficiency**. Fantastic! In your evaluation of this sprint, please let me know if there were some problems, that I can help you out with to make your work even better.”
And this went well not only for one team, it went well for all the teams in this Program, all 10 teams made a fantastic work in this sprint. I am thrilled.
But, this is the first time we have introduced Agile development’s calculation of flow, or Process Cycle Efficiency as it sometimes is called, which has the following formula [2]:
Process Cycle Efficiency = Value Added Time / Total Lead time
The teams make their respective calculation and the results for the sprints varies, but are only 10-20%.
The teams are devastated.
The formulas above are confusingly alike. But, are they really meaning the same thing? Let us find out what in next blog post. C u then.
*Remember that our term Resource efficiency means how efficiently the resources are used, not just that they are used.
**But, in project work as we stated in this earlier blog post, there is always Project Administration waste that can be something about 20%.
References
[1] Martin, Karen at Karen Martin Group, Inc. Link copied 2018-10-04.
https://www.youtube.com/watch?v=5YJYMLaV9Uw
[2] Sutherland, Jeff, et al. “Process Efficiency – Adapting Flow to the Agile Improvement Effort” . Link copied 2018-10-14.
https://www.researchgate.net/publication/327821851_Process_Efficiency_-_Adapting_Flow_to_the_Agile_Improvement_Effort