KANBAN and SCRUM, combined!

Development and maintenance should be done by the same people, it should not be divided and conquered. Why? It’s one product/system! After the first release (it’s all about TTM, isn’t it) you have maintenance, but you’ve only finished a small part of the product. From then on, it’s development AND maintenance, after just a month or so. Still, maintenance, dealing with support, defects and stability, is more variant than development. IMO, scrum is great for development, kanban is great for handling maintenance and variants, and the suggestion in this post is to combine them. Say, if you had 3 teams, would 2 scrum teams and 1 kanban team, rotating each iteration, be a good solution?

This post is in part an answer to Geir Amsjøs blog post and comments at Geir’s smidige hjørne (norwegian only) ITIL – et gufs fra 90-tallet (reads: ITIL – a gust from the 90s), but mostly it’s a post inspired by the problem, trying to find other solutions to the development and maintenance. ITIL is about maintenance, but I will not tell you more about it (check Geir’s link and look at the process diagram) as some stuff can’t be refactored or modified, it just have to be identified as what it is, waste, and handled accordingly.

I greatly appreciate Geir Amsjø, even being Norways only certified SCRUM Trainer, his mindset is not limited to fitting everything to SCRUM. Well, that’s my impression at least! Geir has written alot of great articles about scrum and software development in general.

I’ve been working with scrum since 2006 and have a lot of good and bad experiences with it. My goal is to be agile, delivering business value as first priority, rather than following a detailed plan. It’s all about failing fast, acknowledging that one do fail a lot! Or is that only me? I’ve experience that SCRUM might help me being more agile, done the right way, and what I like best about it is the way it focuses on people working together as teams. I suppose SCRUM is fairly familiar to most of you, and maybe you know or have read about KANBAN too.

My understanding (wishful thinking) of what KANBAN is, is:

  • continuously prioritized queue (of tasks. Might be user stories). SCRUM is at best weekly, more often monthly (please understand why this is bad)
  • continuous deployment
  • applying what works for you (daily standups, retrospective (this is a must) )

Here’s my go at illustrating KANBAN for software development and maintenance:

Actually, the continuous deployment part is so incredibly agile that it will identify an extreme amount of waste in your process, architecture and people/roles that this should be the goal in its own.

As a side not, I suppose you know quite a bit about SCRUM and KANBAN already, I’m not going to explain each element, only stating the main difference: SCRUM is iterative, while KANBAN is flow (continuous). KANBAN may be implemented many ways (hence it is doomed too fail as well when becoming mainstream) and my own understanding of the details is surely to change in the future, so think for yourself and don’t take it all literally. Nice!

What about KANBAN and SCRUM, combined?

First of all, assume SCRUM works really well for software development. That you don’t want to throw away SCRUM just yet (and you probably shouldn’t). Too me, scrum is great at building great teams, done the right way (sadly, I don’t often see it being done right). The team commits, the team fails, or the team succeeds.

In a lean perspective or systems thinking, you need to consider the bigger picture. Talking about software, this certainly does involve maintenance too! I feel SCRUM handles this poorly. Well, there are many (SCRUM) solutions/proposals to this. Some people creates a pot for support task up front, say 20%, but as defects are variant, they introduce unpredictability to a team, affecting commitment and be counterproductive to what I feel make SCRUM good. In my opinion! Others would just focus on development, leaving maintenance to others, which is like closing their eyes!

The way I see it, is that its built upon weekly or monthly waterfalls (V model), as KANBAN is hourly or daily waterfalls, exaggerating of course, bear with me! What does experience teach us? Different tools for different problems, there’s no silver bullet!

OK, to the point, best explained through an example!

3 teams, 2 SCRUM teams and 1 KANBAN team

Wouldn’t it be interesting to run such an experiment? How would I organize this:

  • Rotate the members each sprint.
  • Each developer should be part of the KANBAN team every third sprint!
  • The SCRUM teams focuses on user stories and features, no “support pot”
  • The KANBAN handles support and maintenance.
    • Developers will better understand what they are making, why, and how it is being used.
    • Eliminating failure demand (Leading Lean Software Development)
    • High responsiveness yields happy users and customers (yields profit?)
    • Better quality
  • Both SCRUM and KANBAN teams holds retrospective and implements whatever method they think will be good (as standup, whiteboard architecture, pair programming)
  • Product Owner, right people to continuously prioritize the queues.
  • Prioritizing (continuously) might be THE most effective improvement to any project. This work is extremely important!
  • The continuous work on prioritizing and working on the backlog will improve the sprint backlog for the teams too, as an extra benefit (I’ve experienced that this is part of SCRUM that most often result in it all failing. It should not be taken lightly).

Challenges

  • source control, versioning
  • task dependencies

The latter first, task dependencies. The tasks of the KANBAN team cannot depend on a task being completed by the SCRUM team.

Versioning

Being all agile and whatnot, the obvious choice is using git, hehe.

Said in one line: As the KANBAN team continuously deploys to production, as each defect or such is done, the SCRUM team should merge it into their code.

Said in pseudo code:

for each time the KANBAN team performs 'git push prod' do
  for each SCRUM Team do 'git pull prod' (into devbranch)
for each SCRUM team member, when sharing code
 do 'git commit ...', then 'git push'  (into devbranch)
at end of sprint, push devbranch into prod

Hope this was somehow understandable, not to satisfied with this one.

Summary

As Mary and Tom Poppendieck states. Failure demand is WASTE. Eliminate failure demand! Understanding the failures one introduce is essential in order to not produce them to begin with. Having the developers, rotating as being part of the KANBAN team, take the support calls themselves, fixing defects at once, will make them understand both the needs of the users (customers), and what code quality is all about. Why not only have KANBAN teams? If you truly believe that SCRUM is well suited in creating a winning culture, that is, wanting to commit to delivering as much as possible, repeatedly succeeding with it, you are greatly increasing your chances for success.

Why not trying to extract the better from the two methods?

If you’d like to try it out, remember that I’m a contractor, sign me! :) While being an agile coach, I’m a developer at hearth! I spend most my time programming, experimenting and improving. I would love to work with reflective people with a vision.

About Ole Morten Amundsen

Developer, programmer, entrepreneur. Java, .Net, ruby, rails, agile, lean. Opinionated enthusiast!
This entry was posted in agile, lean, smidig and tagged , , , , , , , . Bookmark the permalink.

10 Responses to KANBAN and SCRUM, combined!

  1. Odd Christer says:

    I’ve just skimmed the article, but I think you’ve left out one important thing for Kanban: limiting work in progress. Perhaps one of the most vital pieces of a kanban process.

  2. Geir Amsjø says:

    Hi Ole Morten,
    thanks for the good words!
    You are missing the limitation of WIP as Odd Christer said, but that was not the main point in your post I guess..

    In my opinion the distinct rhythm in Scrum great. So, if you are able to commit to work for the next 1-4 weeks Scrum is a great tool for becoming Agile. But there are two situations that makes committing very hard:
    1. If what you do is support/maintenance: A large portion (more than 30%?) is “unplannable and urgent”.
    2. What you do is more Research than Development.
    -> Use Kanban instead.

    Be careful with changing teams all the time. People can develop very good releationships in Scrum teams, but that tend to take time. “Don’t change a winning team”.

  3. Nice post Ole Morten,
    It sounds very interesting to give this a try. If nobody else does; I can do it later this year and then present the results on next Agile conference in 2011 ;)

    The thing that concerns me a bit is that developers (on scrum teams) are not fixing their own bugs, someone else (kanban team) is doing it. But as long as you rotate the people inside the teams, maybe this is not a problem.

  4. Ole Morten says:

    Yes, WIP is beside the point, but I appreciate the input!

    @Sergey, do it! :) Involve the team members and let them help form the process. Trust builds great teams, IMO. I’ll be there in 2011, listening to your experience talk :)

    @Geir, you might rotate the whole team. The scrum team becomes the kanban team and so forth. I see and agree with your point, building winning teams is a great concern of mine! This is why I’d like to remove as much of the variants as possible, like urgent fixes and such. It’s counter-productive having teams fail their commitments because of these kind of unplanned tasks. If you can blame others, you blame others (put on the edge). The unplanned work should come from themselves doing a poor job understanding the user stories at the sprint planning (or these stories being poorly written).

  5. Knut J Dahle says:

    Good post, but rather than the developers switching teams all the time,
    could not the teams change process every 3 iteration?
    Two iterations as a scrum team and one iteration as Kanban team? 

    Alternatively, two teams, Kanban and scrum every 2. iteration. Then
    you deliver one iteration as a scrum team, and have the support / bug fixes the next iteration.

    • Ole Morten says:

      sure:) That would help building the team spirit.

      I’m not too sure about the not splitting up part though. Shouldn’t it be more about Project Spirit? They should all work together against a common goal, that’s why we collate development and maintenance. I can think of whole bunch of stuff you miss by not rotating. Common code standards, language, project success over team success… I might be alone on this one. Well, there’s always a trade-off, it’s complex, and I guess, it depends, as Kent Beck would have said :)

  6. Geir Amsjø says:

    I also strongly believe feedback is vital for both building the right product and for delivering reliable software. So – the creator of the bug should be the one to fix it – as soon as possible. A lot of learning to gain from that!
    So, there are a lot of trade-offs to do here – but experiments are welcome anyway Sergey! :-)

  7. Pingback: De Kontinuerlige « Ole Morten Amundsen

  8. Vidar Alvestad says:

    We give it a try to have one team both work Scrumish and KanBan´ish. We splitted the whiteboard in two parts. Upper part Scrum. Lower part KanBan.

    Before iteration start:
    KanScrumBan

    We follow a 14 day iteration for the Scrum tasks. When planning the Scrum tasks we always take into concideration that we should deliver X numbers of KanBan task.

    WHY “KanScrumBan”? (Ouhhh…that was a lousy word)

    * Team responsible for both development of new features and maintance
    * The team likes Scrum tasks when delivering new features and KanBan when delivering maintenance (we have tried both KanBan and Scrum board)
    * If one team only did maintenance -> low morale. (We have two teams of 6-8 developers)
    * When two team members (we mostly work in pairs) have finished a feature they often feel committed to help out with a KanBan task…

  9. Pingback: Scrum y las ingratas tareas de soporte | reThink.net

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s