[Sigia-l] How the design process fits into the agile methodology

[Jacqui Olkin]

Adrian wrote:
>
>A common myth that seems to have emerged about agile methods is that
>there are is only one "level" of step in agile methods, or that
>people only look one step into the future. This is not the case.

Adrian,

Thank you for addressing some of the misconceptions about agile that are 
being batted around on this list--including that there is only one way of 
applying it (you rightly refer to "agile methods"), and that it addresses 
only development, not strategy.

If anyone wants more information on agile, here's a resource: 
http://www.agilealliance.org/

Jacqui

Jacqui Olkin
Olkin Communications Consulting
jacqui at olkincommunications.com
571-643-6020 ph.
703-834-5653 fax
www.olkincommunications.com

web . print . content . strategy



>From: Adrian Howard <adrianh at quietstars.com>
>To: sigia l <sigia-l at mail.asis.org>
>Subject: Re: [Sigia-l] How the design process fits into the agile 
>methodology
>Date: Sun, 18 Feb 2007 22:34:09 +0000
>
>On 18 Feb 2007, at 09:20, Ziya Oz wrote:
>
> > Livia Labate:
> >
> >> the agile nature of the development really only speaks to the
> >> development
> >> cycle
> >
> > I wonder if there's general agreement on that. (I myself don't have a
> > position.) If the development cycle has, say, 30 steps, it's
> > relatively easy
> > to conjecture how steps 3-30 may evolve through iteration. But who
> > determines what the *first* 2-3 steps will be?
>
>A common myth that seems to have emerged about agile methods is that
>there are is only one "level" of step in agile methods, or that
>people only look one step into the future. This is not the case.
>
>For example if you look at XP you have typically have feedback loops
>operating at the level of:
>
>* hours (test-driven design)
>* days (daily stand up meetings)
>* weeks (iterations)
>* months (release plans)
>* quarters (quarterly cycle)
>
>Obviously the short-loops are more implementation focussed while the
>long-loops are more strategic. The key difference with agile methods
>is that they attempt to do the absolute minimum amount of up-front
>work to make progress, and rely on feedback much more than prediction.
>
>It turns out that, at the lower levels of hours/days/weeks, the
>minimum amount of up-front work is a _lot_ smaller than many folk,
>myself included, originally thought. Getting there has involved
>inventing a few new methods, and pushing some existing ones in some
>new directions. A whole bunch of the IA/UX/IxD/whatever world's work
>lives quite happily at these levels.
>
>Figuring out how to do the minimum possible amount at the higher
>levels is, as far as I am concerned anyway, still very much a work in
>progress. Obviously a whole bunch of the IA/UX/IxD/whatever world
>lives at the higher levels too.
>
>Cheers,
>
>Adrian

_________________________________________________________________
Find what you need at prices you’ll love. Compare products and save at MSN® 
Shopping. 
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701