By now we’ve all heard the proponents of the Agile Scrum process tout its advantages over historically popular processes such as Waterfall. In the theoretical world a blind, side-by-side comparison could be conducted with identical projects, teams, customers and Hawaiian shirt Fridays. But let’s consider a more realistic approach. This article proposes a Lean Six Sigma study of the Waterfall process to determine if the effort indeed yields something analogous to Agile Scrum.
It is important to note that this proposal, while interesting in an academic space, is likely not practical from a business perspective. It may be difficult to produce a viable business case analysis to justify an investigation to establish an evolutionary relationship between process models. There are likely more efficient methods for a business to choose a process model. However, it might be a good thesis topic for someone with access to useful data.
It is assumed one is at least basically familiar with the Waterfall process, the Agile Scrum process and the Lean Six Sigma methodology. Additionally, Waterfall and Agile Scrum are better characterized as process frameworks, requiring tailoring at the individual organization to meet the specific business and customer needs, as well as the individual product and team characteristics. Examples of this tailoring would be the Agile Scrum sprint duration or the Waterfall required documentation artifacts. It is self-evident that a poorly tailored process can jeopardize a project.
This article does not attempt to execute such an analysis. Instead it only proposes Lean Six Sigma be used as an objective methodology to optimize a business’s processes. It further speculates with modeling inputs selected to highlight the differences between Waterfall and Agile Scrum, note that the analysis may naturally bias toward the Agile Scrum process. If true, it would substantiate the hypothesis that: if the inefficiencies of Waterfall were removed, the resulting process would be at least similar to Agile Scrum. While the failure of such an analysis would simply prove a weak correlation between Agile Scrum and Waterfall, the success would validate the assertions – at least to the extent Lean Six Sigma is itself valid. However, it is important to note that central to the Lean Six Sigma methodology is not to enter into an analysis with a predefined solution in mind. Doing so taints the progression and limits the fundamental advantage of Lean Six Sigma, its objectivity.
A brief search of the internet uncovered this article, which asserts Lean Six Sigma affirms Agile programming practices. While Goss’s article is interesting in the fact it successfully correlates Agile principles with the goals of Lean, a more thorough approach would be to follow the DMAIC (Define, Measure, Analyze, Improve and Control) roadmap to its ultimate conclusion and compare the results with the Agile Scrum process.
The first step in the Lean Six Sigma DMAIC roadmap is the Define Stage. The key to this stage is to articulate the problem in terms of a specific business goal. This goal must be specified in terms of a process output, referred to as the “output Y”. For a given project development process, candidate outputs might be:
- Time to market
- Post deployment defects
- Time to implement customer requirement changes
- Customer satisfaction
- Costs associated with rework
Each Lean Six Sigma project must have a single clearly defined, measurable and realistic goal. For the process outputs above, the corresponding goals might be:
- Decrease Time to Market by 50%
- Decrease post deployment defects by 30%
- Decrease time to implement customer requirement changes on average from 4 months to 1 month
- Increase customer satisfaction in a specific survey by 2 points
- Decrease the cost associated with rework by 50% over historical projects
It is important to note that a single Lean Six Sigma project should focus on only one of these goals. While it would be essential to monitor the other outputs to ensure no adverse effect was incurred, a Lean Six Sigma project must limit its scope to optimizing a single project output.
The second step in the DMAIC roadmap is the Measure Stage. Key to this stage is objectively establishing baselines from which to measure for improvement. In essence, this step is about collecting data.
For a given organization using a tailored Waterfall process, the Measure Stage might consist of gathering historical data across several projects to establish, for instance, a Time to Market baseline. This baseline might then need to be normalized by project complexity or other characteristics.
The third step in the DMAIC roadmap is the Analyze Stage. In this stage, a large number of process inputs are identified. These inputs are candidates that may contribute to the root cause of the process not meeting the desired goal. These inputs are called “candidate input Xs”. For the purposes of this experiment, it would be useful to define the input Xs in terms that differentiate Waterfall from Agile Scrum. The table below shows possible input Xs and how they might correlate with Waterfall and Agile:
|Possible candidate input Xs||More Waterfall Like||More Agile Like|
|The manner and time in the project where requirements are clearly defined to an actionable extent.||Typically, during project planning, early in the project.||Typically, only when toward the top of the prioritized backlog. Prior to being consumed by the scrum team.|
|The periodicity and duration of project team meetings.||As defined by the project manager and communication plan. Typically, weekly and 1 hour long.||Daily scrums typically 15 minutes.|
|The agenda of project team meetings.||Varying as defined by the project manager. May be outlined in the communication plan.||Fixed and following the 3 Scrum topics.|
|The frequency of demonstrations to the customer during the project.||Varying and more toward the end of the project as the product nears completion.||Frequent and coincident with the completion of a sprint or release.|
By first passively and then actively adjusting the input Xs, the net effect on the output Y can be observed. It is important to note that positively improving one output Y may have a negative impact on a different output Y, not the focus of the Lean Six Sigma project. Furthermore, it is entirely possible that adjusting some input Xs may have no net appreciable effect on the output Y in focus. This would not be an indication that the specific input X was not useful, only that it did not directly affect the output Y selected for this experiment. In the Analyze Stage the number of input Xs under consideration must be limited to 3-5 in order to focus the optimization effort.
The fourth step in the DMAIC roadmap is the Improve Stage. The purpose of the Improve Stage is to identify, evaluate and implement a solution which archives the desired business goal.
In the above example, let’s consider a potential input X such as “the manner and point in the project lifecycle where requirements are clearly defined to an actionable extent”. If the Improve Stage indicated the output Y was optimized by clearly defining the requirements only as they were about to be consumed by the project team, the net effect would likely be a step away from the traditional Waterfall process and toward a more Agile-like model.
The fifth and final step in the DMAIC roadmap is the Control Stage. The purpose of this stage is to maintain the improvements produced by the Improve Stage. This is an on-going stage and may be more applicable to an encompassing program. One such realization might be a process management organization’s monitoring or auditing of the project teams under its domain to confirm compliance with the optimized process.
The more detailed diagram below illustrates the hypothesis of this article. The un-optimized waterfall process inputs are shown yielding an un-optimized waterfall process output (poor time to market, marginal quality, excess cost, excess rework, etc.). After following the Lean Six Sigma DMAIC roadmap, the optimized waterfall process inputs, tailored to yield an optimized process output, tend to more closely resemble Agile/Scrum process inputs (shorter daily team meetings, just in time requirements definition, frequent customer interaction, self-organizing teams, etc.).
While this proposal may take some creativity in its implementation, Lean Six Sigma can be used to optimize an organization’s processes in a manner which focuses on tangible business goals. Essential to this effort is a sufficient collection of past and future projects to allow the objectivity of the DMAIC roadmap to operate without variability. If the original process is Waterfall-like and the resultant Lean Six Sigma optimized process is more Agile Scrum-like, it would provide tangible evidence that the Agile Scrum process is an evolution over Waterfall from the perspective of meeting business goals (at least for the organization and product line under investigation).
Corollary: While it may not be optimal given the stability of the requirements, it would be possible to use an Agile Scrum process to execute a Lean Six Sigma project. Consideration of this exercise is also left up to you.
John Gervais, Senior Project Manager