Over the past 30 years most organizations have approached software development using one faulty methodology after another. They have been looking for a silver bullet that has yet to materialize. First they tried to turn software development into an engineering practice by developing detailed project plans and specifications. This caused most projects to take a very long time while still missing deadlines and going over budget. The problem is that as computers get more and more powerful we are constantly looking to develop software to solve problems that have not been solved before, so usually the team doesn’t know what it doesn’t know. Today’s successful software development teams have to embrace uncertainty so we need methodologies that allow us to respond quickly to change. Lean methodologies offer promise in this area. The Toyota Product System developed in the 1950s describes a methodology that incorporates a set of tools, and techniques into the business manufacturing processes to optimize time, human resources, assets and productivity, while improving the quality of products being produced for their customers. Lean manufacturing processes do not exactly translate to lean software development.
The house of Toyota for lean manufacturing requires modification to fit software product development projects. The image below shows Dean Leffingwell’s take on the best practices required to translate lean manufacturing to the software development domain.
The foundation of the house is leadership utilizing lean techniques. This is unlike Scrum where leadership is expected to stay out of the way, to scale an agile organization to an enterprise level the management team needs to fully understand the concepts and be committed to supporting their teams in the journey. The roof of the house of lean is the goal of achieving value quickly. To achieve purposeful value, the organization needs to fully understand their value chain. What is it that they do to bring something from concept to cash? Once they understand this, they can begin to measure the activities and delays in the value chain to determine which bottlenecks provide the most value when resolved.
The pillars of the house of lean include respect for people, product flow and kaizen also known as continuous improvement. Respect for people includes both the customer and all project stakeholders. Be thoughtful in how one engages the customer and be considerate to all of your stakeholders. Product flow relates to understanding your value chain and mapping the activities in this value chain so that you can understand what levers it makes sense to adjust. Unlike Six Sigma that focuses primarily on identifying and removing waste, Scaled Agile as part of the process mapping activity is aiming to identify non-value added activities that add delay to the product flow. Kaizen focuses on continuous improvement. Respect for people, product flow and kaizen are all critical for building a learning organization.
Teams should focus on product flow as a means to achieving value as soon as possible. Does your team measure cycle time, product cost, product value, development expense and risk or do you measure what you have as a proxy variable? Has your organization quantified the cost of delay for your project or are you just measuring progress against milestones?
The five key economic objectives can be varied independently to see how they affect life cycle profits. This produces what is called a transfer function that can produce a U-Curve like the one depicted in Figure 3 below. Important trade-offs between the five key economic objectives will most likely produce a U-Curve.  The goal is to find the spot where deployment costs plus design build and test costs produce the lowest total cost. We do not need to have precise answers to achieve 90+% of the available cost benefits. In the manufacturing world, managers used to focus on machine utilization, which often caused inventory buildup. Also Management often takes the view that economies of scale can be gained by increasing batch size so in theory large batches would be more efficient. However in practice knowledge work coordination costs usually increase more with batch size and deployment related costs seem to rise in line with batch size. This has led to a focus on reducing batch sizes while modern automated build and deployment tools have reduced transaction costs related to integration and deployment. The objective for most software or IT shops should be to deliver value as quickly as possible.
Time to value is the metric most successful Chief Information and Chief Technology Officers will be asking about over the next couple years. As Jonathan Murray states in his article on The Composable Enterprise, “The time between identifying a business need and delivering the required IT solution needs to become hours and days rather than months and years.” We don’t care how many lines of code per day or really even how many story points were delivered in the last sprint. What we care about is the business value delivered and how quickly we are able to achieve this value. So one of the first five key economic objectives that everyone should examine is their cycle time. What is the impact on product cost; product value and development time does a change in cycle time. How does risk change by varying cycle time? Also how much actual work or touch time is included in the cycle time? When mapping your value/activity chain do you see many hand-offs that cause lag time before another activity or decision is made? How can you remove that waste and still maintain the appropriate level of control for your business? You may be surprised by the huge positive gain that can be achieved just by addressing cycle times with respect to the decisions/activities around the lags. If a cycle time looks like it can’t be adjusted is there an opportunity to push decisions and responsibility closer to the level at which the work is being performed? By pushing smaller decisions closer to where the work is being performed one can usually reduce wait times in value chains.
How are resourcing priorities set when the cost of delay is unknown? Have projects and/or features being developed this budget cycle been prioritized against each other? When making these priority decisions it helps to understand the user value of a feature as well as the time value and risk reduction value. The user value is the value of the feature in the eyes of the customer. The time value is based on how value decreases over time. Many features provide a premium value if delivered to the market promptly and this value can decrease rapidly as competitors provide similar features. The risk reduction value is a relative estimate that acknowledges the fact that software development has many unknowns/risks and that working on certain features early can reduce risk of future feature development.
|Cost of Delay||Effort||Weighted Shortest Job First|
|User Value||Time Value||Risk Reduction Value||Total|
Note that in the example above, the feature with the highest user value has the lowest WSJF so it should be implemented last with respect to the other features being considered. This is because the time value of the other features will have a higher return on investment should they be implemented first. Since we are all about delivering value quickly, this type of prioritization should help with decisions about which tasks to work on first and down the line.
When the cost of delay is equal, we should focus on delivering value as quickly as possible. To do this we should schedule the shortest job first, the next shortest job second on down the line.
No matter how much effort you put into prioritization and visibility, often management will tip the apple cart in favor of a squeaky wheel. Does your team move from fighting one fire to the next based on how loudly a stakeholder protests? More organizations than not move resources haphazardly from one stakeholder demand to another without truly understanding the economic view of the decision. Many published articles point to the fact that escalating priorities is a drain on productivity. Though I have never heard any management argue this fact, they have to deal with the realities of “keeping the lights on” with respect to operations or keeping the most profitable customer(s) happy so they usually will take the productivity hit to handle the problem du jour. If you embrace a Kanban system like Ken Anderson has documented, you can implement work in process limits and categories of service to allow a certain number of high priority items to take precedent over other work items. In this way you make the productivity cost visible to all stakeholders.  With priorities and costs being transparent to all stakeholders including the development team it will be much easier to keep team morale high which is a big part of pillar 1’s guiding principle of Respect for People.
 Principles of Product Development Flow Second Generation Lean Product Development, Donald Reinertsen, Page 30
 Principles of Product Development Flow Second Generation Lean Product Development, Donald Reinertsen, Page 34
 The Composable Enterprise, Jonathan Murray, http://www.adamalthus.com/blog/2013/04/04/the-composable-enterprise/
 Kanban, Successful Evolutionary Change for Your Technology Business, David J. Anderson, Chapter 11