Tag Archives: SPC

  • -

Expert Reviews of the Scaled Agile Framework (SAFe) Training

Tags : 

Reviews of SAFe Program Consultant (SPC) training on the Scaled Agile Framework (SAFe), from Agile and Scrum experts


I have been following with interest the Scaled Agile Framework and its increasing popularity. There have been a number of reviews of the training to become an SPC or SAFe Process Consultant. I am also interested because SAFe came out of work done by Dean Leffingwell and other consultants at NAVTEQ in the US in 2010-2011. At the time I was providing Certified Scrum training to NAVTEQ subsidiaries in Germany who were implementing Scrum. I did not work with the US groups, however I am familiar with what was happening at NAVTEQ at the time. So I think any review of SAFe should include how it helped or did not help NAVTEQ be more successful as an organization. In the last few years since implementing SAFe, NAVTEQ has gone through a major downsizing, been acquired by Nokia, and then shrank some more. Speaking with a former Director from NAVTEQ now at another GIS client of mine, the automotive division is doing OK, but the rest of the company struggling and shrinking in the face of competition from Google and others. There are many reasons why companies fail, and we cannot blame SAFe for the shortcomings of NAVTEQ’s organizational culture and business model. However we can and should ask: how did SAFe help NAVTEQ?

In reviews the Scaled Agile Framework and SPC training, a number of experts Agile and Scrum have commented on their experience in the training, the training style, and the substance of the ideas in SAFe. Below are links to expert reviews of SAFe and SPC training.

Agile experts Ron Jeffries and Chet Hendrickson who are authors on extreme programming and Scrum, consultants and trainers recently took the SPC training in Washington DC. Ron’s review takes the stance that SAFe has some good things that Scrum or XP do not address, and he goes through those points in detail. Ron is an excellent writer and thinker, and I enjoyed his analysis of SAFe and the training. I think this is the best review so far.
Scaled Agile Framework. SAFe: Good but not good enough.

Peter Saddington, a fellow Scrum trainer and consultant based in the DC area recently took the SPC course in Washington DC. Peter gives a balanced review of what he sees as the pros and cons of SAFe. While he likes Lean aspects SAFe has borrowed, he thinks the recommended “one week” roll out period carries significant risk. Peter strives to be open to the ideas that are contrary to some of the core principles and values of Agile. His highest praise is for SAFe’s marketing.
Review of the Scaled Agile Framework SAFe SPC training and ideas

Scrum trainer Daniel Gullo recently took the Scaled Agile Framework and SPC training and reflected on the ideas and how they compared to his experiences working on Agile adoptions in large organizations. Daniel was also a agile consultant at NAVTEQ helping them adopt Scrum while the Scaled Agile Framework was first being implemented at NAVTEQ. “As long as I am able to work with a client implementing “SAFe” and we are allowed to tailor it to include the helpful parts and throw out the harmful parts, I don’t see anything really evil or wrong with SAFe here. What we are left with is doing precisely what I have already been doing for the last 8 years: looking for how to instill the values and principles Agile and Lean in the culture of an organization so that a paradigm shift happens.”
Review of the Scaled Agile Framework SAFe SPC training and reflection on SAFe compared to Agile Coaching experiences

David Snowden, creator of the Cynefin (pronounced Kan av in) framework, a practical application of complexity theory to management science, recently weighed in on SAFe. In Dave’s post he weighs in on SAFe’s linear model and one size fits all approach. Snowden’s background is in complexity theory, and he knows that simple linear approaches fail to solve complex problems. Dave’s evaluation of SAFe is that it is not Agile.
SAFe: the infantilism of management

Enjoy the reviews of the Scaled Agile Framework and SPC training. I will post more reviews from experienced Agilists on SAFe and the SPC training.


  • -

Lean Six Sigma: Are DMAIC Demons Possessing Lean?

Tags : 

Halloween is a few weeks away, and the strange world of the dead, undead, partially dead, or dead fashion is inhabiting the shopping malls. Over the last two years I’ve watched another kind of possession has happened in business thinking. Once the darling of Motorola, GE, Bank of America and others Six Sigma has been falling out of favor. Six Sigma’s DMAIC model, its emphasis on gathering statistical data and focus on elimination of variation has floundered in knowledge work. Knowledge work has at its heart, people. There is no machine stamping parts. In knowledge work, the work being done is continuously varying in size and complexity. The work of problem solving is done in people’s brains, and the effective flow of information in the work system controls errors. All of the variation in these complex adaptive systems means trying to eliminate variation is a zombie’s errand. Lean and the Toyota Production System are principles based. Many of the ideas in Lean can be applied to Knowledge Work. Ideas like Respect for people, Pull, Flow, Visual Management, Value Stream Mapping, Systems Thinking and Continuous improvement all make sense in Knowledge Work. These Lean and TPS ideas can be used with systems that adapt and change based on the variation inherent in the work.

Over the last few years Six Sigma consultants have started to re-brand themselves as Lean Six Sigma consultants. The adoption of Lean onto their business cards is partly a survival strategy. If Six Sigma’s not selling and Lean is, then let’s “do” Lean too. The problem is that Lean and TPS come from a very different perspective on work than Six Sigma. For example Six Sigma’s DMAIC process is:

  • Define the problem, the voice of the customer, and the project goals, specifically.
  • Measure key aspects of the current process and collect relevant data.
  • Analyze the data to investigate and verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered.
  • Improve or optimize the current process based upon data analysis using techniques such as design of experiments, poka yoke or mistake proofing, and standard work to create a new, future state process. Set up pilot runs to establish process capability.
  • Control the future state process to ensure that any deviations from target are corrected before they result in defects.

There are some major problems with the DMAIC approach when dealing with knowledge work:

  • Defining the problem with voice of the customer is great. However what if the customer can’t articulate what they want? Every software customer I have worked with did not have a functional crystal ball. They can often describe at a high level their needs, but they do not yet have enough information. The only certainty is that they won’t have enough information. Neither do developers.
  • The underlying assumption of Six Sigma is that the process under study is a repeatable process producing the same type of work product and subject to some statistically relevant variance. Measuring aspects of the process gives data to better understand where variation occurs. In Knowledge Work such as software development or marketing campaign creation the work is continuously varying so the measurements measure a complex adaptive system, not a repeatable process.
  • Analyzing the data gathered will provide some insights. Let’s say that data reveals a problem and a solution is found. Putting an improvement in place will definitely help. We may rarely do that type of work again. What happens when down the line a different problem occurs that we have never seen and do not have a measurement for?
  • How do we know we have the most correct process just from analyzing work in our current process? In Knowledge work, the work itself often impacts the process.

Six Sigma’s underlying assumptions fail to account for complex adaptive work systems that rely on people to do the problem solving and rely on information flow to do error correction. So why do people apply Six Sigma processes to knowledge work and what happens when they do? More on this later…. time to catch a plane.