Scrum derives directly from the Takeuchi and Nonaka paper in the
Harvard Business Review, "The New New Product Development Game." The
best example in this paper is Honda and their style of product
development. I gave this paper to Kent Beck at his request in 1995
when he was putting together eXtreme Programming.

The Scrum daily meeting derives directly from the Borland Quattro Pro
paper by Jim Coplien.

Complex adaptive systems theory, particularly as implemented by iRobot
using Prof. Rodney Brooks subsumption architecture, was used to
implement simple rules to allow an average team to boot up into a
hyperproductive state.

All of this occurred in 1993. The great results delivered by Scrum
with new products in 1994 and 1995 got Mike Beedle and Ken Schwaber
interested in the process. Ken clarified the process for global
consumption beginning in 1995 and Mike Beedle led the effort to write
the PLoP patterns paper on Scrum pointing out that it is an
organizational pattern to allow teams to achieve a hyperproductive state.

The first Scrum team starting in 1993 rapidly achieved a
hyperproductive state by implementing all of the engineering practices
now known as XP, along with some that are not in XP. In particular, it
used stragegies for choosing Sprint backlog items that generated the
most rapid appearance of new features. This forced not only test first
development (and document first as well) but created a strategy
similar to Toyota's concurrent engineering.

Few implementations of Scrum achieve the hyperproductive state for
which Scrum was designed (5-10 times normal performance). Those that
do all implement variations on XP engineering practices and many, like
the CMMI Level 5 implementation of Scrum (which has not achieved the
hyperproductive state yet) drive the whole implementation from a lean
perspective.

Takeuchi and Nonaka are the godfathers of Scrum and gave it the name.
Their latest Hitosubashi book clarifies and extends their work in the
orginal Harvard Business Review paper and it useful for those trying
to achieve a hyperproductive state. There is a lot of lean in there.

The first Scrum was influenced by concepts from Goldratt's constraint
theory and focus on muri, mura, and mudah. Elimination of disruptions
in flow was initiated after the first few Sprints to eliminate reset
times between Sprints, now accepted as a best practice in Scrum. Mura,
or avoidance of stress on an person, system, or process yielded
hyperproductive states combined with zero attrition in several of the
Scrum companies where I led engineering. This is now known as
sustainable pace in Agile development. Finally, Mudah, or radical
reduction in waste has always been a primary driver in all the
companies where I implemented Scrum. You cannot achieve a
hyperproductive state without it.

Jim Coplien has pointed out repeatedly over the years that there are
down sides to constraint theory and some XP practices which should be
avoided. I've done my best to sidestep the potholes he has pointed out.

Scrum was specifically designed to deal with:

Ziv's law - specifications will never be fully understood.
Humphrey's law - the user will never know what they want until after
the system is in production (maybe not even then)
Wegner's lemma - an interactive system can never be fully specified
nor can it ever be fully tested. This is the software analogy to
Godel's theorem.
Langdon's lemma - software evolves more rapidly as it approaches
chaotic regions (taking care not to spill over into chaos)

Thus any association of predictive or defined processes with Scrum is
an exercise in futility.

That said, I am entirely in agreement with Ken, that all of this
should be driven by "inspect and adapt" and building a prioritized
impediment list. Working off the impediment list in priority order
will streamline flow, reduce stress, and eliminate waste in the
correct sequence and failing to do so will, ironically, result in
violation of lean principles.

Jeff Sutherland

"There is a spectrum of work in which Langdon is at one end and Brooks
can be thought of at the other. At Langdon's end, the goal is to
create virtual simulations (nothing physical) that exhibit
characteristics such as evolutionary change and emergent complexity.
Much of this work was done in conjunction with the Santa Fe Institute,
and was big a decade ago. Much of the excitement around it has died
down. At Brooks' end, roboticists use models from real organisms to
organize their structure. Early works in this vein included an
artificial cockroach, and it has been a feature of Brooks' MIT
research for the last 15 years or so. Although both are biologically
inspired, the goals and methods are quite different."
http://hci.stanford.edu/academics/cs378/wiki/Main/ArtificialLife

--- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
>
> Interesting perspecitves, Mike. I'll have to noodle over this a bit
> more.
> Robin Dymond (on this list) once told me during a phone call that
> "lean deals with known work; agile deals with unknown work." That was
> so pithy I wrote it down and it's on a note card in front of me. It
> seems to fit with your perspective.
> Regards,
> Mike Cohn
> Author:
> Agile Estimating and Planning
> User Stories Applied
> www.mountaingoatsoftware.com
>
>
> On Jul 5, 2007, at 7:23 AM, Mike Dwyer wrote:
>
> >
> > Mike
> >
> > From where I stand, deep in the weeds, Scrum and all of agile is
> > the forward leaning – empirical – implementation of improvement
> > while Lean and its family of tools including Six Sigma is the
> > backward leaning – analytical – refinement of improvement. While
> > both schools address the same problem LEAN relies on the past to
> > tell it where to look in the present to improve a specific aspect
> > in the future, this makes it a reaction to a situation in the past.
> >
> >
> > Agile and Scrum stay in the Present, empirically inspect current
> > actions and make multiple changes over a short period of time to
> > immediately improve the outcome of the effort a teams creates to
> > make something work for the client.
> >
> >
> > This is not to say that one school dominates an other, as they both
> > have their limits. Agile and Scrum (IMO) are tuned for emergent
> > work where the solution or DONE as I have called it is not fully
> > understood.
> >
> >
> > Lean and Six Sigma are suited for established patterns of work
> > where the solution or DONE has been attained and now needs to be
> > improved through regressive analysis.
> >
> >
> > Here lies the analytical tipping point. Lean functions best with
> > repeatable, predictable, events (hopefully captured in reliable
> > data) and is able to refine and improve things by doing root cause
> > analysis. Agile and Scrum function best when there are none of
> > these road markings.
> >
> >
> > Scrum and Lean can work together in transforming existing
> > situations if they each take their role and are careful to provide
> > the other with the tools they need. For Scrum and Agile that
> > means creating good metrics that can form the base for doing the
> > analysis. For Lean is the reliance on metrics to determine next
> > steps. A customer can use both of these to their advantage if
> > they realize that both cause failure when applied in the wrong
> > space and both add value when applied in areas of strength
> >
> >
> > Michael F. Dwyer
> >
> >
> > "Planning constantly peers into the future for indications as to
> > where a solution may emerge."
> >
> > "A Plan is a complex situation, adapting to an emerging solution."
> >
> > -----Original Message-----
> > From: scrumdevelopment@yahoogroups.com
> > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Cohn
> > Sent: Wednesday, July 04, 2007 12:11 PM
> > To: scrumdevelopment@yahoogroups.com
> > Subject: Re: [scrumdevelopment] Re: Origins of Scrum
> >
> >
> > Hi Brad--
> >
> > I completely agree with you on this. It's been a pet peeve of mine
> > that there seems to be an effort to recast Scrum (all of agile) as
> > a derivative of Lean. The two are entirely compatible but I share
> > your opinion that Scrum is neither based on nor rooted in Lean.
> >
> >
> > In "Leadership and the New Science" (which is about complexity,
> > CAS, and other things that did lead to Scrum) Margaret Wheatley
> > wrote about how ideas may arise concurrently in different groups or
> > parts of the world. Calculus being independently and nearly
> > simultaneously invented by Leibniz and Newton is a good example of
> > this. The "time was right" and so it happened but neither's work
> > was based on the others. There was a lot going on in the mid-1990s
> > that led to the creation of Scrum and lean just "being in the air"
> > could be a part of it. I find lean to be a reaction to inefficient
> > manufacturing and agile to be a reaction to inefficient software
> > development. The inefficiencies now look similar but I don't recall
> > anyone saying they were the same back then. I remember reading
> > Goldratt's "The Goal" (a lean book) around 1990 for the first time
> > and thinking, "Hmm, I bet this relates to software somehow; but I
> > can't quite see how; oh well, time to get back to coding...." He
> > had to write Critical Chain years later to show how lean ideas
> > could apply to projects.
> >
> >
> > To use another "new science" example: a common misunderstanding of
> > evolution is to say that humans descended from apes rather than
> > that apes and humans evolved independently into forms that aren't
> > all that dissimilar. Because we live in largely similar
> > environments we have evolved to adapt in similar ways.
> > Manufacturing and software development companies are evolving and
> > adapting and now we're finding that those adaptations have been
> > similar because the problems were similar. It doesn't mean one is
> > based on the other any more than humans are based on apes.
> >
> >
> > Regards,
> >
> > Mike Cohn
> >
> > Author:
> >
> > Agile Estimating and Planning
> >
> > User Stories Applied
> >
> > www.mountaingoatsoftware.com
> >
> >
> >
> >
> >
> > On Jul 4, 2007, at 9:47 AM, Brad Appleton wrote:
> >
> >
> >
> >
> > Much as I like the stuff Alan writes, I don't see how Scrum is somehow
> > based, or even rooted, in Lean.
> >
> > My knowledge of Scrum roots & history comes from Mike Beedle (co-
> > author,
> > with Ken, of the first Scrum book, and with Ken, Jeff Sutherland
> > et.al.
> > of the Scrum "extension pattern language" from PLoP'98), as well as
> > from
> > the earliest days of the controlchaos.com site in the late 90s.
> >
> > Mike and I were (are) both in the same metropolitan area and helped
> > kickoff a local patterns discussion group back then (around '97). And
> > the stuff that Mike talked about regarding Scrum was always rooted in
> > material from Nonaka & Takeuchi ("The Knowledge Creating Company") and
> > complexity theory: self-organizing systems, emergent behavior, complex
> > (non-linear & dynamic) adaptive systems, distributed autonomous
> > collaborating agents, and even elements of catastrophy theory that
> > deal
> > with the "edge of chaos".
> >
> > And I remember Mike using the term "empirically managed" and
> > constrasting that to "statistically controlled" and "defined &
> > repeatable". Learning organizations and the work of Senge & others
> > were
> > often mentioned. And the term "Agility" (as it was then used in the
> > lingo of organizational change management - since this was before
> > we in
> > the software community used the term "agile methods") was often
> > bandied
> > about.
> >
> > I dont see how those things are rooted in Lean, tho I can see how Lean
> > might share some of the same roots. I can see how the emergence and
> > self-organization and dynamic adaptation aligned toward a
> > particular set
> > of shared goals & objectives might result in doing things that are
> > "Lean" in order to reach those objectives (of hyperproductive teams).
> > But I dont ever recall Lean and any of its terms/vocabulary being used
> > as the basis for what was defined in Scrum. I think Lean just happened
> > to be a very successful way of achieving objectives laid out in the
> > application of Scrum.
> >
> > respectfully
> > --
> > Brad Appleton <brad {AT} bradapp.net>
> > Agile CM Environments (http://blog.bradapp.net/)
> > & Software CM Patterns (www.scmpatterns.com)
> > "And miles to go before I sleep" -- Robert Frost
> >
> >
> >
> >
> >
> >
>