Scrum is an Agile project management methodology that can be used to control software and product development using iterative, incremental practices. Scrum generates the benefits of Agile development with the advantages of a simple implementation. This methodology can significantly increase productivity and reduce time to benefits while facilitating adaptive, empirical systems development.
A recent study of software development trends, sponsored by SoftServe Inc, and conducted by online periodical ExecutiveBrief, shows the increasing popularity of the model, with more than half of the respondents choosing Agile/Scrum as their preferred software development method, compared to just 42 percent in 2009. The second most selected methodology in the survey was the iterative model, with 13 percent giving it their top choice.
Between 2004 and 2009, several iSixSigma Discussion Forum members have weighed in on the merits – and obstacles – of merging the Scrum method with Lean Six Sigma. Here are some excerpts from the long-running thread, “Integrating Six Sigma with Scrum”:
Ken: I am interested in obtaining any written information about the integration of Six Sigma with Scrum. Any suggestions?
drjones013: There actually may be a way to combine LSS [Lean Six Sigma] with Scrum – it’s something I’m researching for my corporation right now. Essentially the model created out of Scrum may be assessed with LSS methodology. I find that Six Sigma, in its pure sense, is too much like waterfall (DMADV, you know) to actually accomplish a measurement task in the timeframes necessary for sprints to function and still be Agile.
daveh: What I’ve seen, in a number of companies working to answer this question, is:?
1) The “essence” of DMADV can be very useful to Agile/Scrum, but there are things ingrained in Six Sigma history that need to [be] evolved to fit Agile practice. Building a product backlog – a dynamic list of prioritized user stories/prospective features – is one example. DMADV VOC [voice of the customer] skills and insights about language data, discovering stated and latent requirements, understanding how performance will be measured or tested and prioritizing user stories can directly support the Agile goals of getting closer to customers and delivering what’s truly valuable to them.?
The challenge in helping Agile practitioners to see those potential benefits is the DMADV (for physical products) history, which talks about “getting all the requirements up front” – tollgate reviews and other structures that, on their face, go against the Agile grain. In the development of physical products, there’s more rationale for requirements up front as expensive, irreversible decisions about capital equipment, tooling, etc., are in the balance. DMADV grew up in that world, but it isn’t, in my experience, married to that one form of managing value and risk. DMADV tools, at their essence, offer insight about understanding customers and their environments, results drivers, solution alternatives and fact-based ways to select the best – delivering working features under closed-loop control and verifying delivered results. Those are all things that are important in an Agile world. I suggest it’s worth a fresh look at the “scaled down,” real-time version of some of DMADV tools and thinking.
2) As drjones13 indicated, LSS can help us understand and continuously lean the design/development/support processes. DMADV helps get “the product” right, and LSS applied to the Scrum model, say, helps get “the process” right. Every software development model tries to deliver working features and measurable customer value, while “burning up” effort ($$) and time. LSS helps us see the flow, the constraints, the cost and the time drains.
In short, I think there are more DMADV and LSS links and support points for Agile than meets the eye. If we are ever going to help the Agile community see those links, though, we have to appreciate the way Six Sigma manufacturing and waterfall process history can get in the way, and to provide some fresh views and examples of how the essence can be re-cast in Agile-useful ways. Through a number of iSixSigma articles, conference presentations, and ongoing work in Lean software development, I’m trying to help that fresh view to happen.
KEL: What has to be avoided is xenophobic behavior on behalf of both the Scrum and Lean Six Sigma cultures. You and I both know people who will consider only one approach to solving a problem or designing a new offering. Use of multiple tools where appropriate is the key. Too many efforts have been compromised by people trying to make one shoe fit all.
jeff: Successful companies will ultimately develop an Agile process that works for them. Working in a company that has [implemented] Six Sigma and Digital Six Sigma, one really finds that Scrum works with the engineering management of the software developers. What Agile does help accomplish – and Scrum the best of all – is to put focus on high-priority and low-priority items. Furthermore, another benefit is that Agile encourages teams to take ownership and passion for the software they create. ?
[For] software engineering professionals, the major problem is explaining to upper management how Scrum/Agile really does work and how this will ultimately benefit them in the long run. Tools like VersionOne are extremely helpful in aligning management and engineers to execute the Scrum plan successfully. Any comments?
Marcelo Udo: Where I work, we are glad to working with Six Sigma, Lean and Scrum. From the point of view of Lean software development, created by Mary and Tom Poppendieck, we implemented a kind of knowledge engineering in the knowledge acquisition tasks. After we put knowledge management to work together with project management, we continued implementing some Lean tools, like value stream mapping, kanban pull systems, set-based development, Lean metrics, 5S, OEE [overall equipment effectiveness], queuing theory, and so on. For bottlenecks, we implemented Theory of Constraints.
Our project management was fragile and it needed to be Agile. We listened to Scrum and critical chain, so we implemented Scrum for project planning and project monitoring and control. In part of the schedule, we implemented critical chain to simulate multiple projects.?
To give support to any conflict, innovation, and process improvement, we alignned all IT needs to business to customer satisfaction (VOC) by implementing Lean Six Sigma DMAIC or DMADV methodologies to better define goals and gains. Therefore, we believe most of all that Lean Six Sigma with Scrum gives to software development organizations what is necessary to achieve incredible results.
jeff: I totally agree with you. A lot of upper management sees the old ways while lower management (engineers) see the newer way. We need to adopt a means so that Agile principles are the cornerstone of software development, [the same way that] DMAIC processes are the cornerstone of software quality. For example, DFSS can be used to significantly quantify the quality of test metrics for software where the “backlog” of Scrum can be used to motivate the software development team to identify defects quickly and early on.
I really like the standup meeting idea of Scrum. It allows all team members to be able to quickly identify any impediments they see upfront. Tools like VersionOne are really useful in standup meetings, as they quickly help team members become aware of the status of all others. One impediment of Scrum is that it does not work well in my opinion when team members are involved in multiple projects, which is typically the case as Scrum … works well on one team. I still think the DFSS works well for quality control if implemented properly to measure defect issues.
To see other conversations on the use of Six Sigma in the the software or IT space, or to start you own discussion, please visit the Software/IT section on our forum.
