RE: [scrumdevelopment] RE: [XP] Re: Agile Rentschian Thinking
Thanks for the summary of RUP. A good summary certainly
clarifies the tons of documentation written on it that
sometimes miss the point of expressing its essence.
These are a few statements that summarize my position so far
from our sometimes heated but respectful and insightful conversation
over the last couple of days:
1) Agility always involves "embracing change" and therefore
requires some level of self-organization
2) Agile methods are based on agile practices, are simpler
to implement, and have fewer options to be "configured"
3) There is agility in RUP, (at least in the way you
describe it below), but it varies with how RUP is configured
4) There is a definite difference between Agile Methods,
which include RUP in different degrees depending on how
it is configured (specially as you describe it below); and
striclty Defined-Process methods ("defined process" in
the sense of purely sequential step-wise activities).
These are still things that I question:
1) What are the limits of flavoring that RUP can be
configured into? i.e. RUP-XP, RUP-CMM5, RUP-ISO9K,
2) How much effort does it take and how much overhead
does it take to configure each of these flavors?
And does this come in the way of agility itself?
Grady Booch wrote:
> Mike Beedle wrote:Ok, I'm about to tell you everything you need to know about the RUP...all
> > [egb> ] thank you for the advice. are you open to using this
> > conversation as a crash course in rup concepts, principles,
> > values, and beliefs?
else is simply details.
First, the essence of the RUP may be expressed in its six best practices.
These are not an invention, but instead are a reflection of what we've seen
in working with literally tens of thousands of projects over the past 20
years, codifying what works in successful organizations and what is
noticeably absent in unsuccessful ones:
1. Develop iteratively (every project has a regular rhythm, manifest as a
series of contiuous, regular releases of executables)
2. Model visually (we model so that we may better reason about the systems
we are trying to build; the UML exists as the standard means of visualizing,
specifying, constructing, and documenting these artifacts of a
3. Manage requirements (everything is driven by use cases/stories which are
continuously discovered, refined, and managed in the rhythm of the project,
and so in turn drive unit and systems test as well as the system's
architecture and therefore implementation)
4. Control changes (change is good insofar as it is directed by aggressively
attacking the risks to success in the system)
5. Continuously verify quality (test continuously, using the use
cases/stories as the baseline, and use these tests to measure progress and
identify risks along the way)
Use component-based architectures (one grows a system's architecture through
each iteration; we validate and verify the system's essential architecture
early on so as to aggressively attack all technical risks and to raise the
level of abstraction for the rest of the team by explicitly making manifest
the design patterns/mechanisms and architectural patterns that pervade the
Second, there are a few implicit practices:
1. Develop only what is necessary
2. Focus on valuable results, not on how the results are achieved
3. Minimize the production of paperwork
4. Be flexible
5. Learn from your mistakes
6. Revisit your risks regularly
7. Establish objective, measurable criteria for your progress
8. Automate what is human-intensive, tedious, and error-prone
9. Use small, empowered teams
10. Have a plan
Third, there's some terminology worth noting, so that we level set the
vocabulary of the process to all stakeholders:
1. The conduct of a project tends to follow four major phases, the end of
each which represents an important business gate: inception (when the
business case for the project is established and the basic boundaries of
what's in and what's out of that case are drawn; at the end of inception we
can say "yes, we should do this"), elaboration (gated by the establishment
of the system's essential use cases and architecture, representing a direct
attack that confronts the essential technical risks to the system; at the
end of elaboration we can say "yes, we know we can do this"), construction
(wherein the system is grown through the successive refinement of the
system's architecture, along with the continuous discovery of the system's
desired behavior; at the end of construction we can say "yes, the system is
in a place where it may be fully deployed to its users" [it may have been
incrementally deployed during construction, of course]), and finally,
transition (wherein the business decision is made that aggressive investment
in the system is no longer necessary, and the system enters a plateau of use
and maintenance; at the end of transition we can say "this system is at end
2. Since the RUP is about deploying systems for which software is an
essential element (acknowledging that executables are the essential artifact
that's produced continuously but that this labor has a business, economic,
and technological context whose stakeholders contribute), there are several
disciplines that engage in the development activity: business modeling,
requirements, analysis and design, implementation, test, deployment,
configuration and change management, project management, and environment.
These disciplines represent different stakeholders, different views into the
system, and different skill sets. Each discipline has its own rhythm, but
all in harmony with the essential construction rhythm of the project as a
3. In the conduct of a project, the RUP provides a common vocabulary for
those things that get created during a project (artifacts), the roles/skill
sets who create those things (workers) and the concurrent, interweaving
workflows that those workers typically follow to manipulate those artifacts
That's all you really need to know...
> As such, any meaningful method has to "embrace change" but perhapsControlled by whom ? Aye, there's the rub.
> where we differ is that I would add "and do so in a controlled manner."
> if you are building a high rise, it would be infinitely stupid to startAgreed. Here and now, given our skill and knowledge, it would be
> with a pile of lumber and some hand tools and expect to be successful.
stupid. Do remember, though, that fairly simple biological organisms
routinely build, with their bare appendages, constructions which are
to them as a highrise is to us. Termites. Wasps.
Conclusion : it is not stupid to expect that we might *develop* the
knowledge and skill to build a highrise starting with a pile of
lumber and some hand tools.
Now. Metaphor is nice, but we are not, in fact, building highrises.
We are building software, a different kind of thing. What transposes
there from the metaphor, and what doesn't ?
> To be clear as well, I have problems with the pseudoscientific soundI don't see where you get that. Could be a language problem - as a
> bites in your statement: "embracing change" strikes me too much like
> the pop business edits of the 80's and 90's. I mean, what's the
> alternative? "I'm a Luddite."
freakin' furriner I always double-check this kind of thing.
Dictionary.com says : "embrace, to take up willingly or eagerly", or
more interestingly, "to avail oneself of". Thus the alternatives are:
"to accept change reluctantly", or even "not to avail oneself of the
possibilities offered by change". Which is where you're leading with
your "embrace change in a controlled manner".
Dictionary.com says Luddite is "One who opposes technical or
technological change". I think one could legitimately oppose some
kinds of technical change - human cloning is routinely opposed by
some people who, perhaps, might object to being labeled Luddites.
I definitely don't think "embrace change" is vacuous. On the
contrary, reading some Roberto Unger, who in the domain of social
science says the same thing under the slogan "Plasticity into Power",
I found more content in the position than I would have expected from
a principle of software development.
The greatest obstacle to transforming the world is that we lack the
clarity and imagination to conceive that it could be different.
Roberto Mangabeira Unger