Pawel Brodzinski on Leadership in Technology

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

Tag: constant improvement

  • The Kanban Story: Small Tricks Do the Job

    On my AgileCE presentation on Kaban I said that if your Kanban board doesn’t evolve over time you should treat it as a warning sign. It possibly means you don’t improve workflow. And since there’s no by-the-book implementation of Kanban you should experiment all the time.

    So what has changed on our board recently?

    I can start with things which remain the same – this time we didn’t change structure of workflow. Columns are exactly the same. Limits stand still. But you shouldn’t consider at Kanban board being just a list of stations with appropriate limits attached. Kanban board is a single most important tool you use in Kanban. You look at the board a number of times daily. The more you see there the better is the board. This doesn’t mean we should make our boards completely cluttered. After all, if there’s too much in one place you stop seeing anything but clutter.

    OK, you already know we added something to the board. A few things actually.

    • Different sticky note colors. At the beginning we were working mainly on a single project. Recently we forked our efforts and now we work on 3 different applications. Getting separate color of sticky notes for each project was no-brainer.
    • Blocker flag. Visual mark of blocked feature is a small red sticky note attached to the main card. This is another obvious trick. We added it when we faced the first issue being blocked by external source.
    • Color magnets. We use whiteboard as our board. To make it visible who actually works on specific feature we put color magnets on sticky notes. Each team member has their own color. (Mine is white since I’m such an innocent guy.) Magnets give us quick information about load of each of us at any given moment. Besides, they keep cards from falling down.
    • Dates. We write two dates down on sticky notes. First when we start working on feature and another when we’re finished with the task. We keep forgetting about these dates, since this is pretty fresh idea, but that’s not a problem to fill them after a couple of days when we still remember well when we started/finished work on MMF. This trick helps me to report retroactively cycle time. Earlier I had to dig for information in task management system.
    • Numbers. Each sticky note has its own unique number. This makes it easy to link anything with MMF. A bug? We start with a number and everyone instantly knows which feature is defective. A task? We start with a number and we know which development tasks are related with MMF so we can tell how much work is remaining. We even use them in discussions: “Have you finished ninety seven yet?”
    • Excel sheet as backup. One day I thought what would happen if our cleaning lady would, well, cleaned our board. Man, we would be doomed. So I made simple sheet where I add information about every sticky note, which makes its way to the board. It is also a place where I store information about cycle time etc so it serves as reporting tool too.

    None of these improvements is significant. A few are pretty obvious. Yet when we were starting with Kanban we didn’t use any of these small tricks. They emerged as tiny improvements of the board and the process. And these small tricks do the job. Even though neither of them brings much value on its own they add up and make the board significantly better.

    As additional reading learn how our Kanban board evolved. Check out the whole Kanban Story too.

  • The Kanban Story: I Don’t Know, Experiment!

    I really liked Scrum versus Kanban session I made along with Piotr during Engineering Academy “Diamond Polishing” (both sites in Polish only). The theme of my part of presentation and the following discussion was the sentence I took from Henrik Kniberg must-read article on Kanban:

    “I don’t know, experiment.”

    – What kind of columns I should have on Kanban Board?
    – I don’t know, experiment. Our team’s Kanban Board looks like that. But don’t take is as a universal schema.

    – How many columns should be there?
    – I don’t know, experiment. See our board as example but don’t treat it as a bible.

    – What limits should I set?
    – I don’t know, experiment. Have I shown you our board we came up with? You know, that’s the result of our experiments, yours will be different.

    – How big should be the team to make Kanban most effective?
    – I don’t know, experiment. There are 5 of us, but your team is different I guess.

    – Should we put bugs along with MMFs on Kanban Board?
    – I don’t know, experiment. We don’t. Others do. How about you?

    – How long should we experiment before Kanban Board is ready?
    – I don’t know, experiment. We do it all the time because I’m never 100% happy. If you think yours is perfect than stop. If you change your mind then start again.

    If there’s one universal advice applicable basically to every light-weight method it is “I don’t know, experiment.” Light-weight methods leave many things flexible – you can apply them this way or another or don’t apply them at all. This creates a place for experimenting with what works well and what doesn’t.

    The less the method prescribes, and Kanban prescribes close to nothing, the more you can, and should, experiment. Especially that little prescription means you need to add some practices to run projects reasonably.

    Check out the rest of Kanban Story.