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.
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.
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.
