kanban vs scrum development

7/24/2019 Kanban vs Scrum Development

1/12

Samuli Heljo (/)

Reections on Kanban vs Scrum

development

Done and done! 1,5 years of hard work at National Land Survey is over.

What a great project! This post will be on my personal ndings about

Scrum team transition to Kanban. What worked and what not? Moreover,

I will try to analyze the failures we made and to come up with some

solutions. Lets get started!

Background

Samuli Heljo (/)

June 23rd 2011
http://samuliheljo.com/http://samuliheljo.com/


2/12

4 person development team was formed about 1,5 years ago. Team

members were selected based on a cv, a hourly fee, psychological tests,

and an interview. Two people knew each other from earlier project, but

everyone else were complete strangers. National Land Surveys project

team consisted of Product Owner / project manager and about 8

subject-matter experts. Product owner had no previous experience on

Scrum but he had been coached on Scrum prior to kick-o. Team chose

me to work as a Scrum Master.

We started Scrum by the book. Two week iterations, Denition of Done,

retrospectives, you name it. Some of our initial DoD agreements did not

materialize immediately but got better while team learned to know eachother. Basically steps that team went through in terms of Scrum

implementation improvements were:

Scrum by the book, velocity, definition of done

Unit testing

SwarmingContinuous integration

Automated UI tests

No Monday sprint plannings

Team member cross testing

Process waste visualization

Team does not jell immediately and this takes time. Even though I knew

all these things would be nice and even mandatory to have in place, you

should not force them on a team if it is not ready. In addition, team felt

that it had to make progress with features and team's process

improvements would have to be made in small steps. I feel that every

team will have to discover their own process and you cannot copy-pasteteam culture. Therefore, rst important rule for organizations:


3/12

Do not break well functioning teams. If possible, try to move them

together to a next project.

Hmm, what did Jurgen say?

In Turku Agile day I listened to Jurgen Appelo (http://www.noop.nl/) talking

about teams emergent goals. Well working team will come up with its

own goals in addition to those set by the Product Owner. First of all, it is

important to be aware of this behavior but also to encourage team to nd

their own way. When well functioning team is torn down, a new team will

start formation process from lower level (Tuckman)

(http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development)

If teams emergent goal had been a benecial one, it is also lost.

Group prototype

Once group starts to work together it begins to form a group prototype.

This prototype represents us and it aects teams self-image. If

prototype is energetic and responsible you are more likely to get good

results than when prototype is a sloth. This whole prototype thing is

actually really interesting as it also means that those who are

prototypically central become highly inuential. Check out this nice book

about the subject (http://www.amazon.com/Blackwell-Handbook-Social-

Psychology-Processes/dp/1405106530/). In short, well functioning team is

a gem. Try not to break it.

Please, I am busy, do not get side tracked

Ok, back to year 2011. About three months ago we wanted to try out

Kanban. Team had been doing Scrum over a year, solution was in

production, and now team had trouble with expedite type of work. This
http://www.amazon.com/Blackwell-Handbook-Social-Psychology-Processes/dp/1405106530/http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_developmenthttp://www.noop.nl/


4/12

work that had to be taken care of right away was mostly production

maintenance and occasionally some bug xing. Team (and PO) felt that it

could not wait for two weeks just to t these expedites into a sprint.

Furthermore, team began to encounter stories that were really dicult to

estimate. This could be a 1 or a 10, it depends on x. Team felt that

estimation of these tasks was waste because they had to be made

anyway. Downside of this of course was the fact that when some story

was ten times bigger than originally estimated, sprint goal was pretty

much nullied. In addition, team had challenges with work that had to be

stopped because sprint was over. This caused situations where everyone

knew that a feature needed an improvement but because there was not

enough time to do it, team decided to move improvements to next sprint.

This is somewhat wasteful because it would be nice to completely nish a

feature team is working on if everyone agrees that it lacks some key

functionality. Why move work in to the future? "Because we do not have

time right now". This lead us suggesting the use of Kanban to PO. Luckily,

he agreed.

After three months of development and 4 version later, our board looked

like this:

(/img/blog/kanban.png)
http://samuliheljo.com/img/blog/kanban.png


5/12

(click to enlarge)

Development team's Kanban process went like so:

Development team used the Kanban board, "project team" did not.

Product backlog was still maintained by the PO and stories were

estimated in product backlog like in Scrum. Sprint plannings were

replaced with pull planning. When selected stage had room, PO chose

next tasks on to the board. Once Analysis stage had space development

team broke user stories into tasks like in sprint planning. The dierence

was that these planning sessions were much shorter than with Scrum as

usually only one story had to be analyzed. Team had 3 implementationlanes. When there were empty slots, story was moved onto the

"development" stage. Then, slowly tasks moved across implementation

and once everything was coded, tested and ready, story was deployed to

"staging" environment and PO was notied. Next, PO and project team

veried that everything was OK after which story was scheduled to a

release. One lane was reserved for expedites. Plain and simple! Did thatwork? Well, thats a good question.

Start with positive, what worked?

Team's lead time was painfully visible and pressure to deploy increased

as post-its kept piling up. Our lead time clock was started when user storywas placed to the selected stage. Clock was stopped when feature was

deployed to production. Lead time was measured in calendar days. We

noticed improvements in lead time, partly because now PO was more

concerned about it. I think this is in line with Lean promises that you get

process modications just by visualizing it.

Lead time is very easy to track with Kanban and in our case lead time

was reduced.


6/12

In picture below you can see lead time distributions of 82 stories.

In this second picture, an individual moving range chart

(http://en.wikipedia.org/wiki/Shewhart_individuals_control_chart) has

been created and it looks pretty steady around 11,5 days. There are somespecial causes that were caused by clustering etc.
http://en.wikipedia.org/wiki/Shewhart_individuals_control_chart


7/12

In third picture, I have created a boxplot to see how lead time varied

between releases.

Based on these images, I would say team's process was pretty stable.

Was this data usable or not? Theory is that once we know our averagelead time and standard deviation we can establish a SLA. Then

organization can order features and be somewhat condent that it will

get them when needed. Problem with this logic is that in our case

organization was not particularly interested in this stu. They were more

interested in release level information and Scrum style velocity

information was enough for them. That being said, in some other context

this could be vital information. So, what else? Benets also included the

fact that the team members were more aware about the status of a story.

Is this already deployed to test? The board told you.

Work was nicely organized as everyone in the team could see

progress on the board


8/12

Also, team's initial concern about expedite work worked out pretty well.

But does this encourage towards could you x this for me quickly type

of behavior that is the one main thing we are trying to avoid with Scrum? I

think so.

Team was very responsive to expedites. But this is not necessary a

good thing.

What did not work as advertised?

It was pretty big surprise that PO actually felt that visibility to work waslower than it had been with Scrum. Once we thought about this it was

pretty clear why. We had thought that informal meetings and a Kanban

board would keep PO up to date on progress. It did not. In Scrum, we

spent 15-20% of our time in Scrum "meetings" that also served as a way

to keep everyone on track. That being said, this is not a fault in Kanban

but came out of our work.

PO felt that visibility to work with our Kanban implementation was

lower compared to Scrum.

One of the biggest problems was caused by the lack of a timebox. We

had no predened release cadence (maybe we should have), nor had we

cadence for demos. But the problem was not only about cadence, it was

also about the lack of commitment and positive pressure. In Scrum,

timeboxed sprint will foster positive buzz as the team will not want to

look stupid in demo. I felt that Kanban was lacking this energy.

Lack of commitments caused positive buzz to disappear.


9/12

Daily stand-ups where done in front of the Kanban board. Instead of

asking what team members did and will do next, we focused on tasks.

This created two problems. I think it decreased team member

commitment and also caused team to focus on tasks instead of each

others. Dierence may be subtle but I felt that the team was more

present in Daily Scrums and concentrated more to each others with

Scrum.

Daily stand-ups were not as focused as they were in Scrum.

We held review when the team or PO felt like it. Usually at this point

new features were already deployed to production and everyone had

already tried them. This somewhat took the edge away from reviews.

Reviews were not as exciting as they were in Scrum.

What was really dicult?

It was not uncommon that one or more tasks were blocked by some

external factor. We encountered situations where all free slots were taken

and 50% of tasks were blocked. Often it was the case that none of us nor

PO could do anything to speed up blocking issue. What to do then? We

could increase WIP limits or try to proactively work with upcoming

blockers. We tried both ways even though you should not continuously

tinker with WIP limits.

Our initial WIP limits were too small and we had to increase them

later.

Mistakes, mistakes, mistakes


10/12

It is obvious that we made many Kanban rookie mistakes and David

Anderson probably would not give us Professional Kanban Master

Certication. Anyways, Kanban by stripping down Scrum did not produce

results we had hoped. I feel that Scrum team can benet from Kanban

type work visualization. However Kanban as a method, in my opinion,

needs some structure.

There was a nice tweet by Henrik Kniber

(http://blog.crisp.se/henrikkniberg):

Kanban teams rediscovering value of basic Scrum practices such as sprint

reviews & backlog workshops

And I agree. "Kanban bible" (http://www.amazon.com/Kanban-David-J-

Anderson/dp/0984521402) recommends release cadences but it does not

mandate where daily meetings should be held, how to inform your

stakeholders nor does the book require you to get rid of developer

commitments. Basically all the things that did not work was our own

fault. In that sense Kanban is pretty advanced method because you really

have to understand implications it has to psychology, team culture, and

visibility. It denitely is easier to introduce Kanban to a company than to

do a full scale Scrum transition. Just do as you always have done, but use

this board. But will this actually change anything? In overall, Scrum ornot, organizations in Finland are in great need of full value stream

visualization. It is not only about the development team. Value stream

should be more visible in business side also. Then full concept to cash

lead time would be very interesting. Finally, you can also say that we

created local optima with our Kanban and our lead time calculations

should have included product backlog as it is the real inventory. Onceagain, I agree.
http://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402http://blog.crisp.se/henrikkniberg


11/12

What's next?

If you are having thoughts on your Agile implementation we should

arrange a meeting. Check out how I can help you (/agile).

Back to blog (/blog)

Discussion

Agile vs. Lean Six Sigma

If your goal is to work with

software teams or organizations that do

software engineering I would start with Agile

Stop using story points?

Thanks for the comment! My

blogging rate has indeed declined, projects

consume nowadays that much time plus I try

SAMULIHELJOCOM

3 Comments 1

David Murphy

Only just came across this, bt its a very useful article, even 4 years later :) And thanks for using

Disqus, soon much easier.

Dan Linstedt

Thank-you for such a brilliant and insightful piece. I appreciated reading about both the positives

and negatives of your experience. I would like permission to quote your material and this post, in

my presentations.

Samuli Heljo Mod

Dan, Thanks for the feedback. You have my permission to quote my material.
https://disqus.com/home/forums/samuliheljocom/https://disqus.com/home/forums/samuliheljocom/https://disqus.com/home/inbox/http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175https://disqus.com/by/samuliheljo/https://disqus.com/by/samuliheljo/https://disqus.com/by/samuliheljo/https://disqus.com/by/samuliheljo/https://disqus.com/by/samuliheljo/https://disqus.com/by/samuliheljo/https://disqus.com/by/dan_linstedt/https://disqus.com/by/dnmurphy/http://samuliheljo.com/blog/reflections-on-kanban-vs-scrum-development/#comment-1388340896http://samuliheljo.com/blog/reflections-on-kanban-vs-scrum-development/#comment-1388490349https://disqus.com/by/samuliheljo/http://samuliheljo.com/blog/reflections-on-kanban-vs-scrum-development/#comment-1388340896https://disqus.com/by/dan_linstedt/http://samuliheljo.com/blog/reflections-on-kanban-vs-scrum-development/#comment-2184096993https://disqus.com/by/dnmurphy/https://disqus.com/home/inbox/https://disqus.com/home/forums/samuliheljocom/http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fstop-using-story-points%2F%3Ag0Lx_r_nhKppl3ZrXyqDU1tME0I&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2096095998&zone=thread&area=bottom&object_type=thread&object_id=2096095998http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fstop-using-story-points%2F%3Ag0Lx_r_nhKppl3ZrXyqDU1tME0I&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2096095998&zone=thread&area=bottom&object_type=thread&object_id=2096095998http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175http://disq.us/url?url=http%3A%2F%2Fsamuliheljo.com%2Fblog%2Fagile-vs-lean-six-sigma%2F%3ArsP80hu5zuQKX1tQ39OfUI4uc-4&imp=5c4l4os226to0b&prev_imp=5c4ius72l6lcqs&forum_id=2749368&forum=samuliheljocom&thread_id=2081881371&thread=2082568175&zone=thread&area=bottom&object_type=thread&object_id=2082568175http://samuliheljo.com/bloghttp://samuliheljo.com/agile

kanban vs scrum development

Documents