Scrum as the Six Sigma Council see it
The following is a quote from the six sigma study guide (Lean Six Sigma Black Belt Certification Training Manual).
Scrum projects feature three main phases:
- The pregame. Development teams analyze available data and business requirements. They use this information to come up with the concept for the new product or upgrade. Often, this involves translating business and process concepts into computer and technical concepts.
- The game. Teams begin to develop the product via programming sprints. Sprints are smaller phases of development that are completed in sequence, usually with a review and validation of the work before moving on to the next sprint. By validating work during development, teams are able to create working products faster.
- The postgame. Even though validation occurs during development, teams still have to follow quality assurance, testing, and change management procedures. Quality preparation for product release is handled in the final phase.
I shared this with the intention to demonstrate what do non-IT managers see of Scrum at large organisations. I came across many disputes on several forums whether Scrum covers the definition phase and the go-live phase of a product. In complex environments, I believe it does not.
I can state from my personal experience that I have found non-IT managers are more willing and open to adopting Scrum as described in the Scrum Guide. Not many non-IT managers in large (and even small and medium orgs) see Six Sigma as promising as they used to.
I can attribute this to a few things:
- The inability of Six Sigma to respond to change sooner.
- The inability of Six Sigma to guide strategy based on the market condition. Six Sigma tends to favor the elimination of waste and error. It focuses largely on product quality perspective and related processes only and is deficient in addressing other quality perspectives which guides the market reception.
- It fails to address leadership development.
These issues are quite prominent in the non-IT environment. What we can see is that the Six Sigma Council has religated quality to "the postgame". Probably due to the fact that it focuses on product quality and in my opinion, has a myopic view about quality improvements that take place during every event, with every artifact, by every role and with the help of every rule.
My personal (anecdotal) experience suggests to me that professionals with IT background tend to follow metrics more than the non-IT managers even if it doesn't make sense to do so. Non-IT managers, however, get the sense of Scrum pretty quickly and respond to it, since they are able to visualize the quality improvements it brings tangibly at every stage of the project or product they are dealing with.
The dispute about the coverage of Scrum is inevitable in circles where Scrum is seen only as a means to develop and deploy products and nothing more.
Thanks for posting this, it is better than Edgar Allan Poe and is most likely the scariest thing I will read this side of Halloween.
Quality preparation for product release is handled in the final phase.
I did a small amount of research. It seems like the Lean Six Sigma Black Belt Certification Training Manual comes from an organization known as the Six Sigma Council. Although their name sounds pretty impressive, it's just a name. They don't seem to be any more official than any of the other organizations offering training and certification in Six Sigma or Lean Six Sigma.
I'm also not sure why a Six Sigma study guide or certification program would care about Scrum. There's plenty of relevant knowledge areas and tools related to designing and implementing Six Sigma programs and you don't need to get into various methodologies to implement them. It's even more concerning that they would not only get into this level of detail, and then get the details so wrong.
I would hope that people don't take this as any relevant interpretation of Scrum. Not only is it not useful, I'd consider it actively harmful in understanding Scrum or, more generally, agility.
They don't seem to be any more official than any of the other organizations offering training and certification in Six Sigma or Lean Six Sigma.
Sure, even though they are one of the oldest and largest.
I'm also not sure why a Six Sigma study guide or certification program would care about Scrum.
They sacrificed about 0.6 page out of seven hundred, for introducing Scrum. Almost just a side-note that business and process improvement may involve software.
Actually, they continuously improve this document, but it would not surprise me if this section were added pre 2010. I guess they would be happy to update it if scrum.org advises so:)
I believe the deep interest is true for those who are directly involved in or impacted by Scrum. But when your development team is in India, your tech suppliers are in China, your research teams are in Switzerland and South-Korea, your service centre is in Eastern Europe, your legal address is in Ireland and you are headquartered in the US - where your process improvement specialists are working, then Scrum is really not your area of concern.
has a myopic view about quality improvements that take place during every event, with every artifact, by every role and with the help of every rule
But it is a cornerstone of six sigma that you cannot add quality at the end of the process. All the more outrageous...
The dispute about the coverage of Scrum is inevitable in circles where Scrum is seen only as a means to develop and deploy products and nothing more.
I am afraid it is more than just a matter of intention. In a large, complex environment where scaled agile is only 'heard about', Scrum typically equals water-scrum-fall since that is what the rest of the organisation can handle. Ironically, this is a process improvement opportunity, thus could be targeted by lean six sigma;)