FYI - for those who are interested, the article just appeared
online at:
<http://www.cmcrossroads.com/article/34375>
Portions of this were discussed at one time or another
over the past couple month on each of these lists. The
article includes pictures of the nested feedback-loops,
and the waterfall vs "agile itertaive" lifecycle described
below and also the brief descriptions of my attempt to
characterize practices seem to transcend any 1 or 2 agile
methods:
* Minimal Deployable Releases
* Minimal Manageable Iterations
* Minimal Meaningful Models
* Minimal Marketable Features
* Minimal Malleable Designs
* Minimal Mergeable Change-Tasks
* Minimal Testable Modifications
* Minimal Perpetual Peer-Review
Cheers!
--
Brad Appleton <[EMAIL PROTECTED]> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---- On Wed, Oct 20, 2004 at 04:43:33PM -0500, Brad Appleton wrote: ----
On Tue, Oct 19, 2004 at 09:54:22AM -0500, Scott W. Ambler wrote:
>
> I'm currently working on a column which describes what I think it means to
> be agile. I'm going to focus on ideas like:
> !. Cooperation and communication within the team
> 2. Integrating stakeholders into the team.
> 3. Being test infected.
> 4. Being quality infected.
> 5. Delivering working software which meets the highest priority needs of
> its stakeholders in a timely and cost efficient manner
>
> I guess the question is what is agility as far as you're concerned?
Interesting timing ... since I just wrote a paper this
week that revisited that same question for something I
wrote about two years earlier. Back then I really liked
the basic definitions from Highsmith's ASDE book (ch 2):
Agility is the ability to both create and respond
to change in order to profit in a turbulent business
environment....
What is new about agile methods is not the practices
they use, but their recognition of people as the primary
drivers of project success, coupled with an intense
focus on effectiveness and maneuverability
Then I summarized something from a paper Highsmith and
Cockburn wrote together, and paraphrased as follows:
Responding quickly and effectively to change is easiest
to do when we can minimize the following:
* the cost of high fidelity knowledge-transfer between
individuals
* the amount of knowledge that must be captured in
intermediate artifacts
* the duration of time between making a project decision,
and exploring its results to learn the consequences of
implementing that decision (feedback->learning latency period)
So achieving agility hinges upon reducing the time and
cost of effective communication, feedback and learning
(and, ultimately, the creation, transfer, and
codification of executable knowledge)
Then I got a bit clever (too clever perhaps) and came up with
an acrostic for what I deemed the "characteristics of an
agile project" (Note what it spells out :-)
Projects employing the methods founded upon these "agile"
principles and values [from the agile manifesto] share
the following key characteristics:
Adaptive -- plans, designs, and processes are regularly
tuned and adjusted to adapt to changing needs and
requirements (as opposed to being predictive)
Goal-driven -- focus on producing end-results (tangible
working functionality) in order of highest business
value/priority ("Agile approaches plan features, not
tasks, as their first priority because features are
what customers understand." [Highsmith].
Iterative -- short development cycles, frequent releases,
regular feedback
Lean -- simple design, streamlined processes, elimination
of redundant information, and barely sufficient
documentation and methodology
Emergent behavior -- quality requirements/architecture/design
emerges from highly collaborative, self-organizing teams
in close interaction with stakeholders
The "G" above is kind of lame - it really should have been "Feature"
or "Value" or "Business value" instead of "Goal" -- but I needed
the "G" to spell "AGILE" and couldn't come up with anything better
(I told you I tried to be "too clever" :-)
Just this past week, I revisited all of this for a paper I wrote
on how agile methods impact traditional SCM process/practice, and
I jotted down a few more things.
* Premise (or 'belief' in the possibility) of the flattened
cost-of-change curve [not entirely sure about this one]
* The "Lean" notion of features as inventory (and hence
depreciable in value the longer their lead-time to market)
* The Agile-lifecycle (versus the waterfall lifecyle)
I suggested that the waterfall is "breadth-first",
"phase-based" with "end-of-phase handoffs" whereas
the agile "iterative" lifecycle is "depth-first",
"[feature-]set-based", and with full-lifecycle
collaboration
* I referred to Nonaka and Takeuchi's "The Knowledge-Creating
Company" (the book that inspired Scrum) and how:
- breadth-first waterfall somewhat resembles a relay race
where each phase-specific role passes the baton
(in the form of intermediate artifacts) to the next role
in the assembly-lane (right after clearing the end-of-phase
review "hurdle").
- depth-first iterative more closely resembles a rugby match
where all roles collaborate closely throughout the event,
and must dynamically regroup, reflect, and adjust/adapt
regroup after each short-term win/failure
- They then propose that it is possible to combine the
best-of-both approaches, and liken the result to "American
football" (and I suggested that FDD and DSDM might be the
"american football" of the agile methods :-).
See <http://www.xp123.com/xplor/xp0402/index.shtml> and
<http://www.meansbusiness.com/Knowledge-and-Learning-Books/The-Knowledge-Creating-Company.htm>
* I likened the effects of "Hyper-frequent iterations" to that
of Special Relativity. Here, I suggested that even tho
iterative/spiral models predated agile, that the emphasis
on very short iterations was nowhere near as strong as it is
for agile-methods. And that agile methods reduced the typical
iteration length from months or weeks, to 1month->1week
(and similarly tasks "compressed" from a typical 1-2 week or
several days to instead be a few-days to a few-hours).
In the spirit of Special-relativity's "time-dilation" I
referred to this as "phase-compression" (due to short
timeboxing) and "phase-boundary dilation" (due to
close collaboration). I wrote:
At this short time-span, the boundaries between phases
become increasingly blurred as greater cross-phase
collaboration is emphasized. It becomes less
statistically significant to look at the individual
phases within an iteration than it does to look at the
iteration itself as a whole. Such phase compression
is reminiscent of the time-dilation effect of special
relativity in the sense that:
- The phase-based frame of reference for the waterfall
view "breaks down" in the collaborative set-based
frame of reference for the highly iterative view.
Each perceives the passing of time (and cost-of-change
due to rework) very differently from one another.
Trying to compare them side-by-side is like trying
to compare "apples and oranges."
- This "changes the rules" for how to compute/measure
and communicate/report our results (be they the rules
of "Newtonian mechanics" for summing velocities,
or the rules of "Phase-containment" and the
cost-of-change curve for calculating rework costs).
* Microscopic Incrementalism ... this was meant to refer to
more than just small releases/features/iterations, but also
smaller development tasks, smaller+more frequent increments
of checkin/commit to the codebase, and smaller+more frequent
increments of peer-review (be it pair programming, or an
FDD code-review)
I felt I was trying to get at the basic idea of nested, closed-loop
feedback at all levels of scale. So then I tried to succinctly
summarize what I that was common to most of the agile methods
regarding how they do this. Some are a bit more "extreme" than
others, but I think they all strive to have all of the following
to a large extent:
* Minimal+Deployable Releases
* Minimal+Manageable Iterations
* Minimal+Meaningful Models
* Minimal+Marketable Features
* Minimal+Malleable Designs
* Minimal+Mergeable Change-Tasks
* Minimal+Testable Modifications
* Minimal+Perpetual Peer-Review
I described each of these as follows:
Minimal+Deployable Releases
-- Release content is minimized to balance the impact of
deployment and installation/upgrade against the amount
of business value delivered.
Minimal+Manageable Iterations
-- Iterations are kept short in order to minimize the
opportunity for changes to their scope, and rapidly
enable customer-feedback on tangible working results
in the shortest time-span
Minimal+Meaningful Models
-- Models are made as simple as possible to minimize
intermediate artifacts while conveying the essential
system metaphors, domain abstractions, and their
important relationships.
Minimal+Marketable Features [Denne & Huang, see softwarebynumbers.org]
-- Features are decomposed into the smallest-feasible
units of useful deliverable business value, in order
to fit within short iterations and ensure critical
functionality is implemented first.
Minimal+Malleable Design
-- Code is structured and refactored to be as simple as
possible to minimize over-engineering, redundancy,
and dependencies, while maximizing clarity, modularity,
and encapsulation.
Minimal+Mergeable Change-Tasks
-- Changes are checked-in and committed to the codeline as
(possibly multi-file) transactions representing the
smallest-feasible unit of working/tested functionality
that won't break the build.
Minimal+Testable Modifications
-- Classes/modules and their methods/functions are developed
in the smallest feasible increments of testable functionality,
and then tested prior to coding the next increment.
Minimal+Perpetual Peer-Review
-- Code is reviewed in very-small increments as soon as feasible
after it is written (possibly even as it is being written)
to minimize the cost of error detection and rework, and
enforce coding standards.
I then drew a set of concentric circles (one for each of the above)
to show the different levels of scale of feedback-loops represented
by the above. The outermost circle being the Releases, then Iterations,
then Features, then Change-Tasks, the Modifications, and then Peer-Review
as the innermost circle. Then cutting somewhat across the other circles
in an elliptical fashion (like the "rings of Saturn" :-) I had Models,
and then inside that was Design.
--
Brad Appleton <[EMAIL PROTECTED]> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
