Charlie Rudd

Charlie Rudd, SolutionsIQ CEO I’m Charlie Rudd, CEO of SolutionsIQ, an Agile company. I’m interested in learning better and better ways to unleash the power of teams by applying Agile management principles and practices throughout the enterprise.

Subscribe to The Agile CEO via email

Your email:

Subscribe to our Newsletter

siq newsletter 180

The Agile CEO: A Blog About Agile Management

Current Articles | RSS Feed RSS Feed

Waste in Software Development

  
  
  

In the first in a 5-part series that explores how Lean principles are applied through the practice of Agile, we discussed how the differences between Lean and Agile in software development are more about when particular practices might be best applied under particular conditions and less about how the two approaches are fundamentally different. In fact, Agile and Lean hold many guiding principles in common.

In this second installment, we will explore examples of what might qualify as Lean waste in software development.


The seven kinds of waste, as first outlined by Taiicho Ohno, provides a framework to identify and remove waste from manufacturing. Although software development and manufacturing differ in important ways, once you start looking for the counterparts of manufacturing waste in software development, it's surprising sometimes how easy they are to find. Here we will review two of the original wastes, Inventory and Waiting.

  • Inventory. Inventory includes all parts and materials that have been purchased and are waiting to be used. It also includes work-in-process (WIP). WIP is everything that is being worked on that is not yet ready for shipment or sale. Inventory and WIP lead to waste because by definition they tie up resources that are not yet able to generate a return. In addition, the greater the inventory, the greater the risk of obsolescence, loss, and write off.

Inventory in software development. In knowledge work such as software development, we can think of inventory as being maintained in documentation and in non-deployed software. Software work-in-process (WIP) is all activity (and therefore expense) subsequent to business case approval but preceding deployment to production. This includes requirements documents, project plans, functional and design specifications, source code, test plans, and tests, plus the time to create these artifacts. If a project is a year or more in duration, WIP continues to build up over the entire period prior to production use. WIP is also tantamount to the accumulation of write-off risk for software investments because if the project ends prematurely or never is delivered, no business value is generated and the WIP investment is lost.

  • Waterfall software project WIPWaiting. Waiting is the delay between steps in production. If an order comes in the mail and sits in a mailbox, that is the waste of waiting. If an item is assembled, the delay before it is packaged is the waste of waiting.

Waiting in software development. Examples include waiting for milestone and change request approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts, waiting for builds and testing to complete, waiting for your turn in meetings and conference calls, waiting for deployment schedules and architectural and code reviews. Any elapsed time in excess of what is needed to execute the added value step is a form of waiting. Looked at in that manner, even the most efficient operations still have much waiting, in principle, leaving plenty of opportunity for future improvements.

If you have additional examples of waste in software development, I would love to hear about them.




White paper: When you're Agile you get Lean


If you're interested in this topic,
please take a look at our new white paper:
When you're Agile, you get Lean.

 



 

Comments

Here's 4 ways that Scrum helps keep a company lean. 
 
 
 
Unnecessary Transportation – Task switching from one project to another. Limit the number of projects to the number of teams. 
 
Motion – Scrum teams should have all the skills they need to complete a sprint. No need to hand off information to other teams. 
 
Over processing – Scrum encourages individuals and interactions over process and tools. We encourage lightweight processes. 
 
Inventory – Avoid partially completed features or work in progress. Scrum encourages one-piece flow. 
 
Posted @ Thursday, June 21, 2012 1:52 PM by Steve
Comments have been closed for this article.