Home > agile, kanban, lean > Kanban Psychology. Can You Say No?

Kanban Psychology. Can You Say No?

Kanban looks so simple. In theory. Map your flow, set limits, draw some lines and stick stories on the wall. There you go. Is that it? Obviously, no. One of the hardest things is to change your behavior, shift from “push mindset” to “pull mindset”. And that may be tricky.

_toon18

You have Kanban board and there are no free slots in “In Progress” column. It means new stories should not be started — you’ve reached the limit. Developer comes and says “I know that there are no free slots, but I want to start this new small user story, since all the people are already working on the items and my help is not required”. You might think “Hmm, indeed we are moving forward with a good pace, this small story should not take much time…” and you say “OK, John, take it. I don’t think this would be a problem to exceed the limit right now.”

Two hours later Pete comes to you with a similar question: “I just completed my user story, testers will take it soon and I want to start something new.” You say “Well, we just took one story above the limit…”. Pete replies “Please, boss, I don’t want to sit and do nothing, I want to add some value, I am so much into work today!” Can you say no? I bet in most cases you say something like “OK, let’s do it!” to not discourage your teammate.

What happens then? Testers find some bugs in just implemented user stories, but there are no free developer to fix them. John and Pete are working on new stories. They may switch to bugs, but they’d lose focus and you have 2 stories in progress that can’t be passed to other developers easily (it will take time to make the transition and it looks like waste, isn’t it?). As a result, you deliver some stories later. Yes, later!

I understand that it is very hard initially to say something like “No, you’d better go and read something interesting about new technology. We can’t start new story right now, because if testers find bugs in some running stories, we should fix them ASAP, so we need a free developer”. Moreover, you should train your team to not ask such questions. WIP limit is a rule that should be followed. You may change it, but not arbitrarily. This change should have something behind (better productivity, more developers, etc). And this change should be discussed in retrospective meeting or during a Kaizen event.

I should say it is really, really hard to accept the fact, that sometimes developers and testers should do nothing (I mean do not start new stories when they are free). But it’s absolutely required to do so, otherwise pull system will not work.

Categories: agile, kanban, lean Tags:
  • morevisitor
    >They may switch to bugs, but they’d lose focus and you have 2 stories in progress that can’t be passed to other developers easily (it will take time to make the transition and it looks like waste, isn’t it?).

    I personally think that is wrongnew release air jordan and for more Hermes Kelly bags
  • carfield
    >They may switch to bugs, but they’d lose focus and you have 2 stories in progress that can’t be passed to other developers easily (it will take time to make the transition and it looks like waste, isn’t it?).

    I personally think that is wrong
  • Hey Michael,

    This is a great post.

    Production systems need to have a certain amount of slack in the system to deal with unforeseen events like you describe. Software is no different. This is a fundamental rule of Lean that we haven't fully ingested into kanban for software development yet.

    Why? Because just like you said, no one wants to sit around and do nothing. With manufacturing it's easy to have an extra machine sitting in wait. In coding, it's hard to do this.

    However, without this slack, the WIP is always maxed. Meaning you are running at 100% capacity and have no ability to respond to changes.

    Great post, thank you.
  • Nina
    Very good!
  • In our case it went smoothly. We haven't had a problem with people willing to break the limit. We broke limits only once - at the very beginning of setting Kanban up we had more tasks in tests than we should have according to the limit (we set the lower limit on purpose).

    I think the problem is really with the whole team feeling responsible for "pushing post-it notes from the left to the right side of the board." As long as developers see their task as just moving sticky notes through development column you may face above issues. If they care about making a task done (moving it to the very last column) they will ask you which task in testing is a blocker at the moment, not whether they can start another story.
blog comments powered by Disqus