Sounds familiar? Teams are using Scrum for more than half a year and keep missing their sprint commitments? Or showing a constant velocity? Keep doing improvements without visible improvements that benefit the customer? Scrumban helps teams forward. Scrumban is applying the Kanban Method in a Scrum context. It provides teams a way of doing improvements that matter by providing them with a structure and principles to work with.
Often Seen Symptoms
In practice when coaching scrum teams I often encounter the following:
- repeatedly missing sprint commitments,
- having more than 1 Definition of Done,
- a velocity chart that doesn’t show an increasing velocity,
- keep making changes to the process without any visible benefits to the customer,
- ‘deployment’ user stories, or ‘user acceptance testing’ user stories, i.e. parts of a user story that belong to different phases.
The problem with quick fixes is that the root cause isn’t fixed. Merely the symptom is made to disappear only to see it reappear in a different form and shape.
To see how the Kanban Method helps, let’s take a short deep dive to see what it is and how it helps.
The 4 principes of the Kanban Method are:
- Start with what you do now
- Agree to pursue evolutionary change
- Initially, respect current roles, responsibilities & job titles
- Encourage acts of leadership at all levels
Especially because of the first and third principles the Kanban Method can be applied to Scrum teams by taking their current way of working as the starting point.
These principles provide us with a guide but not yet ‘how’ to apply it.
In coaching teams I often encounter:
- an unclear goal or purpose,
- a strong focus on their ‘own’ work,
- a backlog consisting of various types of work.
Purpose. One of the first things to fix is to return focus on the right things. Together with the team discuss the team’s purpose. Who is the customer? What are the customer’s needs and expectations? Make sure to be able to have this measurable. How are we doing now and what is the customer’s wish.
Types of work. How does the work arrive at the team? Who wants the work to be done? To whom does the team deliver the result to? What are quality expectations? What frequency or patterns do you notice?
Focus on the whole. Visualize the whole knowledge discovery process: from begin to end. Even if the team is only a small part of this chain I find it useful to have the insight into the whole. The effect of this is that it helps the team realize the effect they have on the whole chain.
Metrics. Start at least with measuring three things:
- the average lead time per type of work,
- the frequency of certain bins of lead times (a so called lead time distribution chart),
- the amount of work in progress per time period, e.g. daily, weekly, …. (usually in a cumulative flow diagram)
- optionally: any other metric that is important in providing feedback regarding the purpose.
These metrics help the team in determining the next improvement action. Because the metrics are closely related to the purpose, these improvements will help the team provide an even better service to the customer.
In this blog I have provided a description of an approach that works in practice but not given details of how to actually apply it. Examples of approaches that have worked for certain patterns will be described in next blogs.