Where's the reality? was, Re: [Sigia-l] Off Topic Posts

Mark Canlas mark at htmlism.com
Sat Mar 11 04:13:31 EST 2006


Openly taking the role of fanboy/advocate... I'd say the "arguing"
over deliverables would become more of a dialog. The whole
methodology/philosophy is a move away from clearly
delineated/hands-off/pre-decided deliverables to a more organic,
constant flow of interaction. There are a lot of changes, i.e. making
tasks more granular and immediately subject to change. The concept of
change is expected and welcome, as opposed to something fended off by
a spec shield.

I'd say with the evolution of communication technology (speed,
accessibility), this is a style more in-line with Internet speed/time.
But that's just me. I have drinked/drank/drunkard the 37signals
Koolaid and I lover it.

-Mark

On 3/11/06, Leisa Reichelt <leisa.reichelt at gmail.com> wrote:
> > 37 Signals are advocates. Advocates move the needle and raise the bar,
> > necessarily breaking best practices along the way. So how their reality maps
> > to the fat part of the "ordinary-reality" Bell curve begs the question as to
> > whether they are a fad or a harbinger of things to come.
> >
> > I'm curious why you think it wouldn't work with consultants.
>
> i guess it depends on the nature of the consultant relationship.
> Basically I'm concerned that the very short and non-specific 'scoping'
> phase advocated by the Getting Real methodology is potentially
> troublesome in a project where you and your 'client' have to agree on
> what the project is and the points at which you can agree that the
> work has been completed.
>
> Given that functional specifications are a no-no in Getting Real and
> 'wireframes' are essentially rough sketches on paper that are coded
> ASAP, then move into an iterative release cycle, based on my
> experience I'd say that there would be a lot of arguing over whether
> or not a 'deliverable' had absolutely been achieved (meaning that your
> client then owes you money).
>
> In the 37 Signals environment, this simply isn't an issue they need to
> deal with, so its relatively easy for them to ditch documentation like
> signed off wireframes and functional specifications. Where there's
> ongoing client expectation management required - documentation can be
> very helpful!
>
> Would be interested to hear others thoughts on this :)
>
> ~~~~~~~~~~~~~~~~~~~~~~~
> Leisa Reichelt
> leisa.reichelt at gmail.com
> www.disambiguity.com
>
> ------------
> When replying, please *trim your post* as much as possible.
> *Plain text, please; NO Attachments
>
> Searchable Archive at http://www.info-arch.org/lists/sigia-l/
>
> IA 06 Summit.  Mark your calendar.  March 23-27, Vancouver, BC.  http://www.iasummit.org/
>
>
> ________________________________________
> Sigia-l mailing list -- post to: Sigia-l at asis.org
> Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
>




More information about the Sigia-l mailing list