RE: [XP] Re: Agile Rentschian Thinking
- View SourceGrady Booch wrote:
> [egb> ] This reality of the breadth of software is what tempers abetter
> lot of my comments about process in this forum. Fundamentally, building
> software faster is hard. No one size fits all - there are just sobasic of
> many kinds of domains and development cultures out there. My goodness, we
> as an industry can't even agree upon a common vocabulary for the most
> things like "requirement" or "architecture" or "component" (take a look atlevels of
> what the SWEBOK did and didn't achieve). That being said, I therefore rant
> against any radical claims of revolution in this space from any
> source. The entire history of software engineering is one of raising
> abstraction - but what primarily limits us as an industry from buildingGrady:
> great software is not this technical dimension, but the human one.
(Thanks for your response when I wrote the first "Agile Software Development
Revolution" and "Agile Rentschian articles, this is the kind of discussions
that I had in mind, but serendipity took us to coffee spills, sex, and
"dirty politics". Fun threads, btw. :-)
Here are some comments.
1) No size fits all. I agree that even including the space of
Agile Software Development "no size fits all". Defined-process methods
cope with this problem by adding more processes, more artifacts, more
roles and hierarchy and more tools.
And agile methods follow the same trend, we add more, except we add
more Agile practices instead of more processes, artifacts, etc.. In
Agile methods, we believe _practices_, which are really patterns
in most cases, generate the processes. We see process as a second
Let me give you an example of how different agile practices apply to
different team sizes, in teams of 3-5 or above, Pair Programming applies;
but in projects of hundreds or even thousands of developers or above,
practices like Scrum of Scrums, or like the Shared Resources team that
I describe in XBreed apply. (A multi-project agile method that fuses
Scrum, XP and Reusability, Alexanderian and Open Source ideas, which
main goal is to scale agile methods.)
So there is an agile adjustment for size: we use more generative
2) Building Software faster. There are many core Agile Practices
that deal directly with "developing software faster". For example:
* hiring top talent,
* practicing test driven development,
* constantly getting feedback from the customer,
* minimizing excessive documentation or generating it faster
* avoiding an assembly line process that creates dependencies
on finished products like plans, requirements and architecture.
In general, Agile methods, adjust quality, size, scope and schedule
by making adjustments on agile practices, and accepting that there
are bounds on what can be controlled.
3) Agile Revolution or not?. However, even though there may be
adjustments agile practices there is a fundamental difference in
doing Agile Development. The different is so pervasive that I
think it deserves by its own merits to be granted at least the
possibility of being a true paradigm shift. But only time
will tell. In fact, Kuhn reminds us that the success of a
paradigm shift and a revolution is typically guided by
many factors including strong personalities. (In this case
we beg your endorsement.... )
I believe that this paradigm shift is rooted at its very core in
self-organization, because this is the essence or the difference.
This is the generative quality that leads to many other things like:
1. Management pyramid is inverted
2. Greater Liberty and Freedom to accomplish the task at hand
3. Constant Learning, Knowledge Creation and Knowledge Sharing
4. A More Enjoyable and Humane Work Environment
5. A Hyper-productive Cooperative Work Mode
6. Emergent Planning, Architecture and Requirements
7. New values that generate a cooperative culture
8. The Quality of Life
More on this at: http://c2.com/cgi-bin/wiki?AgileRevolution
Grady Booch wrote:
> [egb> ] I find it telling to note that, if you look at some ofConstantine,
> the hard core methodologists from the previous and contemporary
> generations of analysis and design methods - Ed Yourdon, Larry
> Tom DeMarco, Kent, myself, and others - virtually all of that groupHere I agree completely. In fact the Agile Manifesto is very clearly
> have morphed to confronting the human issue of development. That's not
> to say that tools and methods are irrelevant - they can amplify human
> ability, eliminate errors, help us better reason about complex things -
> rather, it's the social dynamics among individuals, within small teams,
> and among teams of teams that are deeply critical in pushing out
> great software.
in saying that:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The operative memes being "we have come to value" and "over",
- View Source
> 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