The gains that Lean Six Sigma has brought in the areas of manufacturing, operations and physical product design speak for themselves. It is natural to want to replicate that success in software design. To do that most effectively, however, practitioners must meld Lean Six Sigma with Agile, a software development technique that is gaining traction in the industry.
Linking the two can be difficult. The fit involves some grounding in Agile methods and revisiting the core essences of DMAIC and DFSS (Design for Six Sigma). Practitioners must carefully consider the potential gains from using Lean Six Sigma in an Agile software development environment. But first they need to understand what sets software design apart from other product development.
What Makes Software Unique
With hardware design, a lot hangs on getting the design right the first time. There is big value, as well as big risk, in making decisions on such things as architecture, components, manufacturing equipment and tooling – elements that are difficult or expensive to change after the fact. Because of that, Lean Six Sigma in physical product design typically focuses on predicting capabilities, tolerance analysis and critical parameter management. The design process is usually controlled through sequenced phases with gates enforcing a review of requirements and decisions before actions are taken.
Software, whether standalone or embedded in a hardware product, is just as important to get right, of course. But instead of physical dimensions and tolerances, good software depends more on the ongoing flow of experimentation and understanding, which results in improved iterations. Designing software in the same way as hardware, with sequenced phases and locked-in decisions, can reduce the eventual value of the software and increase the risk of costly mistakes.
In software, the cost of creating new iterations is small when taking into account the learning derived; this learning pays dividends to a design. Iteration does not mean meandering aimlessly; instead, it is highly focused, closed-loop experimentation, where customers and developers can learn things they would not have known if forced to sign off on all aspects of requirements up front. Iteration can be value added if done well in the right settings. This theory is the basis for the Agile development method.
The Need for Agile
Managing software development with a gated, waterfall model taken from hardware product design can be costly. Oversimplifying for convenience, Figure 1 illustrates a value/risk pattern for developing with this method, which, as shown, can become a vicious circle.
The arrow in Figure 1 indicates a development pressure point, where work is commonly batched. Organizations may try to squeeze into play more features and requirements than developers know will fit, creating schedule compression and work in process (WIP). To compensate for these additions, haste and task-switching also increase. In a hurry, without enough time for thinking and communicating, developers constantly change gears from one thing to another, leading to gaps in communication, understanding and communication, and incurring risk of mistakes and omissions. That drives extra work and rework into the system and drains available time, increasing schedule pressure – and the cycle starts again.
Agile software development took shape as an antidote to that cycle. Mechanisms to reduce and control WIP, curtail task switching, and close gaps in communication and understanding are built into the foundation of most Agile processes. Agile software development is a combination of Scrum (a term borrowed from rugby, and referring to the team-based process used to push the project along) and Extreme Programming (XP) – referring to the technical practices, including coding, testing and feedback, used to support quality work.
Scrum in a Nutshell
Inspiration for Scrum came from Dr. Jeff Sutherland, a medical science researcher designing a novel diagnostic imaging system. Being responsible for such a complex system reliant on software, he saw the vicious circle up close. As he thought about how to break that cycle, his background in physics and as a pilot provided some insight about reducing turbulence and improving flow.
The process he came up with – Scrum – is fairly simple but the results are significant. It limits development work in process; removes gaps that in the past had separated customers, analysts, developers and testers; and matches and tracks the right work with the right people. The mechanics of Scrum are shown in Figure 2.
Product backlog – This is a list of potential software features or requirements for developers to work on, prioritized by value and risk. A product owner works with customers and developers to consider the next increments to deliver to increase functionality or performance of the software, or to reduce any significant risks.
Sprint – This is set time period (e.g., 30 days) in which the development team focuses on a set list of goals, or features. Before beginning a new sprint, the team assesses its current availability and past work habits using data and discipline connected with prior sprints to decide how much work they can pull from the product backlog into a list of features to be implemented during the current sprint (known as the sprint backlog). Central to this sprint planning is setting up conditions where team members can focus and work to their highest quality standards, without heroics, burnout, or risk of defects and waste. This is a WIP control mechanism, because it is used to pull work into the process at the sustainable rate at which it can be done well.
Daily stand-up – A daily stand-up meeting is held to bring to the surface issues and obstacles using three check-in questions:
1. What’s been done since the last meeting?
2. What are the team’s plans until the next meeting?
3. Are any obstacles anticipated before the next meeting?
The meeting is meant to be short and to the point. Because these open meetings are held so regularly, they provide a powerful transparency and foster learning and adaptation. With Scrum, risk and gaps connected with work completion or performance cannot hide. Whatever is going on, good or bad, will come into view in real time.
Features delivered – At the end of each sprint, the team delivers tested features, sometimes completing a customer project. In other cases the team delivers features that will increase the strength of an emerging product. Done well, Scrum provides insurance against losses if a project is canceled, as the increments delivered tend to stand on their own and may have value in other projects.
Benefits of Agile for All
Switching to the Agile model of development can be a monumental shift for some organizations. Despite the changes in process, however, the method has gained much support from the three factions involved in software development:
- Customers – Before Agile, they had to sign off on requirements for new product development at the outset, before they really knew enough to do that – paying dearly for any changes. They typically find Agile teams more responsive and flexible.
- Software managers and business leaders – They see the value stream moving more quickly, where the path from discovery to successful delivery is shortened and reduced in cost. They are also happy to see fewer resources spent on rework.
- Developers – As W. Edwards Deming said, people want to do a good job, and they enjoy getting the chance to actually do it. When developers get into the Agile workflow, they often take pride in high quality, customer-focused work. They show this by voting with their feet, leaving companies that do not become more Agile, and bringing their talents to the companies that do.
Potential Gains of Combining Agile with Lean Six Sigma
With this background in Agile, practitioners are better prepared to consider a value-added integration with Lean Six Sigma. DMAIC and DFSS thinking and tools have much to offer Agile users; however, the practitioners must do some tailoring to help the methodologies fit together.
DMAIC Thinking and Tools
Because Agile teams thrive on spotting and removing problems, constraints and waste, they are well prepared for using DMAIC thinking and tools. While they may not conduct full DMAIC projects, they can use tools such as causal analysis, mistake proofing and ongoing process controls. Although Agile teams work in sprints, that does not mean they sacrifice attention to detail for speed. Agile teams like to measure, observe carefully, reflect and adapt – a progression that is a close cousin to the classic Plan-Do-Check-Act that was the early basis for DMAIC.
Essence of DFSS – Beyond the Waterfall
A linear DFSS roadmap such as DMADV (Define, Measure, Analyze, Design/Build, Verify) may remind Agile software developers of the sequential hardware design method. Therefore, the method must be re-mapped to avoid losing the attention of these developers. It is possible to use DFSS in a way that supports iterative development, as shown in Figure 3.
DFSS can be viewed as an array of capabilities and questions that are posed and answered, but not necessarily in sequence. Whether in sequence, or as needed and iteratively, these capabilities and questions are important in good design, and they are not covered in the foundation practices of Scrum and XP. By emphasizing the iterative DMADV roadmap, Lean Six Sigma practitioners can add value to software development. It may help to break down the influence by phase:
Define – Software teams care about the issues that must be addressed in a design, and one thrust of Agile is to get closer to customers to increase value discovery. However, practitioners must be ready to streamline the look and feel of customer visits or VOC data collection. Agile teams may favor quick conversations at a whiteboard to structured interviews and survey analysis. They will favor self-documenting user stories over rigorous, formal requirements documents. This should still allow them to gather good data and mine it for insights.
Measure – All developers look for information from customers to support their design and feature decisions. Agile teams will favor ongoing dialogue, fueled by regular customer demos that deliver working increments. For them, Measure might mean gathering the right numeric and language data during those incremental demos and tests.
Analyze – With solid information about what is important to address (determined in Define) and the dynamics informing design and feature choices (Measure), it is time to prioritize what will be delivered, when, and using what resources. This is the crux of the Scrum product backlog and planning for a sprint. The matching of those features or requirements with a sprint and an Agile team still calls for some estimation using past data regarding team capability (speed and accomplishments of recent sprints). Attention to measurements and learning from patterns in past sprints are very important to Agile teams.
Design/Build – Although gated, linear design and Agile, iterative design use different means, they work to achieve the same end – implementing a design that achieves the right things. Scrum seeks transparency and rapid, fact-based learning cycles to uncover and quickly resolve issues. Lean Six Sigma tools such as design FMEA and verifiable design performance models can be a perfect fit. It is all about closed-loop control and rapid flow of results, as evidenced in the daily stand-up meetings.
Verify – The XP aspects of Agile are built around test-driven development, which integrates aspects of testing with the software coding so that many risks and test bottlenecks never happen. When it comes to integration and system level testing, Agile teams seek to measure results in customer terms, using voice of the customer feedback. Their job is not done until real users actually derive value from the delivered product.
The Path Forward
In preparation for finding the right fit for Lean Six Sigma within Agile development, it helps to appreciate some ways that software is fundamentally different than hardware and survey the current state of Agile. With this perspective, it is possible to see how DMAIC and DFSS can provide tools and methodology that add value to Agile environments. By re-mapping their understanding of Lean Six Sigma’s classic paths, practitioners can work to successfully integrate the methodology with Agile development.
