Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: pitfalls

  • Pitfalls of Kanban Series: Abusing WIP Limits

    This is another problem that comes in different colors. It’s either simple acceptation of WIP limits violation, no matter how commonly it happens, or setting WIP limits so high that a team never gets even close.

    Now, I don’t say that violating WIP limits should be forbidden at all. Pretty far from that. I just say that if it is a common thing it basically means that you have no limits at all. The same is with too loose WIP limits – it means no limits at all. It’s always a matter of balance: when and why you accept to violate WIP limits.

    I point this issue high on my list as basically not using WIP limits means that you voluntarily resign from the biggest gain you can get out of introducing Kanban – the rate of improvements and changes you introduce in the team is way slower. It is so because WIP limits are a mechanism that incentivize people to change their behavior (they would normally do one thing but they can’t as it would mean violating WIP limit so they do another). Without changing behaviors most changes are quickly rolled back to what people know and feel comfortable with.

    When you start thinking about the issue it may be a very complex one and as such may be approached from different directions. One thing which is pretty obvious: make abusing WIP limits painful. I don’t mean here physically painful of course, but add enough hassle that people would think twice before doing it.

    A neat trick I used was that every time someone wanted to violate WIP limit they had to organize a meeting with a team and tell everyone why they’re doing so. First, organizing a meeting, even an ad-hoc one, takes some time which you may use to rethink whether this is really needed. Second, you want to have pretty damn good reason to share as everyone will like to know why you’re breaking the rule. Actually, if you could come up with good argument you probably had a point in violating a limit anyway. You can use other similar methods as well, but basically the goal would be the same – to make abusing limits reasonably uncomfortable.

    Different approach will be needed to deal with unreasonably high WIP limits. A thing that may come handy in such case is measuring WIP over a period of time. It is an interesting observation but some teams believe that they actually have more WIP than they really do. In such case once you’ve measured your work in progress you shouldn’t be scared of limits. Even more, your initial decisions on WIP limits will be informed.

    Another idea is to reduce WIP limits periodically to see what will happen. Eventually the team would find their sweet spots, where limits are tight enough so that they’re incentivized to improve but loose enough that the inconvenience of having WIP limits is acceptable. It is like playing ball flow game, but on the real work done in a real team.

    Check the other pitfalls of Kanban as well.

    Advertisement: Infragistics® NetAdvantage® for Windows Forms provides developers with flexible, advanced controls to rapidly build high-fidelity Windows Forms application user interfaces “IN” style with the look and feel of Microsoft® Office® 2010 and Windows® 7. It Features every control developers need to deliver superior user experiences with stability, performance and robustness.

     

  • Pitfalls of Kanban Series: Kanban Board Not Up To Date

    This is something I see very often and at least in a couple of flavors. The problem can be a team member who haven’t really bought the whole thing and see little value in updating all these stickies on the board every time something changes. It can be more a whole team’s thing – Kanban implementation has its leader, or a champion, and when they have a day off suddenly the board starts to deteriorate as people don’t feel pushed or obligated to update anything.

    On a side note: I would put it on the same shelf in my mind as when Scrum teams don’t do daily stand-ups when a leader is out.

    This issue is tricky as it doesn’t seem to be much harmful but, if tolerated, it basically renders the whole Kanban implementation useless. The first step we do with Kanban is we visualize all the work. Basing on that we make informed project decisions every single day (with help of WIP limits, explicit policies etc.)

    Now, if the board isn’t up to date these decisions are made on a basis which doesn’t reflect the reality. We may violate the limits or cease to help a colleague with a critical issue not even knowing about that. This way, not only do we make suboptimal everyday decisions but we also cripple the biggest power of Kanban – its improvement mechanism.

    Potential solutions of this problem depend on what flavor of the problem you face. If it is a single person you can work with them to convince them there is value in updated board for them too. You can also ask them to give everyone in the team a credit of trust and give a method a try for a few weeks or a couple of months. It usually is enough to turn them back into the light side of the force.

    However, in the worst case scenario you last resort may be setting up a proxy who updates the board instead of a problematic person. It will be a hit on team’s morale (“we have someone who is treated differently”) but it’s a tradeoff some teams are willing to make. Especially that, eventually such person either changes their behavior or leaves a team.

    If we think of a whole group not updating the board it is a signal that there’s little or no buy-in for the idea. Unless this can be changed most likely the Kanban implementation is doomed.

    The way of getting team’s buy-in will of course depend on people. However, I find it pretty successful to ask the group to give the method a try. Of course considering there is a problem I believe Kanban can help to fix quickly. Thanks to simplicity of Kanban it doesn’t cost much hassle to “try it” and pretty often first results are rather quick as almost always teams have some low-hanging fruits in terms of improvements they can make – quick wins they just aren’t aware of.

    Read the whole Pitfalls of Kanban series.

  • Pitfalls of Kanban Series

    One of tricks I sometimes use when coaching teams that are starting with Kanban is I tell them why they shouldn’t adopt it. Challenging the team in such way helps me to indicate whether there is buy in as this is crucial thing to deal with issues the team will face.

    I do that knowing that, thanks to its flexibility, Kanban is pretty vulnerable and even a single team member may cripple Kanban implementation, thus vastly reducing value the whole team gets from adopting the method. Besides getting buy in having knowledge of these potential vulnerabilities can be a game-changer as then the team can avoid them.

    This was the idea which stood behind my session titled Kanban weak spots which I presented at Lean Kanban Central Europe last year.

    Recently David Anderson started an email discussion that inspired me to write a follow-up on the subject. As I was typing an answer to David’s questions I realized that it would be worthwhile to discuss each and every pitfall in details, covering reasons why it may appear and tools that can be used to deal with it.

    And this is how the idea of this series was born. You can expect a number of posts covering just a single Kanban weak spot. The whole list will be gathered here: