I suggest that Scrum is a methodology which I define as a set of principles
and processes, in this case with a heavy emphasis on the principles. I
believe Method/One and other (massive) methodologies focus more heavily on
the cookbook approach because they have been augmented over the years with
additional detail, tools and templates. My copy of a Method/One binder for
a project 3 years ago is 600 pages with 240 deliverables and innumerable
process steps. But, if you want several thousand people to use the same
methodology the same way, maybe this is what you need.
But Method/One and other massive methodologies are totally inappropriate in
situations where there is either high uncertainty or low agreement. Where
this is a case, a process where you "manage to a vision", using empirical
project management approaches and a hands-on style is more appropriate.
Ralph Stacey proposed a certainty matrix to select the appropriate
management process for a complex environment based on level of uncertainty
and level of agreement
. Interpreting this
matrix in a project management/ application development context points to
the use of traditional waterfall, cookbook methodologies where there is a
high level of certainty and agreement -- we know want we want to do and we
know how to do it so the best approach is to plan the work and work the
plan. In an environment of greater uncertainty, a process based on
iterative or evolutionary delivery focused on a vision that is refined
during development (e.g. SCRUM) is more appropriate as an approach that will
reduce the uncertainty and deliver the best possible outcome. Where there
is certainty but no agreement, prototyping and a good dose of organizational
politics is probably the right answer.
So yes, in my view Scrum is a methodology and an excellent one in the right
Also, if anyone else has been looking at the application of complexity
theory to application development or project management I would be
interested in hearing from them.
From: Ken Schwaber [mailto:kschwaber@...
Sent: Saturday, November 25, 2000 11:07 AM
Subject: [scrumdevelopment] A Tool or a Methodology
I've been invited to a session on "light methodologies"
or "minimalMethodologies". This caused me to rethink about whether
Scrum is a methodology.
My experience with Summit, Method/One, SDM, UML, and other
methodologies are that they are cookbooks. You follow the cookbook
and you are following good engineering practices, and you will, as a
matter or course, get a good product.
One argument about methodologies is their degree of specificity. For
instance, a methodology is usually tool neutral. A methodology also
usually presumes the presence of a development and computing
My experience is that the influx of new technologies and techniques
makes most methodologies irrelevant. Since they are so neutral,they
contain nothing of relevance. The new stuff that causes products to
be competitive is still experiential, or - at most - published.
I am in the middle of using Scrum at an ASP ... a recently reapplied
concept (like time-sharing) where the product vendor not only
provides the application but the whole computing infrastructure.
There were so many unknowns that Scrum worked great ... but not as a
methodology, but as a tool with which to organize, prioritize, and
get work done.
The ASP is a startup company, which only had sales and product
development doing everything. But when the orders started pouring
in, they needed quality control, customer support, systems
engineering, and implementation services. Based on what we were
discovering, the backlog changed almost every week.
For instance, to test a product, you need a stable build. To have a
stable build, you have to have a coordinated code checkin/checkout
and unit testing process. For the unit testing to make sense, the
teams had to have a high degree of coherence, with low coupling to
other teams. This got sorted out, day by day, in daily Scrums. In
the daily Scrums, we identified the new work, set up Scrums to handle
the new requirement ("oh!! We need a customer support function,
otherwise we'll never get to the work on this release because we're
too busy working with customers on enhancements!!"). This chaos,
driven by marketing and venture capital dates, was continually
organized and reorganized by Scrum.
So, we used Scrum as a tool to get work done. Does that make it a
minimalMethodology? Or are we into something different here?
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: