This is a story about the path for a scrum team who started to use Kanban and the results of
the transition, which brought considerable improvements in performance but also improved
the situation for the development team.

The EMU team is working within the product line Human Vision, in the Continental ADAS
business line. The products provide a wide range of visualizations to support parking or
giving a better view around the car. Right now, the team works in the end phase of a
customer project for a good but demanding customer. The project is running in SAFe.
Why did the EMUs want to try out Kanban, it is a mature Scrum team that actually loves
Scrum? On the other hand, as most of us have experienced, in project “end phases” things
are not always running 100% smooth.
The customer felt the bug tickets were not prioritized high enough and that things generally
took too long. The customer was also unhappy with lack of flexibility for the frequent
unplanned “must have” tasks and had limited understanding for the team’s preference to
work on planned items.
The team on the other hand was annoyed with the, already mentioned, unplanned
customer items and the need to allocate time for unplanned review for external
contributions. They were disturbed that people often ran out of planned work in the end of
the sprint and that sometimes some items took very long time to get done. The team was
also, and still is quite large, in the project end phase with some 15 members. This resulted in
long and sometimes inefficient Scrum meetings. So far, the Emu’s did not want to split up in
two, more Scrum sized teams. One reason was it would be hard to make the teams
independent.
This was the situation when Felix, the EMU Scrum master and Martin, the PO searched for a
new way of working. We had already earlier had some lose chats about Kanban but now
they had gotten a buy-in from the EMU development team and asked if we together could try out if Kanban could improve the situation. It needs to be said, the EMU team is very
open for change and were encouraging the experiment.

How did we setup Kanban?

We planned two workshops; one to run a flow simulation with the team. It was an online
version of Klaus Leopold’s “the Ship building simulation – improving and scaling Kanban”
(please find on YouTube). It is a great visualization about the difference of flow for a push
system and a pull system, with WIP limits. When running in pull mode the throughput
improves a bit but the changes in lead-time and predictability are enormous. Such a
simulation is a very good start to understand the ideas of pull and flow from Kanban.

The second meeting was a STATIK workshop, which is a “Systems Thinking Approach To
Introduce Kanban”. It is a systematic approach to investigate the situation from a holistic
point of view, where the whole team takes active part to define the way of working. When
is the service fit for purpose? What are sources for dissatisfaction? What kind of
requirements do we have? What is the performance? Thereafter you agree on a workflow
model, agree on how to handle different classes of services, and finally design a Kanban
system. The STATIK process helps to ensure we consider many facets of the situation, helps
us to get a common understanding and provides an agreement for the setup and next steps.

Finally, the still engaged team discussed and agreed on explicit rules for handling of the
process and the Kanban board. A stringent and “lived” set of rules is key for a successful
Kanban implementation. They agreed on WIP Limits for of the various workflow states and
on rules to always pick the highest prioritized item from the Selected items, even if it does
not fit to your expertise, to not move items backwards in the flow, that impediments are not
counted in the WIP but are discussed every day and that they have at maximum one blocker
in an expedite lane, that is allowed to break the WIP limit and order of execution.

The EMUs agreed to keep many of the processes from their Scrum that worked well, like
standups, review meetings, retrospectives and backlog refinement. These are also explicit
cadences in Kanban. The general cadence for e.g., review and retrospective is still two
weeks.
However they stopped estimation of items after a while, since the value of estimation is
lower in Kanban and to save time. Even if items are not mapped to sprints the team focuses
more on breaking down items as much as sensible, but in all cases shorter than two weeks.
They also have more focus on getting items “really done”, by including unit test and
documentation in the items.
For the replenishment of selected items, the active backlog for the team, they introduced a
rule to fill up when the number of selected items goes below a defined level (right now 5
items).

Was there an outcome?

The new way of working had several positive effects. The customer got a considerably
higher throughput and some improvement in lead time but also experienced better
flexibility for ad hoc requests. The customer could also be confronted with direct impact on
putting urgent tasks in the backlog. This helped the stakeholders to reduce the number of
items with highest priority to get better focus.
For the team the new process has improved many things in addition to the feedback “more
pleasant / Less painful”. The team has got more flexibility and has less overhead, for
instance with leaving out estimation and having less discussions. “We have better focus on
the right things”, “we always have something important to work on” and “unpopular items
do not hang around for long time anymore”. In fact, even quality improved, since there is no
temptation to take a shortcut to get an item ready for the sprint end, now you can spend an
extra day or two to get something “really done”.
Other effects were better co-operation and a more active inspect and adapt process, with
more improvement proposals from the team. This may be the result after any change.
On the other hand, the team misses the end of a sprint when you can slow down, think a bit
and then start up again. In their Kanban setup the process still runs in a more continuous
mode, with less time for calm downs and re-thinkings.

What about the performance for the new setup?

Interesting enough the major change in delivery after introducing Kanban was in terms of
throughput, where the team delivered around 40% more during the 6 months after the
transition, compared to the 6 months before.
Also the lead time improved but not as significant, with a 15% reduction for the 85%
percentile (the lead time at which 85% of the items are closed).
The limited change in lead time is probably based on that the mature EMUs already had
focus on closing items in the scrum setup, but also due to the complicated long items that
turn up in every project end phase, when the simple things have already been fixed.
The increase in throughput is not fully clear, the team claimed in a presentation based on
early results “We do not know why we close more items (too good to be true?)”. However
also after 6 months there is a significant improvement. The reason is probably based on better cooperation between team members, where the WIP limits could lead to more pair
work, together with even more focus on finishing items. Further there was less down time
for developers, that earlier sometimes happened in the end of the sprints.
The improvement may also be related to other factors like item size and improved learning
and experience of developers.

Learnings and conclusions

For the EMU team the Kanban process improved the general performance in terms of
throughput and lead time, but it also improved the flexibility and focus to work and close
the most critical items. This has helped the team to provide a better service to the
customer.
The customer can be confronted with direct impact on putting urgent tasks in the backlog.
This helps the stakeholders to not put in too many items with highest priority.
The team experienced the new way of working as “more pleasant / Less painful”, within a
process that they had defined themself. The benefits are for instance less overhead in the
process, the urgent customer requests that earlier destroyed the planning are now business
as usual and there are always most important items to work on, earlier team members were
often without work in the end of the sprint. The team also owns the process better; when
the customer and/or PO now comes with a tricky request to be taken up “now” the team
asks “Is it a blocker? … well if it is not, please put it in the “selected” column, we’ll work on it
next”.
The initial workshops with flow simulation and STATIC helped to explain the benefits with
Kanban but also to get a buy in from the team. It is their process.
The Scrum master and Product Owners are obviously happy with the way Kanban turned
out but what would they do if they had to start from scratch:
Martin, the PO, “If I started up a new project I would probably start with Scrum and then
consider applying Kanban when team and project get more mature. In the early phase the
Scrum process seems to provide better structure to encounter too much flexibility from the
stakeholders.“
Felix, the SM, “the next thing to try out is to split the big team in two or three teams.”

And what happened to the EMUs in the last months?

For the last three months the project has an even higher demand on resolving items fast. At
this point the simple bugs were already fixed, what remains are complicated issues and
performance problems that require maximal focus. To encounter the situation the team,
still open for experimentation, decided to temporarily split up in four focus/topic sub teams,
which maintained own specialized backlogs. To further gain momentum, the whole
worldwide team co-located in Ulm for a week, it was a required and very appreciated move
to align on the last activities and tasks within the project before code freeze.

In the new setup the standup meetings were held per topic team, with a second common
standup with representatives for each topic team to align the whole team. The positive
effects were improved co-operation and communication in the small teams, including very
fast review and further improved throughput. A minor downside was the reduced
transparency for focus on the right things, since not all team members participated and
aligned in the common daily standup.
In the last weeks the sub teams joined into the normal EMU team again, since the most
critical specific work were closed into a more general bug fixing phase.

Felix Paffrath Conti, Martin Bürker Conti and Mats Olof Winroth improuv.