What I'd Do Different

In my last post I mentioned a few things I'd like to do differently in my next new dev project where we utilize Kanban. I sat down with our PM, Elizabeth, and we did kind of a mini-project retrospective, and what we could do differently from the Kanban side of things to help things flow along better.

The first thing we thought would help would be to get better info on the cards, and to treat the cards as Minimal Marketable Features. Across the top of the card we'll put the feature number, name, and its time estimate. In the middle of the card, the description and any task breakout that's needed. Across the bottom we'll stick with the WIP start and end dates, and the cycle time will go between them once it's complete. The back of the card we'll put actual developer and tester times, and then once complete total that and put it on the front of the card under the estimated time.

This will accomplish a few things for us. First, on the dev side of things, it gets that task card breakout thing out of the way and allows us to track the features across the board as a single entity. Secondly, it gets more project management info clearly on the dev card, which makes it much easier for people not knee deep in the project daily to keep tabs on what's going on.

The second thing we thought should be implemented the next time around is an extension of the board, to the left. Our board for this one had a bullpen column where features were in holding waiting for the tasks to breakout. From there, they moved into the backlog, and into work in progress.

Our idea here is to break that bullpen column out into another Kanban section where discovery, design, and estimation takes place. Once that is complete the feature can wait in a "Ready for Dev" status and be pulled into the backlog column on the development Kanban board when the set trigger point is hit.

Elizabeth and I went back on forth a bit on where the bullpen board would reside. Initially I wanted to see it isolated from the dev team so they could concentrate solely on the dev tasks at hand. However, Elizabeth's persuasive abilities (strawberry cake with white icing may or may not have played a role here) led us to the conclusion that it should all be one board. This allows the developers to be aware of what's in the pipeline coming at them, lest they relax a bit too much at a critical point in the timeline. And, it allows the dev side of the board to pull from the bullpen as features are estimated and ready to go.

Finally one last thing we thought we'd employ would be different sized cards for different sized features. If we can't get all features to breakout into a similar estimate range, which is a very real possibility, then maybe get two or three ranges and denote them with different sized cards on the board. This would allow for different cycles to be tracked based on feature size, and a quick look at the board would tell you what type of features are moving through the system at any given time.

I think these changes to our approach will help the next new dev project where we employ Kanban. We used it successfully before, but I think this will help get more features into done with less friction for the whole team. Which means cards will get put in the envelope above this lovely lady's picture in a shorter cycle. (Whiteboard drawing courtesy of Dan Shultz.)