First, I state that I can’t improve the process; instead they should improve their work. I found this statement helpful by allowing the team to assume responsibility on their work and to position me as coach for building trustful relationship. The last thing they should worry about is that I am going to expose their weaknesses. This step is foundation for successfully working together. Trust shouldn’t be declared instead it’s judged by the team. I try to explain that as a team our role is to meet the demand from various sources. Therefore, we should understand the demand from various types and our Throughput to meet it.
Second, I ask them to talk so that we can together layout their end-to-end value stream from need-to-cash. I ask them about:
- Dependencies on other teams.
- Players in various activities.
- Various request types and the percentage of each.
- Typical length of each request in the system.
- Who should be involved in every request type? How they define success for each request?
- What is the Definition of Done for every request type? This can have impact on adding more stages to the value stream.
I don’t ask them about data, I rather plan to implement system which visualizes the flow and collects the data. This is excellent opportunity for me to learn about their context and for them to understand my role and approach.
Third, I construct next day the visual board, which includes:
- Define the WIP limits for each stage and for every team member. This helps to set the rule of controlling task switching up-front.
- Agree on card layout of a request.
- Agree on the layout of children cards that might need to be tracked for certain requests.
- Define queues based on understanding of dependencies. I found that if we depend on external resource then it’s normally a bottle neck. I start exploiting this bottle neck by asking to have queue with WIP limit in front of it. I also suggest that the team should ensure this queue is non empty. I talk about we should not poorly utilize this external resource (bottle neck), therefore we should provide them highest possible quality. In live situations, I found this bottleneck role is played by Architects who review the designs from various teams.
Fourth, agree on the ceremonies, which include the following:
- Daily stand-ups. What are the team member responsibilities on updating the board?
- What is the trigger of moving cards or signaling that work needed to be pulled?
- How often the backlog will be prioritized? What is the mechanism for doing so?
- How the hand-offs from one stage to another of the value stream will be administered?
- Agree on regular schedule for demoing the finished requests.
- Agree on regular schedule for retrospect.
We always align our work to the regular release schedule of the organization; hence, the target on each card must coincide with a release date. This drives prioritization and card movements from one stage to another. I avoid having a separate sizing meeting; instead I suggest having stage after the backlog for Analysis. During this stage the developers break-down the request to manageable children cards, assess risks, and confirm whether they can meet the target date. They provide lump-sum estimate for the effort. I did not find tracking actual effort pays off.
In the daily stand-up address:
- Ensure the board reflects reality
- Issues which stops the flow
- Un-clear priorities
- Expedite requests
- Ensure the team receives requests only through the agreed on sources
Fifth, collect data electronically and report weekly/biweekly the following:
- Lead Time
- Deviation of Target and Actual Dates
- Throughput per request type
Sixth, uncover improvement opportunities to address:
- Bottle necks
- Collaboration opportunities
- Improve prioritization
- Deepen the Definition of Done
- Include acceptance test cases with the request card
A key success in the implementation is the first step, which the team owns the flow and visualization. Gradually the team should take control.