Studio711.com – Ben Martens

I’ve never worked on a team that really used an agile process. Some claimed they did but they only went so far as to use it as an excuse to not plan. This new team follows a variation on Kanban that is being developed by another manager in our org, Brent. It’s spreading pretty quickly and I wouldn’t be surprised if there was a book written about it in the future.

I first heard about Kanban when I was an intern at John Deere in 2001. They used it on their factory flow to reduce the amount of money tied up in logistics. Applying it to software is similar: keep your total work in progress as low as possible. I won’t go into all the details here. If you really want to learn more, you can read Brent’s blog. (One of his most popular posts is how he implemented this with his kids for chores.) He has also started a podcast called AB Testing. But anyway, here are a few keys to how the system works:

• Every piece of work done by the team is represented by a ticket on the board.
• No ticket should take longer than two weeks to finish. All tasks should be trimmed down until they fit into this time window.
• All tasks move through these phases: Backlog > Ready > Analyze > Engineer > Code Review > Release > Customer Validation > Done. Backlog is the list of work that the team could do, Ready is a small number of tickets that the manager says should come next and the rest of the phases are a little more self-explanatory. There are specific criteria for exiting each stage and every ticket goes through every stage.
• Lightweight documentation is created in the Analyze phase to give background on the issue, clearly define scope and agree upon what “Done” looks like.
• Each phase has a limit on the number of tickets that can be in the phase at one time. There’s also an overall limit to how many tickets can be in flight in total for the whole team.
• Morning team standup meetings focus around what you need to do to get your ticket into the next phase and who can help you, NOT a status report of what you’ve been doing.
• When you finish a ticket, you don’t pick up a new one until you go through every other ticket and ask if you can help move the ticket along.
• There are special ways to track high priority issues and requests from outside the system.

it seems a little complicated at first, but once you get into it, it’s liberating! Here are some of the things I love about it:

• Coming on to a new team, this really helps you ramp up. Everyone is encouraged to work with someone else on every ticket. Solo tickets are not the norm. That means you can hop in with someone else and start learning about their area.
• You’re encouraged to pick up tickets from all areas that the team owns, not just your comfort zone. It’s a bit inefficient at first, but after a couple months, you have a team full of people that really can fill in for each other.
• At most, you have two tickets on the board at one time. Imagine only having TWO things to work on! You can focus and pound them out instead of constantly task switching.
• There is ALWAYS help available. The whole system focuses on really working as a team and moving the tickets through the system.
• It’s very clear how much work is getting done and how long it’s taking. Inefficiencies or choke points quickly bubble to the top to be addressed.
• This seems to avoid the slow buildup of responsibilities over time that you get as you stay in a group longer and longer. If you’re doing work, it’s on the board. And if it’s visible, it’s less likely to be stuff that builds up. The team will see it and find reduce the cost of those taxes.

This system has made it very enjoyable to ramp up with the new team, see the contributions I’m making, and focus on one or two very specific and well-defined tasks.