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

22259RE: [scrumdevelopment] Re: Origins of Scrum

Expand Messages
  • Ken Schwaber
    Jul 1, 2007
    • 0 Attachment

      I certainly run into a problem here. The first principle books for Scrum refer to it either as a defined or empirical approach. In our industry, this probably would be better known as command-and-control/prescriptive, or empirical.


      There is certainly definition in empirical, but it is only enough to create one increment to inspect and adapt on (be empirical about). This increment is either what a team members produce for a daily scrum, or what a team produces for a sprint planning meeting.


      The biggest difference is attitude. Defined/Prescriptive is based on Frederick Taylor’s approach in Scientific Management. If you lay it out perfectly in a plan and follow the plan, you will achieve your goal. The empirical approach says that the complexity is too great to rely on any plan. Lay out goals and proceed, keeping your eyes open and doing your best to achieve the goals.




      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Peter Alfvin
      Sent: Sunday, July 01, 2007 1:39 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Origins of Scrum



      Thank you for pointing to your 1996 Origins of Scrum article.  It provided helpful background on your thinking.

      One of the concerns I've had with the whole agile adoption process and to some extent the Scrum adoption process, is the drawing of false dichotomies within the software engineering community and the related demonization of entire domains of knowledge and associated institutions, particularly as it relates to process management.  I know that Jeff has worked to show how Scrum can be used as part of achieving CMMI Level 5, but it seems that many do not appreciate this and tend to equate IEEE/SWEBOK and SEI/CMMI to waterfall development, big up front requirements and design, detailed PERT charts, etc., and want to write them off accordingly.

      The heart or this false dichotomy, it seems to me, is a failure to distinguish between the generic management and engineering processes used to development systems and the specific process used to develop a specific system.  There also appears to be some ambiguity around the definition of a defined process.   I was hoping to get your feedback on both these points.

      I may have this wrong, but it seems me to that the CMMI and traditional software industry notion of a "defined process" is essentially a documented process that is understood and executed by its practitioners, is essentially repeatable and is under some form of control.  By this definition,  Scrum itself is a "defined process" that spans the domains of project management and process management.  It's well documented in your book and quite prescriptive in terms of roles, steps, sequencing and duration of the project and process planning and control tasks (e.g. time-boxed Sprint Planning, Sprint Review, Sprint Retrospective meetings as prescribed in Appendix B).  To it's credit, it is largely repeatable.  And finally, it is under the control of the Scrum Master, who is the only one you can approve changes in the Scrum rules.  [Note: This is ironically reminiscent of Taylor 's assertion that only management is capable of understanding the process well enough to understand it, let alone control it.  I don't mean at all to equate the Scrum spirit with Taylorism, which is clearly at the other end of the spectrum in terms of respect for workers, teamwork, etc.; I'm only trying to make a point here about process control.]

      By contrast, the definition of defined process referenced in your paper goes beyond this definition to say that a defined process is one that is fully understood based on first principles (e.g. physics, etc) and therefore not subject to change.  It goes on to make the obvious point that building systems cannot possibly be understood at this level, so it's absurd to treat system development as a defined process and that you must plan adaptively, have empirical process controls in place, etc.

      Given the above, when Ken Schwaber says:

      "Defined processes" are an inappropriate process model for "building systems/software" .

      many people hear:

      We shouldn't have "documented and repeatable processes" for any of our "software engineering disciplines" . By extension, CMMI, which is based on "defined processes", is inappropriate.

      In other words, I think the term defined process is badly overloaded and I think people are confusing the process represented by "the project plan" with the process used to (say) develop the project plan.  It seems to me that it would be helpful if you could:
      1) Emphasize the benefits of empirical process controls without having to reference/denigrate "defined processes" (i.e. avoid the overloaded term), and/or
      2) Emphasize that while the steps to design a specific system do not meet the criteria of a defined process, (i.e. you cannot produce a useful detailed plan to produce a complex system), you can define repeatable processes associated with the various software engineering disciplines, including the project management process (a la Scrum).


      Pete Alfvin



    • Show all 39 messages in this topic