From LeanSSC Wiki

Note: This page was started by wiki-fying the chapter Appendix B: A Model of Lean-Agile Software Development from the book Lean-Agile Software Development: Achieving Enterprise and Team Agility. This appendix is periodically updated based on enhancements to this page, which is maintained by Net Objectives.

An alternative format for this model is being created at A Road-Map for Lean-Agile Competencies

Contents 1 A Model of Lean-Agile Software Development 1.1 Foundational Thinking of Lean 1.1.1 Perspectives 1.1.2 Principles 1.1.2.1 Principles (Laws) 1.1.2.2 Principles (Guidance) 1.1.2.3 Attitudes 1.1.2.4 Knowledge 1.1.2.5 Practices 1.2 Just a Beginning 1.3 References

A Model of Lean-Agile Software Development

As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. Albert Einstein

We have always found it useful to create a model of our thinking. This both sharpens our understanding of things as well as gives us a frequent chance to check its validity. While one should not work off a model as truth without understanding it, very often, the extra awareness that a model brings is useful – it allows us to take advantage of our intuitive knowledge by bringing it to the surface.

Something as complex as Lean thinking has many different ways and levels. These perspectives are not truly orthogonal, but rather build on each other. Figure 1 illustrates how practices build on knowledge which builds on attitudes which build on perspectives and principles which builds off foundation thinking.

Figure 1. The building blocks of the model

Foundational Thinking of Lean

This is the underlying belief system that Lean is based on. Much of this work comes from W. Edwards Deming.

• Most errors are due to common causes
• People are basically good and want to do a good job
• Businesses will do best when they maximize value given to their customers

Beliefs added 1/16/2010:

• There is a science underneath what we do in product development. That is, there are laws, that we ignore at our peril - they affect our work whether we attend to them or not
• This science implies a need to understand our systems. If our systems recognize and incorporate this science, our results will be better. This is what enables and requires systems thinking to achieve consistent results
• Management plays a key role in software development
• A top-down or bottom-up approach is inferior to one where executives, management and first line workers work together in their roles. Business drivers must identify, size and prioritize the work to be done. Management must facilitate the improvement of the value stream and pay attention to the working conditions that people find themselves in. They must provide coaching when necessary and assist teams in following their own processes. Teams must implement the business and management vision in the context the team finds itself in in the flow of work.

Perspectives

You can think of perspective as how to look at things. Perspectives in themselves don’t tell you how things work. But if you don’t attend to the right things you often lose a lot of power. We often see things but don’t understand how important they are or we otherwise misinterpret them. The perspectives of Lean come from a combination of Deming with his systemic and psychological approach, blended with Toyota’s focus on Just In Time (JIT).

• Look at time not resource utilization
• Think of the development process as fast-flexible-flow
• Lowering buffers between steps increases visibility into the process
• Best way to eliminate waste is not to build what you don't need
• Your process is your baseline for change
• View impediments to flow as waste

Principles

Principles come in two flavors – principles as laws and principles as guidance. There is obviously a relationship between these so there will be redundancy in the listings.

Principles (Laws)

The following are what we think of as laws of development. Break these at your own peril and incur waste. That does not mean you never break them. There are times where emergencies call for action that are not optimal. But understand that a cost is being incurred.

• Shortening cycle time will reduce waste and increase quality
• You tend to get waste and lower quality when you increase the time between:
  • When you need information and when you get it
  • When you make an error until you discover the error
• Making decisions too early increases the risk of waste
• Excess Work In Process (WIP) increases both risk and waste
• Impediments to flow cause waste
• Increasing the number of concurrent projects with a given amount of resources working them increases the length of the projects
• Large batches cause waste
• Switching from one task to another such that thrashing occurs causes waste
• Having people work on more than one project at a time decreases their efficiency.
• Not paying attention to risk may cause waste
• Delivering value quickly increases ROI

Principles (Guidance)

These are principles to follow. That is, these give us guidance. Those that are bold-italics are the seven principles detailed in (Poppendieck and Poppendieck 2003).

• Optimize the whole
• Eliminate waste
• Create knowledge
  • Look to the system for errors
  • When something impedes the team, find a way to eliminate it
  • Follow the scientific method to see how to improve your process
  • Select the most important things to work on
  • Have teams work on one project at a time
  • Quality problems are often caused by delays in the work flow. Removing such delays will improve quality and increase speed of delivery while decreasing cost
• Build quality in
  • Limit work to capacity
• Defer commitment
• Deliver Fast
  • Organize product enhancements into Minimal Marketable Features
  • Have the people with the greatest knowledge of the problem at hand make the decisions involved
• Respect people
  • Improve your culture by improving your management systems

Attitudes

Attitudes are important. They help define how we look at things and if we consider things to be of value. Attitudes are a result of our belief system and will affect how we look at things.

• Management is important. Management needs to set outcomes for teams, allowing the teams to figure out the best way to get there.
• Have a goal of delivering as much value as possible in as short a period of time.
• Focusing on removing delays by eliminating waste and delays will raise quality and lower costs.
• Always go to root cause to find and solve impediments
• Do not let errors go by without fixing them or at least noting them so the root cause of them can be fixed later.

Knowledge

This is knowledge based from experience. We could also call this lessons learned.

• If you have long test and fix cycles you are not testing early enough.
• If you have requirements churn you are doing too much requirements early.
• Optimizing components of your process without attending to the whole may result in waste.
• Focusing on lower costs typically results in lower quality and longer cycle-times.
• Focusing on only quality may result in longer cycle times with little value to the customer.
• People doing the work have an appreciation of it greater than those managing it.
• A high level of work in process (WIP) is often an indicator for lots of thrashing.

Practices

There are, of course, many practices that Lean suggests doing. However, one has to be very careful about following practices. Practices make sense only within a particular context. One must always ensure that the practices being followed are sensible for the context at hand. Knowing practices, however, is a good starting point. Using principles to guide practices in unfamiliar contexts is often a good way to create new practices.

• Use value stream maps to see delays
• Manage with visual controls
• Build software in stages (iterations)
• Do continuous process improvement
• Move testing up to the start of the development process
• Select stories to work on to minimize risk (note, biggest risk is often building what you don't need)
• Use Minimum Marketable Features to manage release cycles
• Have cross-functional teams take on projects until completed and then move on to another
• Go to the “gemba” (that is, go to where the work is being done)

Just a Beginning

The model presented here is just a beginning. Lean product development is not new. As our understanding of Lean unfolds, this model will be refined. There is already much more available. We are very excited about Don Reinertsen’s book, Principles of Product Development Flow: Second Generation Lean Product Development (Reinertsen, Principles of Product Development Flow: Second Generatilon Lean Product Development 2009) in which he lays out 175 principles of Lean product development organized into the following areas:

• Economic
• Queuing
• Variability
• Batch Size
• WIP Constraint
• Flow Control
• Fast Feedback
• Decentralization

This work presents a extensive model that Don began with his excellent book, Managing the Design Factory (Reinertsen, Managing the Design Factory: A Product Developers Toolkit 1997), which is a must read by any Lean product developer. We will be posting what we are learning on the website for this book which you can find at www.netobjectives.com/resources/books/lean-agile-software-development.

References

Poppendieck, Mary, and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Boston, MA: Addison-Wesley Professional, 2003.

Reinertsen, Donald. Managing the Design Factory: A Product Developers Toolkit. New York: Free Press, 1997. —. Principles of Product Developmen Flow: Second Generatilon Lean Product Development. New York: Celeritas Publishing, 2009.