Sunday, December 02, 2007

Purging the Kanban Backlog

One of the PM’s in our office calls it a “clean out.” From time to time you should purge your kanban backlog to keep it fresh and relevant. The backlog is either a set of requirements for a project or program or a set of change requests for a sustaining engineering effort. There will always be new backlog incoming as the business changes and people have new ideas. Depending on this incoming rate compared to throughput of software delivery, the backlog may be growing, or at least not falling. A significant backlog is a problem. It affects your agility because things spend time queuing and that queue time is waste. Meanwhile, the request or requirement my be atrophying in relevance or ability to generate revenue as a differentiator.

Purging the backlog is similar to a bug triage effort. You simply need some criteria to decide whether something stays in the backlog or is dropped. It could be very simple. For example, “anything over 6 months old is dropped.” This simple rule fits with the real option theory nature of kanban pull prioritization. If something isn’t important enough to get selected over a 6 month period, it probably isn’t important enough - period!

Naturally, a more complex set of criteria is possible. You might want to assess the alignment with strategic, operational and tactical objectives of the business. You might want to assess alignment with particular customer segments or even specific customer orders. As we do, you might want to consider whether a change request is obviated with a forthcoming major release, or is requested on a system due to be decommissioned at some known point in the future.

Regardless, of your criteria, I’d recommend that you purge your backlog regularly, at least quarterly and perhaps monthly. Keeping the backlog healthy and relevant serves the business by simplifying prioritization discussions for kanban slots and by reducing queuing time and improving overall business agility from ideation to delivery of working software.

Related Posts: Kanban in Action, Recipe for Success Technorati tag: Agile, Lean, Kanban, Software+Engineering, Project+Management

Tuesday, November 27, 2007

Bugs and Kanban

Corey Ladas takes a look at two ways to treat bugs in a kanban system. The second option is the more challenging. It requires patient courageous management. My feeling is that option 2 will produce the net higher velocity (and throughput) in the long term because it teaches the team to really focus down on prevention of bugs while option 1 treats bugs as part and parcel of the business of software development. While option 1 will suffer a throughput reduction as bugs increase, there is far less incentive to focus on eliminating them altogether.

Ideally, I’d like to run a side-by-side comparison over a 6 to 9 month period to compare these two options. How are you dealing with bugs in your kanban system? Like option 1 or option 2 or do you have you own alternative approach? Technorati tag: Agile, Lean, Kanban, Software+Engineering

Wednesday, November 14, 2007

How big can an effective standup be?

This is a picture of a standup meeting on a large project at Corbis. Today I counted 41 attendees. The attendance has averaged 39 or 40 every day for 6 weeks. Daniel Vacanti can be seen far-left leading the meeting. The kanban board is behind him out of shot. [Not everyone is standing as some are sitting at their actual desks in the communal work area. This meeting happens every day at 9.30am. It’s generally over within ten minutes.

Corey Ladas has blogged about how the Lean Kanban process scales differently and how a standup can be effective with very large numbers of people. The key is that we don’t enumerate through the people asking them what they have done and will do and whether they are blocked. We enumerate through the kanban cards on the board and discuss whether work if flowing and what if anything is blocking it.

This project has 6 dev leads and 6 dev teams working concurrently. If this were a scrum project we’d have 6 independent scrums followed by a scrum-of-scrums with only the leads (assuming the lead is playing the scrummaster role.)

I see pros and cons to the big meeting. It is efficient. It gets the whole team together, not just the sub-teams. But it clearly isn’t as personal. And the claimed peer-pressure aspect of a scrum standup meeting is missing.

What we are finding is that some of the dev teams hold a brief huddle afterwards for just their own team. This is entirely optional, doesn’t happen every day and doesn’t (generally) happen in front of the kanban board - more a design coordination meeting than a project tracking meeting.

Is anyone else running standup meeting with larger than the recommended scrum size of 6 to 12? What are your results? What’s the largest effective standup meeting you’ve been a part of?

Photography: courtesy Laurence Cohen
Related Post: Lean Scales Differently than Agile, Corey Ladas Lean Scales Differently than Agile Technorati tag: Agile, Lean, Kanban, Software+Engineering, Scrum, David+Anderson, Corey+Ladas

Thursday, November 01, 2007

Kanban Warranty Claims Processing

Tom Hopper has implemented a kanban board for processing warranty claims following his attendance at the Lean New Product Development Summit in Chicago earlier this year.

Related posts: Lean NPD Summit Report

Tuesday, October 30, 2007

Javapolis Sessions

Here are the full abstracts for my two official Javapolis conference sessions…

UNI: (Monday 10 December) The Zen of Agile Management

What is the essence of agile management? How do you create a culture of continuous improvement? With light touch, empowerment, delegation, high levels of trust, and focus on the correct leverage point to drive maximum advantage. Learn the Zen of agile management! A set of techniques developed by David J. Anderson over the last 8 years through his experience managing teams at Fortune 100 companies such as Motorola and Sprint using Feature Driven Development, Microsoft Solutions Framework (and Team Foundation Server) and his latest work at Corbis using Lean ideas such as kanban. This half-day workshop dives into the heart of how to manage with queues using kanban boards, cumulative flow diagrams and application of wider ideas in management science, to software development process. Through David’s experience as senior director of the software engineering function at Bill Gates’ private company, Corbis, you will learn how to scale Agile and Lean techniques enterprise-wide.

CONF: (Friday 14 December) A Kanban System for Software Engineering

Ideas from Lean Thinking have been growing in popularity with the Agile software development community. Over the past year, the use of kanban (literally signal cards) popular in manufacturing has been seen as the significant innovation in managing agile work and is growing in adoption at firms such as Yahoo! David Anderson introduced the first electronic kanban system at Microsoft in 2004 and has since extended the technique through his work at Corbis. Kanban acts to limit work-in-progress and focus the team on achieving a continuous flow of value to the customer. Kanban innovates on accepted agile management practice by providing an iteration-less process with a regular release cadence. It helps achieve a balance of demand against capacity on the team and eliminate multi-tasking. David will present a brief history of the technique through case study reports from teams at Microsoft and Corbis. The kanban system enables David to deliver on his Recipe for Success: focus on quality; reduce work-in-progress; balance demand against throughput; and prioritize. Technorati tag: Agile, David+Anderson, Agile+Management, Javapolis, Kanban, Software+Engineering