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

Read more...

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.

Read more...

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.

Read more...

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

Read more...

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"

Read more...

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?

Read more...

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.

Read more...

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?

Read more...

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?

Read more...

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.

Read more...

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

Read more...

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?

Read more...

 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?

Read more...

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

Read more...

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

Read more...

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

Read more...

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;

Read more...

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

Read more...

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.

Read more...

Here is a real world story about Steve Jobs:

"I wish you could have seen Steve in action with Lee Clow of Chiat/Day, working on Apple's ‘Think Different’ campaign. Lee, the living legend whose creations ranged from the ‘1984’ Apple commercial to ‘Yo Quiero Taco Bell,’ showed an early version of ‘Here's to the crazy ones’ from the ‘Think Different’ campaign. A full minute of black-and-white pictures of Picasso, Einstein, Muhammad Ali, Rosa Parks, Bucky Fuller, amazing music and Richard Dreyfus reading this poem, seeing it for the first time brought the hair up on the back of my neck. So here I am, practically with tears rolling down my face, and Steve just looks at Lee, shakes his head, and says, ‘You've lost it.’ I thought, ‘What?! That's one of the greatest ads I've ever seen!’ And here's Steve going, ‘No. The music isn't right. It was right before. And you've changed the pace of the pictures, and you've got them in the wrong order.’ He sends them packing, back to LA. They came back after probably 30 hours with no bodily functions, and I was stunned. It was a lot better. Steve has a vision of what great is, and he's never going to settle for anybody else's standard of great.

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

Read more...