Loading ...
Sorry, an error occurred while loading the content.

Origins of Scrum

Expand Messages
  • Ken Schwaber
    Lean thinking, theory of constraints, and the second law of thermodynamics. What do they all have in common? They all have been described as being the basis
    Message 1 of 39 , Jun 27, 2007
    • 0 Attachment
      Lean thinking, theory of constraints, and the second law of
      thermodynamics. What do they all have in common? They all have been
      described as being the basis for and the root of Scrum. The danger is
      that someone will study lean thinking or any of these and think that
      they know Scrum. This isn't true because Scrum didn't originate in any
      of them. Instead, they have many similar insights that can be used to
      elucidate Scrum thinking, but they must be applied with common sense
      within the context.

      A useful tool in thinking through a problem while using Scrum is,
      "what does lean thinking have to say about this," and to look and
      incorporate useful ideas. A useless tool in thinking through the same
      problem is, "what does lean thinking have to say about this," and
      blindly applying the result because you believe that Scrum originated
      from lean.

      I presented a paper in OOPSLA'96, "Controlled Chaos: Living on the
      Edge" that describes the origins of Scrum. Scrum had emerged from best
      practices that Jeff Sutherland and I understood, and time tested
      within the industry. However, it wasn't until I understood empirical
      process control theory that I understood why what Jeff and I were
      doing worked.

      Our approach embraced complexity - expecting it and handling it by
      using inspection and adaptation to optimize the results. The more
      traditional approach, defined or prescriptive (Frederick Taylor,
      Scientific Management), attempts to shake the complexity out before
      starting, and then make a mad dash toward the goal before something
      changes.

      Everything you see in Scrum revolves around inspecting and adapting to
      optimizes goals in a complex environment. Team size, sprint length,
      "done" increment, integration, etc. Lean and the others talk about
      this too, but the root is empirical process control

      I find it useful to relate to lean thinking when I describe Scrum
      adoption because manufacturers have as much trouble going lean as
      product development people have going Scrum. And, for the same
      reasons: a new way of thinking and perceiving has to be learned and
      adopted, and an old way of thinking and perceiving has to be discarded.

      I've posted the original document at
      www.controlchaos.com/scrumorigins.pdf.

      Regards,
      Ken
    • Michael Spayd
      Hi Alan, On 7/5/07, Alan Shalloway wrote: I have made several posts illustrating these connections. Ironically, there has been more
      Message 39 of 39 , Jul 5, 2007
      • 0 Attachment
        Hi Alan,

        On 7/5/07, Alan Shalloway <alshall@...> wrote:
         
        I have made several posts illustrating these connections.
        Ironically, there has been more discussion on my restatement of
        _Jeff's_ assertion (as if _I_ had come up with it when I have
        already said isn't that important anyway) than there has with
        whether my comments about using Lean in the way I do is correct or
        incorrect. I am certainly interested in people's opinions if they
        think my posts are useful, useless, questionable, unclear, concise,
        … (whatever).
         
        Thanks for clarifying that, Alan, it was a bit annoying that others seemed not to understand your intent. I can't comment on your use of Lean except to say it makes good sense to me (I am knowledeable, but can't claim to be an expert in Lean). I would like to emphasize another point of yours in the Agile methodology realm where I can claim expertise (or at least old dog status). That is, you first distinguished principles from practices, then said something to the effect that Scrum does not have clearly articulated principles (unlike XP or Crystal, for instance), even if the practices are quite clear.
         
        For me, this was a very useful observation. It is a big gap, IMO. Dave Barrett (above) did what I take to be a good first draft at articulating some principles, but these have clearly not been validated by the Scrum community. I believe, as Dave indicated, they the underlying set of Scrum principles are few and simple, but unarticulated nevertheles.
         
        Does that make sense to others? or do the rest of you just believe  that that would be helpful? Again, the principles in an Agile methodology do not change (though they might slowly evolve), whereas the practices are adapted by a self-organizing team and a competent coach according to experience and circumstance (and using the applications of the relevant principle).

        Comments?
         
        Michael

        --
        Michael K. Spayd
        Cogility Consulting Solutions, LLC
        "Business Mind, Social Heart"
        michael.spayd@...
        720.300.5286

        "Leading Agile Enterprise Transformations"
      Your message has been successfully submitted and would be delivered to recipients shortly.