"True" Rules of Agile Software Development (was Re: Organizational Patterns of Agile Software Development)
- On Wed, Oct 27, 2004 at 06:24:37PM -0500, Mike Beedle wrote:
> > Remember, the practices I characterized at:Thanks! Much appreciated.
> > http://www.cmcrossroads.com/article/34375
> Ok, I read the article.
> I think you need better names for the "minimal list".Could be. I liked the "minimal marketable feature" from
the _Software_ _by_ _Numbers_ book and quite possibly got
carried away with the use of the word "minimal" and with
alliteration for whatever came afterward.
> On the other hand, I like the idea to categorize them inMe too. That was the thing I was initially going after. To
> terms of minimums', balances', or maximums'.
indicate what the binding/competing forces are that need
to be balanced when trying to come up with the smallest,
shortest, fastest whatever-it-is.
> However, the article doesn't say anything about time asI like the idea. The name then becomes too wordy to be
> you indicated above -- the "minimizing time" makes sense
> but the article says "release content is minimized...".
> So perhaps a better name is:
> Minimize the Time but Maximize the Content between Releases
> That leaves much less to be interpreted as to what should be "minimal".
the name of a practice (albeit a generic one common to
[almost] all agile methods).
Let's see what we can come up with together!
At first I was thinking I might need to say "Minimal _yet_
Deployable Releases" to clarify that the "minimal" refers
to the release rather than the deployability. Maybe that
wasn't a bad idea and I should have done it.
I think I don't entirely agree with "maximize the content".
I think it is the business value we want to maximize,
while minimizing the amount of time/effort to deliver it.
We want to deliver the greatest amount of value in the
shortest possible time.
My concern with content size measured in #features is that
I can simply repartition my features into smaller chunks and
claimed to have double or quadrupled (or more) the "content"
when in fact the content and perceived business value hasn't
I also think the biggest factor/struggle in making releases
shorter is getting the customer to accept them and to
install/deploy/upgrade them more frequently.
of features) that we want to maximize.
> "Iterations are kept short in order to minimize theAnd also the granularity of what should be customer-visible in
> opportunity for changes to their scope, and rapidly
> enable customer-feedback on tangible working results in
> the shortest time-span"
> But very short iterations are also a problem -- for
> once the time of the Product Owner, the Customer (or
> its equivalent) is not as accessible.
> People that ask for shorter iterations seem to ignore these facts:
> Availability and schedules of Customers, Executives and/or other
what gets reported/tracked/statused to the customer. Partitioning
things into smaller sub-things makes more stuff that has to be
tracked/reported/status-accounted. And if we choose to subdivide
(for our own purposes) at a finer-granularity than what we report
to the customer, we have the classic decomposition+traceability
burden of having to roll-up the data from multiple fine-grained
things into a single customer-reported thing.
Hence I tried to use the word "manageable" to convey those
things. It appears that you don't object so much to the word
"manageable" but rather to the fact that nothing in the
description gives any hint of keeping things manageable.
> We don't draw.... seriously. We just code.And before there is any code written and you try to convey
> And we talk about "technical things" all the time.
> Our face-to-face communication is in front of
> computer monitors that display the code -- no
> need to draw the code.
information about design abstractions and domain entities,
you don't do any drawing on whiteboards that are in the
same room as the computer monitors?
I know you are also "big" on using patterns and frequently
talk in terms of the entities within a pattern or the
interaction between patterns and have seen you and others
make quick drawings in the process of communicating without
any seeming interruption in flow.
> So each of the features is minimal not the bag ofYes. or even "Marketable Minimal Features"
> "Marketable Features" as in:
> Minimal "Marketable Features"
> So perhaps a better name is:Certainly is more descriptive. A tad on the long side
> Minimal (or the Smallest Possible) Features that
> are still Deployable and Marketable
tho. At some point there is a balancing act one must also
do with the names of things to find the right mix of
brevity and accuracy.
In this particular case, the MMF term came not from me
but from the book "Software by Numbers" which introduced
the "Incremental Funding Method" (IFM).
See a review of the book from Tom Poppendieck, and also
Alistair's comments on it, at the following URL:
> Ok, now that I get the meaning, I have the same question as below:I think the above mixes the granularity of features,
> Wouldn't you like to code the largest possible feature
> that won't break the build?
> Wouldn't you like to code the largest possible feature
> that is still testable and deployable in a short time?
with that of change-tasks and of modifications. I think
that the granularity of a feature >= the granularity of a
change-task, which is >= the granularity of a modification:
* For me, a modification is the activity feedback-loop
that starts when I edit a file to make changes for a
particular purpose or express a particular thought in
code, and ends when I run tests to verify my changes
* I define a change-task to be the activity feedback-loop
that starts when I first populate my sandbox with the
latest working version of the code and begin to check
out files, and ends with my checking-in (committing)
my changes to the codeline that the rest of the team
used as the basis for making changes.
* In between those two is another integration-feedback-loop
where I might update my sandbox with the latest changes
from the codeline, but my own changes are not yet ready
to commit to the codeline because they may not work yet.
So using those definitions, hopefully it becomes clear
that a change-tasks would encompass many modifications,
and a feature may encompass many change tasks. Thus:
* I want my tasks to be nice and small and have very
little possibility of becoming "stale" with the codeline
from when I first did my "checkout". I want to minimize
the likelihood of checkout contention/collisions and
* I want the amount of time in between when I write code
and when I test code to be as small as possible. If I'm
editing a file to modify a particular method, I want to
make the smallest possible set of modifications that I
can possibly verify before making the next modification
to the same file or a different file.
I think Agility (and TDD in particular) pressure/motivate
me to intersperse my testing with my coding to the extent
that they are so frequent as to be inseparable activities
and are instead part of the same activity.
I sometimes have a lot of difficult keeping that rigorous
discipline. Sometimes I'm trying to express a particular
thought I'm having in the code, and I don't want to stop to
test what I've done until I finish expressing my thought.
> I hope the comments are useful -- you(we) are onto somethingThey are very useful - I appreciate the substantial time
> *very big*, that's why I am taking the time to respond:
and effort you've taken to read the article and make the
> you(we) are onto something *very big* [...]That's a bit more ambitious than I was thinking of, but we
> The *true* rules of Agile Software Development
> These are the "simple rules" that, through simple interactions,
> give rise to the emergence of "Agile Teams" and their
we can certainly give it a shot :-)
Speaking of which, Alistair's Crystal Clear book wasn't out
yet when I wrote my article, but it is new, and he has some
GREAT things in there (like "Osmotic Communication" which
is one of my favorites :-)
Brad Appleton <brad@...> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost