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).
- 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,
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).
Michael K. Spayd
Cogility Consulting Solutions, LLC
"Business Mind, Social Heart"
"Leading Agile Enterprise Transformations"