It can be challenging at first to find the connections between Six Sigma and Agile; a number of obstacles stand in the way of reaching an integrated view. But there is some untapped leverage that, if explored, may ease the use of the two methods.
It is often more interesting to find the intersections that connect things, rather than the distinctions that seem to divide them. This is true with Lean Six Sigma and agile software development. Ultimately, both aim to improve the processes used to deliver products that meet customer specifications. But it can be challenging at first to find the connections between these methods; a number of obstacles stand in the way of reaching an integrated view. With this view, though, practitioners can leverage the benefits of both greater design and programming skills and a better understanding of how to discover and meet user requirements.
Obstacles to an Intersected View of Lean Six Sigma and Agile Development
Finding the intersections within Lean Six Sigma and agile software development can be beneficial, but four obstacles may stand in the way.
1. Seeing Software Development Through the Manufacturing Lens
In manufacturing operations and repetitive services, the variation that gets in the way of doing the same thing the same way over and over is the main concern. While there are some repetitive aspects to software development – configuration management, aspects of coding standards and testing, for example – Lean Six Sigma can miss the mark when a widgets-on-conveyor-belts model is presented. In software, the variation in shared understanding is usually the main enemy.
Therefore, Lean Six Sigma should be presented as a method that goes where the value and risk questions are, and then helps grow net value and reduce risks. Practitioners should be ready to communicate the intent and potential value of Six Sigma in ways that offer help dealing with value and risk in less physical and repetitive domains.
2. Painting Six Sigma into a Statistical Corner
Connected with the first obstacle, this problem occurs when practitioners define Lean Six Sigma in terms that are too statistical – missing the connection software developers might have with more-descriptive and language-data-based strategies in the kit. These include voice-of-the-customer tools for gathering better language data and distilling it more effectively, as well as tools such as quality function deployment (QFD), the analytical hierarchy process (AHP) and KJ, which deal with best use of qualitative facts and data, sometimes together with numbers, to drive quick learning and decisions.
Practitioners should not reduce all software development issues to a statistical problem – some reduce to logical problems but still benefit from Six Sigma tools and thinking.
3. Trying to Fight Complexity with Complexity
Software development involves a number of challenges: understanding requirements and prospective features; selecting the features to implement; and planning the resources, schedules and tests for on-time, high-quality delivery. These challenges can be extremely complex, and practitioners must be careful not to misapply manufacturing remedies such as compliance to checklists and complex forecasting and optimization to the development process.
It is easy to get enthused about “the power of the tools” and become over-reliant on roadmaps, checklists and high-octane multivariate models. On that path, practitioners may try to subdue process complexity by matching it with process complexity and model-based complexity. But that approach in a software environment may lead to missing the chance to get aboard the way that agile software development (and Lean in general) deals with complexity – by trying to make the work and the people-to-people connections simpler. Although neither approach is right for all cases, note that complexity can be fought with complexity and, sometimes, with simplicity, depending on the situation.
4. Overemphasizing the Waterfall Development Model
“Do it right the first time” and “Get the requirements right, up front” are great pieces of advice in the situations they fit. But practitioners must be careful not to over-apply this thinking when it may alienate them from potential allies. When capital equipment and manufacturing process investments are hanging in the balance, it may make the most sense to force decisions to the front end. Reducing the risk of scrapping or reworking capital equipment or manufacturing components is exactly where Lean Six Sigma should focus in a manufacturing environment. In software, though, the incremental work products are a lot less brittle.
If practitioners force signoff on requirements and specifications up front, they, and the customers, have to act like they know more than they actually may about what is important and what the choices will be. This practice cuts off the chances for learning en route – and thus, lops off a whole class of value- and risk-improvement options that might have been extremely helpful and Six Sigma friendly.
It is easy for Lean Six Sigma practitioners and software developers to become polarized over this issue. Waterfallers may see agilites as wanting to go back to Capability Maturity Model Integration Level 1. Agilites may be too quick to dismiss the value or risk-reducing aspects of things such as documentation or interim reports. The answer is often somewhere in the middle.
Understanding Scrum
Here it may help to underline a key insight about the agile software development method scrum. Scrum is a simple set of roles and practices that helps prioritize and organize people and their work – while fostering the communication and transparency vital to high-quality, high-efficiency delivery of working results. This transparency reveals obstacles and performance gaps in a daily, closed-loop way. The figure below illustrates a flavor of agile software development that is common enough to be a good reference point for Lean Six Sigma integration.
Done well, scrum is elegant and potent at what it does, but it is not a complete diet. The first shell that needs to surround it is a set of programming practice. Extreme programming (XP) and close variants are a common choice there. Practices such as test-driven development, pair programming and refactoring will put design and development meat on the bones of a Scrum workflow.
6 Ways to Leverage Integration
While scrum (inner circle of the figure above) can be a great foundation, there are still times when teams and individuals reach outside pure design and programming skills to the broader worlds of user-environment exploration, requirements discovery, study of design drivers and dynamics, and other areas depicted in the outer ring of the figure above. This is where Lean Six Sigma can fit in and will make everyone happy. These six steps represent the best potential for Lean Six Sigma and Agile software development integration.
1. Understand Problem and Opportunity Context
Software product owners and analysts, and sometimes even developers, occasionally need to exercise anthropology or sociology skills and learn things about people and their work or play environments. That’s not a coding or design skill per-se; it is a coding and design informing skill.
Lean Six Sigma practitioners have learned much about how to gather and understand the VOC and the voice(s) related to their environment. Skills in language-data gathering and distillation (such as effective affinity and KJ) can be welcome and may help with scrum and agile whiteboards.
2. Discover User Stories and Delivered-Value Tests
Often the focus of Lean Six Sigma VOC work is requirements discovery and prioritization. Agile practitioners will often talk in terms of user stories as potential requirements in the process of becoming better understood. Lean Six Sigma practitioners can learn valuable lessons by understanding the intent and best practices of user stories and agile teams can benefit by some appropriately tailored VOC insight. The key here is to avoid the fourth obstacle from above, about overemphasizing Waterfall. Practitioners should recognize that there are times that requirements understanding is better treated as unfolding and iterative rather than “‘spec’ now or forever hold your peace.”
While it is crucial for practitioners to use functional requirements or user stories to identify what a user or actor wishes or needs to be able to do with the software, it is equally important for them to know how to verify that value has been realized and delivered. This is where delivered-value tests come in. Thinking about the nature of the acceptance tests as part of the understanding-the-requirement process resonates with the test-driven development notions in agile/XP and with the verification sense in Lean Six Sigma.
3. Understand Value Drivers, Risk Drivers and Dynamics
The need for an understanding of key drivers and dynamics depends on the nature of each particular software project. This type of understanding is more commonly useful in firmware development, where software controls hardware and touches the physical world, but also sometimes in applications (e.g., network performance, usability testing) and even in commercial, off-the-shelf deployment. In this latter realm, this type of understanding is important because the development team must be familiar with the “what if?” dynamics related to choices they face.
These development situations call for the right form of model building. Some software teams model the hardware or network in order to reduce development time and dependency on availability of scarce resources. If and when that happens, the team is outside the sphere of scrum-plus-XP skills and tools. But if they have a friendly relationship with a Lean Six Sigma resource, they can work together to build, assess and use some models to drive their required learning.
4. Make Quick, Correct Decisions
Practitioners at all levels would probably agree that they are continuously pushed to make quick decisions – under the pressure that they have to be right or at least right enough to avoid undue waste as a consequence. In simple cases, common sense methods can do well enough, and they will always have a place. But there are other times when the complexity of the decision may become too much, especially relating to one or more of these dimensions:
- Number of decision goals and relationships or tradeoffs between them
- Number of alternatives and related choices
- Evaluation of the merits and gaps of each alternative with respect to the goals
- Solution-deployment dynamics including choices about people, other resources and schedules connected with making the solution happen
- The number of people who need to be involved with evaluating the goals, alternatives and solution-deployment dynamics
- Documenting the decision thought process to inform others and compel them to align with the decision
An Agile team may find itself in need of help when dealing with these decisions, and might be glad to find a Lean Six Sigma person with some simple, practical tools to help sort things out. KJ and web-based AHP are among the tools in some Lean Six Sigma kits that can help in these situations.
5. Deliver Results Using Closed-Loop Control
It is a challenge for developers to see where they are going while they are going there – and see it in a way that delivers early course-correction signals. Scrum uses burndown charts as a primary way to watch the effort and time spent versus the tested functionality delivered, but there are aspects of product and system performance that can benefit from some real-time measurement, adaptation and optimization. Lean Six Sigma understands this realm and developers can gain greater control by fitting its principles into the agile environment.
6. Scale and Sustain Ongoing Delivered Results
After the work products are delivered, there follows the useful life of the product, where there is much to be learned by watching the right aspects of user experience and results. Lean Six Sigma has tools for streamlining the environment for the delivered, installed product – and finding Lean benefits not only for the software company, but also for the customer.
Focusing on the Similarities
It has been said that being able to see what is different in things that are apparently the same is the talent of a good problem solver – but being able to see what is the same in things that are apparently different is the sign of a good innovator and designer. This is why it is important for practitioners to focus on the “things that are the same” that might better connect Lean Six Sigma and agile development.
