The Kanban strategy: a real driver for a good Daily Scrum

Collaborative article written by José Coignard (French PKT) and Jim Sparks (American PKT)

In this article, we explain how to regain control and direction of your daily Scrum using the Kanban strategy.

1 ) What is a Daily Scrum?

The purpose of the Daily Scrum is to enable the team to organise or reorganise itself to continue progress towards achieving the sprint goal.

The team is a collective that succeeds or fails together; there is no individual responsibility, but a team responsibility for this goal and the quality of the increment.

The Daily Scrum is used by the team on a day-to-day basis to manage the work required to achieve the sprint goal together, which means that all team members must attend this event.

Be careful, it's not a reporting event, but a short event for getting organised in a collaborative way to work on what's most relevant for the next 24 hours.

2 ) Improving the Daily Scrum with Kanban

For a more effective and efficient daily scrum :

1. Have the sprint goal and the sprint backlog in front of you.
2. Have a view of your work items in your workflow, including the age of the work items and a simple way of viewing "blocked" work items.
3. Rather than answering the most common Daily Scrum questions, i.e.

• What did I do yesterday (which leads to reporting)?
• What am I going to do today to make progress on the objective? (not bad, but a bit too individual)
• Am I stuck and do I need help? (this one's a keeper)

Use the following questions:

1. Is something aging unnecessarily in our flow?

2. Is it because that thing is stuck (dependency, an issue that the person or group working on it can't find a solution to, etc.)?

3. If so, what is happening briefly? Have you identified someone to help? How can we work together to unblock the situation and finish this work?

4. Does anyone think they need help and with what?

5. Is there anything at risk of exceeding our SLE?

6. What is the most important thing we need to achieve today?

7. How can we increase the chances of finishing this most important thing today?

With the sprint backlog and a visualisation of the age of the items in the workflow in front of you, focus the daily scrum exchanges so that the items progress in your flow in a logic of starting by finishing (i.e. from right to left) as well as in a logic of working as a priority to move forward the items that are aging abnormally.

Don't forget your sprint goal ! Logically, you won't have started anything else that doesn't contribute to it until you've reached it, have you?

How can you tell if a work item is aging unnecessarily?

When applying the Kanban strategy, one of the first things you'll do as a team is to define an SLE* (Service Level Expectation). The SLE is a forecast.

Using historical data and your SLE will enable the team to identify when something is aging unnecessarily. This guides your focus for discussion and enables a plan of attack for the day.

*SLE: A forecast is comprised of a range of time (e.g. 15 days or less) and a probability of being in this range (e.g. 85%) which the team chose and on which the team challenges itself not to exceed in order to finish an item which has entered its workflow.

Another contribution of the Kanban strategy to daily Scrum revolves around another fundamental metric, the WIP.

If you've started too many things (low focus), you're going to have trouble keeping up with the 15 minutes of daily Scrum. Apart from the fact that this event is likely to have its timebox blown up regularly, it's a real problem for your efficiency, effectiveness and predictibility to start too many things (see José's little post on this subject here: https://www.dhirubhai.net/posts/jose-coignard_doug-macdonald-rice-and-traffic-congestion-activity-7138275853376839680-z6sf?utm_source=share&utm_medium=member_desktop )

3) Application to a real case

Let's take the example below, which represents the state of a team's workflow during a daily Scrum.

First of all, let me give you a quick explanation of this chart, which is known as the "work item age chart":

• Each point represents one (or more when there's a number in the point) item in the sprint backlog
• On the x-axis (horizontal axis), you can see the stages in the workflow. "En cours" meaning In progress, "Dev terminé" meaning Dev completed, "Recette" meaning Testing and "Terminé" meaning Done
• On the ordinate (vertical axis), you can see the age in number of calendar days
• To the right of the percentiles is an indication of the historical base of items that have been validated in terms of the time it took to go through the workflow. 85% of historical items took 18 calendar days or less to go through the workflow, and 10 days or less for 70% of items.
• The colours represent these same percentiles (dark green <50%, light green <70%, light yellow <85%, orange <95%, red >95%) but by time spent (historically) within the workflow state itself. For example, to make this clearer: 50% of historical tickets were in the "Acceptance" state after 3 days or less of circulation in the workflow, 85% of historical tickets were in the "Dev Completed" state after 18 days or less of circulation in the workflow...

Let's assume that this team has chosen an SLE of 18 days or less 85% of the time. You can see that this SLE is represented on the graph by dotted lines and the 85% indicator on the right.

Let's focus on work items 643 and 649, for example, which are respectively 23 days and 21 days old in the flow.

Given the logic of checking that nothing ages beyond 18 days at 85%, discussions should have happened before today to try to ensure that these elements do not age beyond 18 days at 85%.

We can imagine that this is probably not what has happened here, as these work items have already exceeded the SLE (And José confirms that it was, really !)

The detail give us a bit more information. Work item 643 has spent 1 day "En cours" (In progress). Then 6 days in the waiting stage "Dev Terminé" (Dev completed) and now is sitting in "Recette" (Testing) since 15 days. Why the testing part is taking so long ? Are there many problems encountered ? Are there many regressions ? Are we really working actively on this and if no why ? Are we blocked by something ?

All those questions should have been asked days before in order to avoid this situation where the item is aging unnecessarily.

Other example here from the detail of that work item 649. 7 days "En cours" (In progress), oki... But 13 days in the waiting stage "Dev terminé" (Dev completed). What are we waiting for? What is blocking us to pull this and start testing? Why didn't we focus on finishing this item? Some questions that the team should have asked few days ago as they now have pulled this in the stage "Recette" (Testing) but have already exceeded their SLE. They have let that item age unnecessarily.

We can also see that a significant number of work items are beyond these 18 days, and even 32 days at 95%.

The next important work items to move forward are therefore in the "orange/red" zone of the graph, like 557 in the example below:

So taking a global view, on this Daily Scrum using the Kanban strategy, discussions should revolve around the items in the focus area below:

All these work items are aging unnecessarily. The reasons may be varied, but it's a subject that needs to be taken seriously by the team, as customers and users expect these work items to be of potential value!

There's no need to discuss the other work items today, at any rate, especially as the WIP is extremely high for this example of a team and workflow situation (unless you have something that will ruin your business if you dont take care of it now ! but hopefully for you that is not happening everyday).

The organisation of the team today must be built to focus on stopping work item aging and finish what has been started.

By unblocking and getting these old work items out of the way (and avoiding starting anything new), the team can eventually tackle the other work items and re-establish a much better flow of potential value delivery.

If the team doesn't do this, some of the potential outcomes include the situation could get worse, customers could become less and less satisfied, pressure on the team could increase (which will most certainly accentuate the problems), and stakeholders’ confidence in the team will only fall... (and we could list many other bad things). In short, things you absolutely don't want to experience!

We invite you to read José's other article on Little's Law (find out more about that article here) to understand the importance of flow stability and why you want to limit (accordingly to your context) the number of work items in progress at any time.

4) A real life analogy

Here is a quick analogy to help relate this to everyday life outside the office.

Let’s say you are in charge of the barbeque for the summer holiday party. All your guests’ happiness rests on your shoulders. While you are grilling the best selection of food money could buy, you are also wrangling the chips, dips, and drinks. Delivering those tasty meats and kabobs on time is paramount to the success of the party. Undercooked food would spoil everyone’s appetite. Even worse, overcooked, or delayed food would leave everyone famished and frustrated.

Now let’s break this down.

Your guests are relying on you to satisfy their hunger. Value delivery to your customers.

You want to get all the food delivered to the tables by your advertised dinner time. Your time box and your sprint goal.

You have multiple items cooking on the grill while you are also overseeing the rest of the party food items. Think of this as your work in progress.

As you step away to tend to other party needs, you need to regularly check back on the food items cooking on the grill. This allows you to check progress as well as plan out when these items will be done and ready for your guests. This would be considered your Daily Scrum.

Each time you check the barbeque, you should assess how long each item has been cooking and what state they are in. You know about how long it takes to cook most items to achieve the proper level of doneness. This is your item aging and SLE.

Are there any items in danger of cooking too long and becoming burnt? Are there too many items on the grill at once that slow down the cooking process? Are the flames on the grill burning correctly? Are you struggling to flip the food items because of a lost spatula? Is there anyone who can help put out the ships while you tend the grill? Here are the questions you should ask yourself each time you check-in. They help you identify any items aging unnecessarily, any inefficiencies in the process, any impediments, any areas you can ask for help, or any areas of immediate focus.

Although this is a very simple example, it shows how you can link an effective Daily Scrum to processes that most people identify with in real life. Embracing these processes can help you support the team’s goals of value delivery.

5) Time to conclude

We do hope that this article will help you improve your Daily Scrum and optimize your flow. You should have understood that Scrum and Kanban work very well together. There is no Scrum vs Kanban but Scrum with Kanban, or Kanban enhancing Scrum. Indeed for the Scrum Teams out there, Kanban can help you move towards informed decisions, accurate planning, and actionable improvements.

You want to learn more about how Kanban can help you achieve greater flow of value ? Join us in one of our classes !

Class (in french) of José can be found here : https://www.tickettailor.com/events/theflowmizer or if you want some private one (in french or english) get in touch either via LinkedIn or check the website www.flowmizer.org

Class (in english) of Jim can be found here : https://www.tickettailor.com/events/transcendingagilityllc

Feel free to comment and give us other ideas for articles!