Wherefore design [WAS Prioritizing design in successful, legacy applications]
28 Aug 2007 - 9:07am
I'm not a huge agile fan which is why I'll jump in at this point.
But for folks who are interested in learning more about design &
agile, Jeff Patton will be leading a 1/2 day workshop on the the
topic at the IxDA Interaction08 | Savannah conference in Feb 08.
Ok, enough of the plug. Here is why I think this whole issue of
"slow" down is a red herring. The only reason that it is a slow
down is perceptual. For in house teams there is no reason why you
can't have design going off and doing their thing while you are
working on the previous revision. Leap frogging design and
development in this way means that design up front can exist without
slowing down the rest of the development organization. It does mean
having high level engineering leads who are available during the
design process, but most of your development team can work at worp
I find that whenever "agile" comes up it means that an organization
hasn't really put design into their DNA. When I say design, I mean it
in the "design thinking" ways that are as much strategic as they are
tactical. While design "research" is always an option, most seemed
to have agreed on this list that it is a necessity towards making
better and differentiated products.
Further, I would suggest that the role of a designer/developer (not a
replacement of a sole design) but a developer who can convert design
into working prototypes goes a long way towards making development a
heck of a lot more efficient.
Having worked with agile teams in the past, I have not really found a
true value add to agile that competes with the value of design up
front. All the reasons that people purport to use agile methods
seemed to wash away once you hit the GUI level regardless of whether
design was done up front (and in the way) or not. Basically, too many
people are invested in the front-end to let it be done in such a
manner. Iterations invariably have been added on on almost every
agile project using a GUI that I've worked on. Agile seems to work
best with the fewest number of stakeholders that have interest.
To me "speed to market" is not actually turning out to be the great
differentiator people think it is. Getting the wrong product out at
the right time is still the wrong product.
That being said, I think there are different strategic angles to take
that work well for addressing the speed issue.
A rapid release process 3 a year or even quarterly is helpful in many
business cases, so long as what is being released is of true value to
those who have to upgrade. In the enterprise space doing upgrades
often means huge overhead for IT that just isn't worth their time if
what is being upgraded isn't enough of a change. That being said, I
have enjoyed thinking about a process where a vision is outlined by
design (and others) but that vision is iterated upon in cleaner,
meaner, shorter releases. That is the approach we have been taking
with the IxDA project and I have to say it has been working well
(with a few bumps here and there).
For those doing software to be integrated with hardware I find agile
to be quite useless. You got ONE release and that's about it. It's
gotta go out w/ the hardware or it will be a HUGE mess later for
now as in all design advice, it depends and mileage may vary, but I
have yet to see a truly design thinking organization implement an
agile development methodology yet. I'd love to see it. In my
experience agile is done in organizations that are very engineering
centric where the business folks are short sited about the "bottom
line" and don't see the real big picture. It is usually done in
failure and designers who work within it do so b/c they usually have
no choice. I mean, could you really say "No" if you wanted to?
So yes, Design is slow, deliberate and well adds so much more value
than speed ever could. As the saying goes, "Fast, cheap, good --
pick any two." (and I would even question if you could really
succeed with two). Everyone will pick fast & cheap if they could.
I'll throw in another saying from PM school that I love just b/c I
love it. "9 mothers can't make a baby in a month." ... I forget
where I heard that one, but it is Sooooo right on!!! I never go a
year without having an opportunity to use it at work. ;)