This article discusses briefly how Scrum could support Six Sigma projects. Issues of whether Six Sigma is used specifically in software or other product development are not considered. If you ask yourself "Why should Scrum support Six Sigma projects?" I can promptly reply, "Why not?"
Scrum promotes cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.
In today’s work environments, research proves that distributed Scrum teams can achieve the same quality results as collocated teams, but relationships, communication and culture play important roles in the latter.
When it comes to Scrum, I'm a newb. I got my CSM certification last year and have been slowly learning how best to introduce Scrum to my organization. Recently, I started using Post-its to enhance how we use Scrum.
In 1993, at Easel Corporation in 1993, we we first applied the Scrum process to software development teams when we built the first object-oriented design and analysis (OOAD) tool that incorporated round-trip engineering. In a Smalltalk development environment, code was autogenerated from a graphic design tool, and any changes to the code from the Smalltalk integrated development environment (IDE) were immediately reflected back into design. Since the product was directed toward enterprise software development, we spent a lot of time analyzing best practices in software development methodologies.
It is often said that to truly understand someone else, one must walk a mile in that persons shoes. Similarly, taking on more than one role on a Scrum team, on a temporary basis at least, can have unexpected advantages that may offset the disadvantages.