Pawel Brodzinski on Leadership in Technology

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

Tag: best practices

  • The Kanban Story: Kanban Alone Is Not Enough

    Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.

    I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.

    What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.

    We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.

    All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.

    So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.

    Read the whole Kanban Story.

    If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.

  • The Kanban Story: What We Do and What We Don’t Do

    Last two posts of the series (on Kanban Board and on setting up whole thing) were Kanban implementation-in-a-pill kind of story. As you may guess that’s not all since Kanban doesn’t prescribe many things which you can use and, most of the time, you do.

    To show the big picture there are two lists: practices we use and these we don’t.

    Things we do

    • Cross-functional team.
    As I mentioned at the very beginning (the_beginning) we have cross functional team which is a great thing. Virtually every action connected with our product in any way is performed within the team.

    • Co-location.
    We sit together in one small room. That’s so damn great. I wouldn’t change it for private office even if you paid me.

    • Roles.
    We have old-school roles within the team. Developers who, guess what, develop. We have our commando guy who mixes roles of QA, system administration and maintenance. He could work as our bodyguard too. My role is project and product management which in our case could be called Product Owner as well. We also have a guy responsible for business development. Nothing fancy here. Everyone just knows what they’re supposed to do.

    • Measuring lead time.
    When I initially wrote a draft for this post this was on the “things we don’t do” list. For some time it wasn’t needed much since with no production environment it wasn’t crucial to know whether specific feature will be ready in 2 weeks or rather 16 days. Now, as we need more precise estimates, measuring lead time emerged as useful tool so we started doing that.

    • Continuous improvement.
    Implementing Kanban was an improvement to the old methodology. Starting to measure lead times was another. We look for tools or frameworks which improves the way we develop our products in terms of speed, quality, code readability etc. Nothing fancy here – we just try to make our lives a bit easier whenever we can.

    • Unit testing.
    We write and maintain unit tests. We don’t have 100% coverage though. I trust our developers would write unit tests wisely. Most of the time they add unit test covering a bug scenario as they fix bugs too.

    • Continuous integration.
    Oh, is there someone who doesn’t do that?

    • Static code analysis.
    There are coding standards we follow. They’re checked during every build. After a couple of weeks coding standards became native and basically invisible so it’s hard even to say that it’s a real practice.

    Things we don’t do

    • Iterations.
    At least formal iterations. We don’t have sprints whatsoever. To bring some order we group some features and call them “iteration,” but that’s nothing like scrumish iterations. I’ll write a bit more about our pseudo-iterations soon since that isn’t something very standard done by-the-book.

    • Stand-ups.
    We have permanent sit-downs instead. Whenever something needs to be discussed we just start the discussion not waiting for morning stand-up whatsoever. No-meeting culture works surprisingly well so far.

    • Formal retrospectives.
    Same as in previous point. We just launch “I don’t like it, let’s change it” kind of chats whenever someone has some valuable input. You could call them informal retrospectives on call.

    • Burndown charts.
    We have no fixed scope within iteration to burn since we don’t have real iterations. I occasionally draw burndowns for a specific feature (a single sticky note). I do it mainly to check how my well works schedule simulation (estimates plus statistical analysis).

    • Code review.
    I’m a big fan of code review. I tried to implement it twice in my teams and failed twice. As long as developers won’t want to do code review I’m not going to force them. That just doesn’t work this way.

    • Pair programming.
    This one I don’t believe in. So do our developers.

    • Test driven development.
    We write unit tests. We do this after not before. This is another practice I’m not a big fan of and another which takes people who strongly believe in it to make it work.

    If I forgot to mention something on either list just let me know what I omitted and I shall provide update.

    I encourage you to read the whole Kanban Story.