Loading ...
Sorry, an error occurred while loading the content.

"True" Rules of Agile Software Development (was Re: Organizational Patterns of Agile Software Development)

Expand Messages
  • Brad Appleton
    ... Thanks! Much appreciated. ... Could be. I liked the minimal marketable feature from the _Software_ _by_ _Numbers_ book and quite possibly got carried
    Message 1 of 1 , Oct 28 9:27 AM
      On Wed, Oct 27, 2004 at 06:24:37PM -0500, Mike Beedle wrote:
      > > Remember, the practices I characterized at:
      > > http://www.cmcrossroads.com/article/34375
      > Brad:
      > Ok, I read the article.

      Thanks! Much appreciated.

      > 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 in
      > terms of minimums', balances', or maximums'.

      Me too. That was the thing I was initially going after. To
      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 as
      > 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".

      I like the idea. The name then becomes too wordy to be
      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 the
      > 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
      > resources.

      And also the granularity of what should be customer-visible in
      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 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.

      And before there is any code written and you try to convey
      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 of
      > "Marketable Features" as in:
      > Minimal "Marketable Features"

      Yes. or even "Marketable Minimal Features"

      > So perhaps a better name is:
      > Minimal (or the Smallest Possible) Features that
      > are still Deployable and Marketable

      Certainly is more descriptive. A tad on the long side
      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:
      > 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?

      I think the above mixes the granularity of features,
      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
      are correct.

      * 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
      merge conflicts.

      * 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 something
      > *very big*, that's why I am taking the time to respond:

      They are very useful - I appreciate the substantial time
      and effort you've taken to read the article and make the

      > you(we) are onto something *very big* [...]
      > 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
      > hyperproductivity,

      That's a bit more ambitious than I was thinking of, but we
      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
    Your message has been successfully submitted and would be delivered to recipients shortly.