Crisp's BlogPage 28

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?

Here are the slides from my "What is Agile" keynote at Agile Tour 2009 in Grenoble. Sample slide: Take-away points: Agile is a set of values & principles that help you succeed with software development Agile is not binary Agile is not about specific methods or practices Agile is not a goal Agile is not

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

Last September I attended the UK Lean Conference in London (September 27-29) with colleague coach Joakim Sundén. That was an exciting conference. Not the least because it was the first time for me that I met in person the Lean and Kanban thought leaders that you can follow on the leanagile and kanbandev mail lists

The fixed price contract has been discussed here at the Crisp blog by others. It is broken by design as it creates more problem than it fixes.

On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.

The fixed price contract is not necessarily fixed price, a contract or evil.

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

Besides understanding the most important structures of a system, it is an architect’s responsibility to understand and influence the design principles.

One common and important set of principles are those of error handling. It is good to have the same principles throughout the system as it produces fewer surprises and mistakes.

In this post, I will discuss some principles that including checked exceptions and Null Object, which you may not fancy. But it is always good to think this subject through, so please come along.

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?

Here’s a new article for you: Cause-effect diagrams: a pragmatic way of doing root-cause analysis Cause-effect diagrams are a simple and pragmatic way of doing root cause analysis. I’ve been using these diagrams for years to help organizations understand and solve all kinds of problems – technical as well as organizational. The purpose of the

For those of you interested in Lean problem solving techniques, Tom Poppendieck and I have created an A3 problem solving example and template. Feel free to use as you please.

If you’ve read Michael Feathers’ book, Working Effectively with Legacy Code, you’ll know that he presents his techniques for refactoring clearly and simply. My favorite is his metaphor of finding the “seams” in the code to break it apart then “sew” it back together again. If you’ve attempted to implement some of these techniques in your own project you’ll also know that it’s not easy. It is slow arduous work, and when there are no unit tests it can be scary.

Crisp hosted Michael Feathers’ course:”TDD and Refactoring Techniques” this week in Stockholm. I hoped that some secret knowledge of how to refactor easily would be revealed, something that was just too elusive to express in a book. Instead my experience that refactoring is difficult was reaffirmed.

Continue reading

 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?

If you’re interested in Kanban I can recommend this course in Stockholm, there are still a few spots left. If you don’t know what Kanban is you might take a look at: http://www.limitedwipsociety.org/resources/ … or my article Kanban vs Scrum or (if you only have a minute) my cartoon One day in Kanban Land. My

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.

Check out Scrum Checklist version 2.0!

Here are the slides for my 90 minute session "Introduction to Scrum" at Agile 2009 in Chicago in a couple of weeks. The slide deck is mostly pictures and intended primarily for presentation use, not reading. So this stuff will probably make most sense if you attend the session.

I was recently invited to run for the board of directors of the Agile Alliance. After some initial hesitation I decided to go for it! The election will be held at the Agile 2009 conference on Tuesday, August 25 at 6:00 p.m. at the Hyatt Regency Hotel in Chicago. Voting can be done online as

Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.

I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?

Peer code review.

But enough. It just struck me how much I do not miss code reviews.

I’ll tell you why and I’ll tell you what is the replacement, because there should be one.

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.

On the Wicket user’s mailing list there was a question about modal windows and it set me off. Since my excellent wisdom 😉 is larger than just modal windows and Wicket, I thought that it would be of interest to all of you, dear readers.

I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.

A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.