David Anderson was the first one, for me, to demonstrate how Little's Law addresses one of software development's underlying issues, Lead Time. He did this in his book, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results which if you have not read, run and go and read it now! In this book, the way he addressed Lead Time, just like everyone else in the Agile Universe, is through iterations. At his current place of employment, Corbis, David is the Senior Director for Software Engineering. He has written several blog entries on his experience at Corbis. Corbis had an existing non-Agile development culture and they had built and shipped products. Additionally, the team had prior commitments to ship new product and enhancements on specific dates that David in trying to improve the productivity of the organization, could not compromise. This meant that he could not swap in wholesale some Agile methodology but rather he needed to change practices to more Agile ones incrementally and tailored to the current context.

To do this, David went back to the Principles behind Agile and distilled them down to "four actionable directives that will deliver significant improvement." He calls these his Recipe-for-Success:

• Focus on Quality,
• Reduce Work-in-Progress,
• Balance Capacity against Demand,
• Prioritize

He also realized that some of the work being done at Corbis was not easily broken done into chunks of usable/useful end-user functionality that could be accomplished within the delivery time he wanted -- where delivery time is the same lengthas an iteration. So the problem David had was: how do you accommodate these longer development pieces yet also have deliveries on regular basis, i.e. every 2 weeks? I think that he arrived at his solution by elevating the Corbis constraint which is development capacity which is the two middle points of his Recipe-for-Success. Based on his analysis/experimentation/guessing(?) it was determined that his development colleagues could handle: 20 new development activities + 2 maintenance activities [+ 3 defect correction activities]. Explicitly reserving tasks for maintenance and defect correcting ensures that progress is made on these longer standing, lower priority issues. The defect correction activities are additionally deemed optional, which allows management to apply resources to other activities as needed.

This approach provides the organization with the rhythm of regular releases, but breaks the constraint of having to shoehorn functionality into being completed within an iteration. The system has flow, low amount of Work-In-Progress and a improvements to reduce completion time have a direct and immediate improvement in the productivity of organization as a whole. The development team is self-organized. There is low management overhead, i.e. small amount of tracking, handling exceptions and setting priorities. Business is directing the selection of features to be completed and there is continual investments made in improving the quality.

I am impressed with what David and his colleagues have accomplished. They have broadened my view on how Agile can be introduced into organizations.

There are four articles that relate to the transformation at Corbis, and I recommend you read them in this order:

• My Approach at Corbis
• Recipe For Success
• Making Progress with Imperfect Information
• Kanban in Action

One final thought, upon reflection the changes made improved the agility of this development organization, but the approach taken tastes much more Lean and Theory Of Constraints in nature, than Agile.