Mattias Skarin's blog

The invasion of Lego robots

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:

Video from Introducing Kanban in operations

A video of my presentation at Devopsdays'09 in Belgium is now available.

I didn't wear a microphone so you might need to pop up the the volume :)

If you are more interested in the slides check them out here

Pair program your roadmap

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.

The book is out!

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.

Manage the normal - treat exception as exceptional

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 :)

Personal Kanban

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"

West vs. Japan

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?

Speaker at Lean Conference, Atlanta 2010

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.

Four strategies for dealing with breaking WIP limits

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?

The Manager Sanity Check

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?

Devopsdays'09

My slides from Devopsdays'09 in Belgium.

It is inspiring to see the number of system administrators looking into Kanban. Myself I discovered Cucumber scripting.

Thanks to Patrick who pioneers a great conference for system administrators and developers.

Know your continuous improvement

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

The responsibility model

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.

Denial - ‘Problem? What problem? There’s no problem.
Blame – ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
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.’
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?’
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).’
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?

The problem solving algorithm

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:

Surface problem
Concretize problem - write it down! (what, when, how, who)
Find root cause
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?

Why cycle time can tell you more than velocity

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

Team velocity of a the Starship team. Number are weeks, the colors
represents different categories of work.

It is quite hard... There are too many variables distorting our data. Do we having a problem with estimating? Or is available man days fluctuating? How do we know?

This problem gets accentuated as we try to plan releases. If we went on and made a made a release plan based on this velocity, what predictability can we expect?

Stop runaway meetings with the timeout sign

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 Scrum is running fine, right?

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..

What to refactor?

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;

Learn Kanban from the source - Kanban Jedi training class

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.

You will learn how to	Who can benefit from participating?
Start up Kanban Draw a Kanban board Set up measurements Drive continuous improvement with Kanban Advanced concepts such as risk management with Kanban	Developers Project managers Product owners Line managers Coaches & trainers

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

It is not the process, it's the improvements

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.