From AOCWiki
Host: Michael DePaoli (Agile Coach, VersionOne (http://www.versionone.com) )
Bill Dominguez (Agile Coach, Shojiki Solutions)
Participants: Dave Smith, Tom Moore, Tom Lody, Alida Cheung, Shane Duan, David Mcleod, Steve Bockman, Jeremy Lightsmith, John Donahue, Brian Chan, Dirk Wippermueller, Jeffrey Frederick, Jim Sun, Trevor Morris, Mike Wright, Moira Wilmes, Vickie Hall
Session notes:
We started with a discussion of common problems that occur on agile and non-agile teams with unplanned work,bug escalations Examples: Startups that don't usually have the goal of shipping a product in the short run, rather they need to achieve their next round of funding. This can cause a highly volitale set of priorities.
Companies that allow technical debt to get out into the wild begin to get escalations from customers about problems. This only increases as more debt is put out into the world. Teams that don't have a way of dealing with this that are following an agile approach like Scrum will be very frusturated and frequently won't have a useful velocity.
To address this problem an example was given where a team implemented a defect threshold. This was explained with a metaphor where delivering a release was equated to landing a plane. Teams that allow for the amassing of defects during a release create a situation where they frequently can't land their plane because the find / fix rate of defects doesn't approach a smooth landing approach. Their plane keeps bouncing back up. This happens because of the complexity of defects that have been built upon other defects. Frequently bug fixing in this environment treats symptoms of a bug and not the root cause. Also, the more complex the situation the more likely fixing one defect breaks code in other places (more defects).
Mike gave an example of a team that put in place a defect threshold that basically set a maximum altitude' the release could fly at in terms of number of the amount of time to fix defects. So, the particular team set this ceiling at 3 weeks. Therefore, no developer could continue to work on new features if their bug backlog hit the defect threshold. This policy always kept the release at an altitude that could have a predictable landing. This was a basic
application of Work In Process Limits (WIP).
Bill introduced the concept of the Lean Agile Prism which is an extension to the traditional iron triangle of project management by adding 3 other facets, those being Value, Quality and Innovation. More information at www.shojiki-soltutions.com.
Bill and Mike also introduced kanban as a way to implement pull based processes for a team and explained the use of WIP limits to eliminate waste in the value flow (workflow). Also it was explained for for continuous process improvement to occur, there must be slack in a process. Case in point, it is frequently the case that QA is a bottleneck in software development value flows. If all the other operations upstream from QA continue to produce inventory to drop at QA's door step, this is push based planning and not pull based and is not respecting WIP Limits of the upstream steps in the value flow. If instead, when QA's WIP limit was reached, the dev teamwould stop pulling in new items once they reached their WIP limit, there would be slack created for the dev team.
With this time, the dev team can spend time on process improvement, innovation or just helping QA to eliminate the bottleneck for the moment. Once the bottleneck is evaluated from a value flow perspective and this issue is addressed, it is inevitable that another will occur, hence continuous process improvement. By having slack in the value flow occur because of bottlenecks allows us to identify the bottlenecks. If every operation in the value flow is unbounded by WIP, you can't truly identify the issues.
Bill also introduced the concept of an Organizational Value Currency that can be used as a common measure of value for work / features. This allow for richer prioritization of work as well as helping to provide an understanding of the cost of changes that are being considered. Without a common currency, it is difficult to negotiate trade offs.
It was clarified that how a team chooses to do prioritization of stories ahead of the kanban development process is up to the organization and should be appropriate given their context. However, once a story arrives in the queue that is ready for dev (analysis or what ever the first step in the value flow) it needs to be ready, just as how stories that are brought to a Sprint planning meeting need to be ready, otherwise it adds waste to the process.
Excellent kanban reference is David Anderson's book on Kanban
