Thursday, August 11, 2011

Why we went Kanban

I don’t think any single process is the best fit for all teams. Teams and projects using Scrum, Kanban, Waterfall, or any other custom process you can think of have been successful in the past. In my opinion, the most important thing to keep in mind is that the process should be constantly evolving, similar to the software that you are building.

We recently started a new project off with 1 week iterations as they seemed to be a good balance between a client who was coming from a waterfall background and our team, who was experienced in agile development eager to get show off completed functionality as soon as possible. A few retrospectives ago, we found a number of us were openly questioning why we weren’t using Kanban. So as any adaptive, continually improving team would do, we switched. There are a number of reasons for moving to a pull based model, but here were the top ones for our team.

Estimates were WASTE

We performed our demo, retrospective, and planning on Friday of each week. This was usually accomplished in 4 hours or less but by far, the most significant portion of that time was spent discussing and estimating the stories for the next week. We continually struggled to balance how much discussion was needed to properly understand the solution without totally solving the problem within the discussion. With a team of 4 or more developers, the time spent determining whether or not a card was a 3 pointer or a 5 pointer was not trivial. It was however WASTE, and it leads me to my next point.

5846058698_809e782a00_b

Track output, not arbitrary numbers

We had been tracking overall burn down based on the number of high level stories identified anyway so the specific number of points that we accomplished in any given week were just a number. Across projects that I’ve been a part of recently, the points and further, velocity as a weekly total of those points, generally winds up becoming at best an arbitrary number and at worst a point of contention or undo pressure. Clients wind up believing that the team is gaming the number of points and the team has to listen to the endless sighs and groans when a card is estimated at 5 points. Screw the points. Get rid of them and instead track either how many cards are being accomplished over time, or better yet the cycle time of cards.

Planning sessions are no substitute for conversations

Another bad habit that we had gotten into was trying to provide cursory information on a card or in TFS work items, discussing that during the planning session, and then just kicking the feature over to the developers to work on during the week. Cards need to be a promise for a future conversation. Without some level of collaboration between product owner and developer, you really don’t get all of the detail flushed out. Further, doing that conversation in a long meeting a few days prior to starting the work inevitably results in details being lost or having to be rehashed in the form of defects or new cards. Since moving to Kanban, we began to execute conversations about the cards in real time much more often. This has inevitably led to less defects or missing requirements coming back into the system.

What’s going to work?

Teamwork! Our project had a couple iterations where our product owner and QA were frustrated by the lack of time they had to test the application before demoing to end users. Ultimately the team is to blame and should’ve realized that having 8 features partially tested and completed is less valuable than having 4 features DONE. When developers are prohibited from pulling another feature forward until stalled cards in QA are moved to done, they immediately begin helping in areas they might otherwise thumb their nose at. It also facilitates in focusing product owners and BA types on keeping a nice stack of prioritized stories ready for development. 

user-stories

Better Stories

Kanban doesn’t write your user stories or even provide better visibility into your user stories. It does however, eliminate some boundaries that are counter productive. When a team feels that a user story must be decomposed into chunks that fit nicely into iterations they may begin to create cards that have many interdependencies. If a project has a bunch of interdependencies within user stories, it will also have significant issues with stories not being testable until other stories are done. Is it worse to have a story that spans an arbitrary segment of time or to have 4 developers all stepping on each other trying to complete small portions of a single large story? In my opinion the former is much better and Kanban doesn’t prohibit it.

I don’t believe everyone should change their process to Kanban. I do believe everyone should evolve their process, though. Kanban definitely seems to be the better fit for our group, but I’m confident it will continue to change before our project is done. In the last couple of weeks using it compared to the prior months of doing weekly iterations, we are communicating more, resolving defects in real time, and collaborating with our product owner much more tightly. This works for us, but as always, use your noodle to determine what works for you. Most importantly, don’t be afraid to change it up!

Numbers photo courtesy of c a r a m e l on flickr. User Stories photo courtesy of jakuza on flickr.

6 comments:

mgroves said...

boo for Wonderpets reference

asdfasdf said...

So did you find most of your stories to be similar in complexity/size?

Todd Kaufman said...

@mgroves, my fatherhood is showing!

@asdfasdf No, we actually had started off categorizing our stories as small, medium, and large when we moved to Kanban which wasn't too different than our 1, 3, 5 pointing when using iterations. We've seen that the stories have probably shrank to an average of somewhere between a small and medium though after using our Kanban board for a month or so.

Andrew Fuqua said...

Hey Todd.
I'm curious how you apply your cards/unit-of-time metric (your "overall burn down based on the number of high level stories"). In some projects I've found the /release/ backlog to contain stories that are larger than development wants to tackle as a unit of work. Therefore my metrics are on smaller stories than the backlog so I can't project a project completion date (or tell management how much we might get done by the release date). How have you tackled this?
Thanks!
andrew

Todd Kaufman said...

@Andrew

I tend to use cycle time (or even per iteration velocity) for monitoring anomalies. I don't use it at all for overall project burn down. For that I use some level of user stories. These are typically larger than the cards we move through the board. I monitor what comes out of the board every week and work with the product owner to mark stories done when all of the sub tasks or sub stories for it are done This is more work to track but it gives the team a healthy indicator (cycle time) and the product owner a good metric for overall progress.

Andrew Fuqua said...

Gotcha... I think. On my 1st reading I glossed over where you sead "estimating the stories for the /next week/". I don't think I've ever estimated without the intent of release planning.

Where you say "...gives the team a healthy indicator (cycle time) and the product owner a good metric for overall progress", I guess you mean a good metric for iteration progress, not release progress.

Sounds like you just use a count of stories for release planning (velocity), assuming that on average, the average story is the same size.

Thanks!