Give them Credit?
In his recent post "Retrospectives using Flow Metrics", Credit Suisse's Agile Coach, Christian Hofstetter, offered some interesting insights into applying Dan-Vacanti-style Metrics to tune a "ScrumBan" Team's Processes.
The article begins with the Team's Cumulative Flow Diagram (CFD) and then 'drills down' into the data, using visual techniques such as Cycle Time Scatter Plots, Percententiles, and Ageing WIP distributions. I found this stuff fascinating. (After all, I devoured Vacanti's Actionable Agile Metrics for Predictability some years ago and the book really filled in some final, few areas of understanding that I hadn't deduced for myself.)
However, my conjecture here is that, from the shape of the graph, the trained eye can see not only the basis for Christian's conclusions but also the explanation as to WHY this new Team might be struggling. (If you haven't seen it already, I'd recommend to you my other post, "CFDs: What does 'Good' look like?")
Image 1: The rate of finished Backlog Items increased each week steadily from 0 to 9 Items.
Image 2: Work In Process (i.e. the amount of work started but not yet finished) increased by circa 78% over the same period.
Image 3: Average Cycle Time now extends 29% beyond the duration of the 2-week-Sprint (14-day) boundary, showing that the Development Process is effectively getting slower as the WIP increases.
Image 4: The Average Lead Time tripled to just over 24 days (6.2 days waiting in the Backlog, 15.6 days undergoing Development, and 2.4 days awaiting Review).
Image 5: The Average Lead Time displayed in a Pie Chart. (NB: In accordance with Taiichi Ohno's 7 Wastes, Waiting is waste, and the Team's Backlog Items appear to be spending over 33% of their time waiting.)
• The Team’s Lead Time is growing because their Cycle Time is growing.
• The Cycle Time is growing because the WIP level is growing.
• A Team’s WIP level only increases when it starts more work than it finishes.
• Scrum uses the Sprint Backlog (a Batch) as a natural limit of WIP.
• Kanban uses Policies (such as column limits / person limits / team limits) to limit WIP and improve the visibility of Flow throughout the entire Value Stream.
• ScrumBan employs both Scrum and Kanban’s WIP-Limiting techniques, and so – by definition – does not suffer the effects of expanding WIP.
It’s also very understandable as to why Credit Suisse, a large, financial organisation, might err on the side of caution when it comes to reviewing and accepting new pieces of software functionality.
However, as Items are not moving continuously from “Review” to “Done” (but are being Batched together), this suggests that the time of the person/people reviewing the work is valued much more highly than the rest of the team.
I think this is why the role of the Product Owner is so carefully described in the Scrum Guide.
The article begins with the Team's Cumulative Flow Diagram (CFD) and then 'drills down' into the data, using visual techniques such as Cycle Time Scatter Plots, Percententiles, and Ageing WIP distributions. I found this stuff fascinating. (After all, I devoured Vacanti's Actionable Agile Metrics for Predictability some years ago and the book really filled in some final, few areas of understanding that I hadn't deduced for myself.)
However, my conjecture here is that, from the shape of the graph, the trained eye can see not only the basis for Christian's conclusions but also the explanation as to WHY this new Team might be struggling. (If you haven't seen it already, I'd recommend to you my other post, "CFDs: What does 'Good' look like?")
But first, I need to mention a couple of things:
|
So let's take another look at Christian's CFD...
Image 5: The Average Lead Time displayed in a Pie Chart. (NB: In accordance with Taiichi Ohno's 7 Wastes, Waiting is waste, and the Team's Backlog Items appear to be spending over 33% of their time waiting.)
What do we know?
• Credit Suisse is a Financial Organisation.• The Team’s Lead Time is growing because their Cycle Time is growing.
• The Cycle Time is growing because the WIP level is growing.
• A Team’s WIP level only increases when it starts more work than it finishes.
What should we know?
• Regular 'Steppyness' in a CFD (where lots of Backlog Items move from one state to the next, all at the same time) tends to indicate the running of 'Batch Processes.'• Scrum uses the Sprint Backlog (a Batch) as a natural limit of WIP.
• Kanban uses Policies (such as column limits / person limits / team limits) to limit WIP and improve the visibility of Flow throughout the entire Value Stream.
• ScrumBan employs both Scrum and Kanban’s WIP-Limiting techniques, and so – by definition – does not suffer the effects of expanding WIP.
Here’s my educated guess:
In my experience, Product Management is often the main sticking point to Agile adoption. Senior persons, embodying a hierarchical ‘Waterfall’ Mind-Set, often tend to have difficulty entrusting their ‘junior’ colleagues with the rights & responsibilities of Product Ownership, preferring instead to combine Business Analysts (to do the ‘paperwork’) with Management Committees (to make the decisions).It’s also very understandable as to why Credit Suisse, a large, financial organisation, might err on the side of caution when it comes to reviewing and accepting new pieces of software functionality.
However, as Items are not moving continuously from “Review” to “Done” (but are being Batched together), this suggests that the time of the person/people reviewing the work is valued much more highly than the rest of the team.
I think this is why the role of the Product Owner is so carefully described in the Scrum Guide.
Recommendations to improve Flow:
- Apply Scrum and Kanban's WIP-Limiting Techniques.
- Use Value-Stream Mapping to identify where and how much time is spent waiting. Put that time into estimated monetary costs.
- Persuade those involved to Review much more frequently. (Preferably ad-hoc, 'as and when required.')
Comments
Post a Comment