Pawel Brodzinski on Leadership in Technology

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

Tag: process 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: Kanban Board Revisited

    Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.

    We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.

    When we left the board last time it looked like that.


    What was the problem?

    On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.

    Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.

    The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.

    After playing with some ideas we came with version 3.0 of our Kanban Board.


    What has changed?

    The left part hasn’t changed at all. We were happy with it.

    The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.

    Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.

    Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.

    Limits

    Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.

    Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.

    The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.

    The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.

    “Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.

    Looks like we get more and more columns over time. I just wonder whether that’s a good thing.

    If you liked the post you may want to read the whole Kanban Story.

  • The Kanban Story: Implementation of Kanban

    So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

    There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg’s article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

    Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

    The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server… OK, just joking here.

    Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t “marketable” at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

    To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

    Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

    Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

    Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

    Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

    I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.