Re: [scrumdevelopment] Agile and 6 Sigma
- From a root philosophy standpoint, I tend to agree with Alistair.
Six Sigma tends to emphasize rigorous documentation and
quantifiable measurements -- even when developing the
documentation and analysis delivers little real value. This is,
of course, directly opposed to the philosophy of developing the
minimum documentation, code, etc, required to confidently
deliver the product.
That said, I think it is possible to map XP@Scrum activities into
a Six Sigma DMADV framework. I haven't fully thought this
through, but I've been kicking it around for a while. Any comments
are most welcome.
Sigma DMADV Phases & XP/Scrum Deliverables
- User Stories
- Functional Requirements
- Non-Functional Requirements
- Product Backlog
- Committed Sprint Backlog
- Management Tests (from industrialXP)
- Acceptance Tests
- Management Tests (current state)
- Sprint Backlog Burndown
- Customer/Developer Design Sessions
- Alternate Design Concepts
- Prototypes (paper, code, etc)
- Unit Tests
- Working Code
- Design Documentation (as appropriate)
- Acceptance Tests (outcomes)
- Management Tests (outcomes)
- Customer Feedback
- Sprint Review Meeting
Then loop-back and repeat for the next iteration.
I think this mapping could work in a Sigma organization,
provided the Master Black Belts understand the reason
for taking an "inspect and adapt" approach like XP@Scrum.
Since Sigma came out of a manufacturing environment,
many MBBs may be able to see the correlations between
Scrum and industrial process control theory (maybe Ken
or someone else can expound further on the connections?).
Hope this helps.
>Subject: Re: [scrumdevelopment] Agile and 6 Sigma
>Date: Tue, 30 Sep 2003 11:40:12 EDT
>In a message dated 9/30/2003 9:34:30 AM Mountain Daylight Time,
>I've had great success with Agile, and wish to continue developing in
>this manner, however the 6 Sigma wave is upon us. My concerns on how
>well these 2 methodologies can integrate are increasing. Has anyone
>found a way to merge the 2 or experimented on weather the 2 can
>Thanks in advance for your replies,
>---> My take is that there is a fundamental opposition to the two.
>Some agile techniques can be used anyway, but the *intention* or value of
>staying agile and the intention or value of being correct lead to different
>for a discussion.
>Dr. Alistair Cockburn
>President, Humans and Technology
>Program Director, Agile Development Conference
>1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
>Phone: 801.582-3162 Fax: 775.416.6457
>"La perfection est atteinte non quand il ne reste rien a ajouter,
>mais quand il ne reste rien a enlever." (Saint-Exupery)
Instant message during games with MSN Messenger 6.0. Download it now FREE!
- --- In email@example.com, Brad Appleton <brad@b...>
> I don't know who has applied this to software development,What little I know about six sigma (I'm just getting started
> but in theory at least "Lean" and Six Sigma are compotible,
> so I would imagine it possible that Agile and Six Sigma are
> compatible as well and it all comes down to the implementation
> and execution in practice
myself), indicates that it will work in an Agile environment.
Our product falls under FDA control, and we wondered how we would
implement Scrum and what the FDA needed. What we discovered was
that the FDA didn't dictate any given process.
What I'm finding is that these external processes have requirements
and control points that you need to insert within your daily
schedule (things you have to do to make the given process work - its
a machine and you need to turn the crank).
Scrum wasn't so much a process - it was a tool for getting processes
done. Whatever your process is - you just insert them within your
The FDA is pretty much about documenting everything- having defined
processes and follow them (and "prove" that you followed them - if
you don't write it down, it didn't happen). We just documented our
implementation of Scrum (and how our life cycle worked). The FDA
and Six Sigma have different purposes.
I expect six sigma to be the same. A set of control points to
insert into our current process and metrics to record (and feed into
some machine). The hard part is always... Just Doing It. Agile is
about doing whatever needs to be done and throwing the rest aside.
So you decide what you want from the process and do those parts (and
some parts aren't optional).