Mattias Skarin

It was a blast meeting the Agile community in Estonia. What a vibe!
More to come on that subject .)

Anyway, here are my slides:  "Mind over matter"

Cheers

This other day, I stumbled upon an article by John Seddon  – "Rethinking Lean Service" which had been laying around in my disk space for a while.

It struck me how these principles can be deployed using a Kanban system:

• design against customer demand : create the kanban board starting with the demand
• focus on value creation over cost elimination: set highest priority in completing work before accepting new. Use WIP limits to ensure that is happening.
• know the actual time it takes to complete the transaction as "one stop" : learn the cycle time of flow and use this to plan resources rather than spent time

Maybe Kanban is well suited for services?

Me and Henrik’s book have now been translated to french.

Through the admirable effort of Claude Aubry, Frédéric Faure, Antoine Vernois and Fabrice Aimetti, you can read it here:

http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/

How do you go about converting a development team from Scrum to Kanban? Can we benefit from incremental improvements in projects under high pressure?

Here is a case study of a team who transformed from Scrum to Kanban and managed to save a derailing project. I hope it can inspire others to experiment and improve.

Some of the things I learned:

• Incremental improvement  works, even under high pressure
• Key problems are typically cross functional. The better you are in building a cross functional momentum – the faster you’ll overcome them
• Kanban works as a tool for incremental improvement
• Quality over speed – always more important than the tool

(… and I have a far way to go until I can order a proper cup of tea and a croissant 🙂

Anyway, here’s the link:

Converting a Scrum team to Kanban

Is this years final series in the Swedish hockey league, there is one team that standing out from the crowd. They are more stable, persistent and thorough in every part of their game than the other teams.

Today I stumbled over this comment from one of the players. It highlights a mindset I have seen in both software and sports team that basically felt unstoppable.

"If I am going to think about this victory on the way home? No. I am only going to think about the details that is going to make us better in the next game" 
           – Jimmie Ölvestad

As a part of this weeks Kanban Applied course, the teams had to solve problems using Lego robots.

It was good fun. So fun teams almost forgot about Kanban 🙂

Programming the bot:

Doing a road map can be a tricky thing. There are plenty of constraints and dependencies to consider: how to we balance long and short term improvements? how do we rate future revenue opportunities for our clients? how well do the separate steps tie together to a coherent product? is this fun and challenging? are we keeping our team motivated? can we stop half way?

I find that pair programming is by far the fastest way of traversing the decision tree. Basically, if you are a Product Owner, construct the road map together with another person. Lay out the plan that best meets the constraints and business goals and let the other question the options. (Of course, don’t forget to switch).

Altogether, it helps you check  the different options and prepare arguments. You will be better prepared when meeting the stakeholders. For when you do, there is always something uncertain waiting for you.

My and Henrik’s book on is out. Get a downloadable version, or buy the full copy at InfoQ. The book includes: Foreword by Mary Poppendieck and David Anderson A comparison of Kanban and Scrum – their approaches as process tools in software In-the-trenches case study of introducing Kanban in operations Hope you enjoy the reading!

For further reading about the case study,  see my presentation at Devopsday’s 2009.

Ever had this thrown at you?

"This production bug is unacceptable, it must never happen again!"

And that event, outside your systems control, formed a policy that affected all your every day life. Failure to distinguish between uncertainty under our control and uncertainty imposed by outside events is a bad management habit.

Instead;
"Manage the normal – treat exception as exceptional"

And have a happier life 🙂

Feeling busy? Not ready when the deadline approaches? Many things in action?

Maybe you should consider a personal kanban. Now,  I will admit the first to admit I heard about the concept I thought "but isn’t slight over administration? What about just saying no?" But not all events are under our own control and as this story will tell; I’m now convinced it actually works.

The personal kanban can help address three problems:

• "Constant reprioritization"
• "I need to be able to focus"
• "I want to feel the reward of completing work"

Why do we level out? In many agile teams I have met the introduction of Agile methods have made the teams to take a big leap. But then, after a while, they level out. Why so?

I will present at the Lean Software & Systems Conference, April 21-13 in Atlanta.

 Looks like a promising event, with speakers like Don Reinertsen and David Anderson.

Ps: There are some new exciting events in Stockholm this spring coming up with David Anderson, stay tuned.

Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

Last weeks have been busy!

• We ran the first Kanban training course i Stockholm with David Anderson. The training class got a 8.5 score average out of 10. I really enjoyed the skill and experience  of the participants as well as David’s many "off topic" discussions.

  

• The first Limited WIP Society meeting arranged in Stockholm brought 50 people(!). Besides sharing kanban stories (and a beer or two..:)  we managed to gather 20 people in playng the bottleneck game in the open space session. In the stories shared the simpleness of applying Kanban to an existing organisation was a common thread.

  

Talks I have held,

• NFI – Från krav till system, Var är mitt krav? Följ det med Kanban (slides in swedish)
• ScanAgile 2009 – Getting Agile in system administration and operations
  -> Great to meet some old finnish collegues!

Talks – upcoming

• Devopdays 2009, Belgium – Introducing Kanban in operations

Continuous improvement ( "kaizen") is a core process within Kanban and/or Scrum.

But what does it mean?

Here is an A3 I use to explain the concept

At the Lean Software conference in London Portia Tung tipped me off about Christopher Avery’s responsibility model. I need to show it to you.

1. Denial – ‘Problem? What problem? There’s no problem.
2. Blame – ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
3. Justify – ‘I guess it’s possible that I’ve become insensitive to other people’s feelings and needs. I can’t help it though. After all, I’ve been doing this job for a long time. It’s who I am.’
4. Shame – ‘What have I done? I’m going to look such an idiot in front of the people at work. How am I going to live it down? Why should they help me after the way I’ve behaved?’
5. Obligation – ‘Tell me what you think I should do. I have no choice but to do it (even though I don’t want to). I’ll do whatever you say. It’s only a job after all (no one can expect to do a job they love).’
6. Responsibility – ‘I can wait for them to change but that could take forever. No, it’s up to me. I want to fix the problem. So how am I going to be a better colleague? I know! I’ll listen more. And be more considerate towards others. It’s a start.’

Now test yourself –  just how professional are you?

 I have been watching several discussions over the years between brilliant people where clear perception of the problem prevented them from solving it.  It is so easy to marry ourselves with our suggestions of action (how) that we loose focus about  what the nature of the problem really was.

For cases like this, I advice teams to follow this problem solving algorithm:

1. Surface problem
2. Concretize problem  – write it down!  (what, when, how, who)
3. Find root cause
4. Surface ideas  (start with those that helps improving the existing situation)

For seeing situations like this, I try to keep the following "aha" reminders in the back of my head..

As an arguing manager, if I can’t concertize the problem it is a sign I need step back and put the right decisions into the right hands – the people closest to the problem.

As an arguing engineer, have I progressed towards engineering a solution, or even evolved into solving another problem (which I felt needed to be sorted first), before concretizing it’s nature with my counter part?

Take a look at this chart and tell us how we are doing?

Sometimes it is hard to stop a running meeting. You might have someone so fond of talking he doesn’t realize time is up. Or the daily stand up has gone haywire. How do you break in, politely?

Teach everyone the timeout sign.

  "hey, let me get back to code"  🙂

Your team is coding along, sprints are passing by, your somewhere around sprint 15.. life is ok..  ..or?

As a famous test leader once said:
"Team are happily completing sprints but nothing gets’s done"

Here are a couple of  things to look out for in your Scrum organization..

It is not uncommon I run into a team coding a system in desperate need of refactoring,  at the same with huge pressured to move things out of the door. When trying to refactor we face the bad news of doing nothing but refactoring..

So we need to be a bit more clever. He are two ways;

On September 24-25:th in Stockholm, there is a chance to learn Kanban directly from the source!

Kanban is framework to help improve efficiency and continuous learning, but with a very light weight footprint. It works both in- and outside software environments.  Support is one example.

Hosting the training is David Anderson, one of the most experienced practitioner in the field. So it is a great opportunity to learn from the source.

http://www.crisp.se/kanbanjedi

For those of you who wonder "why would anybody convert a Scrum team to Kanban" (see earlier blog) – it is important that you understand the true intent. (..yes there is one! 🙂    What expected output do you have from a process framework?

This important "why" question is often left out in the debate. The heated "Scrum vs Kanban" discussion is a good example. Try yourself  "why are you using Scrum"? (or Kanban). At what point would you throw the tool out for not delivering?

It is no wonder debates turns heated if we disagree on where we are heading. But if we instead start with clarifying intent ("why") – then the actual choice of tools becomes less important (more like a boring context summary 🙂

Why then? How do you know that the process tool works for you?

• First (obvious) – it helps you deliver running software.
• Second (less obvious) – it makes you do continuous improvement effectively

If you are getting results from continuous improvement – your tool is right. If it is not happening, it is probably wrong. (check yourself, what improvements have you benefited from lately?)

This was the main reason I chose to implement Kanban in the Scrum teams. It was not because the sprints where not delivering, it was because the improvements didn’t happen.

Here is a real world story about Steve Jobs:

(Excerpt from an interview with Ed Niehaus at Coopers Journal, full story here)

Two views:

• I’d love we had more product owners working like this! Not about making an ad campaign that has to be this or that, – it’s about making a great experience!
• How would we have experienced Steve in any other role? Probably like a egocentric lunatic complaining and whining  "not good enough" all the time. A "non team player". People like Steve are rare but when whining they simply express a need for role where they can outlive their excellence. Our job is to create an environment so that can happen.