Re: [agile-usability] Re:are you making efficient designs?

... Heh. Sorry about that, Robert. That s how it feels to a lot of people who have tried it both ways, but it sounds like they could be more polite about it.

Message 1 of 341
, Jan 25, 2007

0 Attachment

Robert Davis wrote:

> This is a related comment/question from a non-tech perspective -- my
> UEX firm is partnering with a big agile development firm on a
> consumer-facing web project -- and we're adapting our "waterfall"
> (everyone loves to cringe when they say that, like we have been lepers
> and will be cured now) web development method to agile, and vice-versa.

Heh. Sorry about that, Robert. That's how it feels to a lot of people
who have tried it both ways, but it sounds like they could be more
polite about it.

Just the other day a developer friend stopped by from a waterfall-ish
company and described his woes, all the conflicts he's having with the
suits over scope and schedule. But he happened to be doing it in the
middle of our team room, where the walls are covered with jointly
created, continuously updated product plans. I look over at one of our
"suits" and share a look: we're both thinking, "The poor sap. We know it
doesn't have to be like that." We said nothing out loud, because we
didn't have to.

And to me, that's one of the engines of an agile process: techs and biz
folk thinking the same thing instantly, because we're part of the same
tight collaborative team.

> [...] I think we should work out as inputs "all at once" -- metadata
> architecture for the CMS and some other uses, and the content strategy
> so we can agree on 3 templates for content presentation (lots of
> articles and stuff.)
>
> The dev team is advocating to do metadata and content templates "just
> in time" in the iterations.
>
> It's a major sticking point for us. I'm very interested in the agile
> method and like a lot of the ways it refocuses attention and effort --
> but this seems to me to be a place where there is benefit in working
> some elements out with a system-wide view rather than just in time.

Having done agile development for a number of years, my position these
days is that you should work out immediately anything you feel is
critical and are seriously afraid you won't be able to work out when the
time comes. You don't have to work it out all the way, just until you're
comfortable again.

Note that this is not an objective measure. It's about one's personal
fear. Having been through a number of agile projects, and having had my
evolved architectures stand the test of time, there's very little I fear
these days. Perhaps your dev team feels the same way.

If you have done little agile stuff and have been in the industry a
while, then you've probably had a lot of bad experiences where people
implemented something that turned out to be wrong, but that you were
stuck with because the cost of change was too high. The natural response
to this is to follow the "if only..." path and plan more.

If your dev team is truly agile, then the cost of change will be very
low. Many of your fears, adaptive in the previous environment, now are a
hindrance. But until you've lived that a few times, you won't really
believe it. And given the number of faux-agile teams out there, you
probably shouldn't.

So I'd suggest you go to the team and be honest: tell them you're afraid
that like every other project you've had, the stuff left 'til later will
suffer. Don't make it about them or their ability to deliver; make it
about your fear, and why it is well-earned and has served you well in
the past. Were I you, I'd ask them to show me past projects where they
had happily done what they're telling you they can do for you. And I'd
ask them to walk me through how exactly they would handle the metadata,
until you start to believe they can do it.

Something like that won't take away your fear entirely, but hopefully
they can be plausible enough that you begin to doubt your worries. Then
you can give them the benefit of that doubt, at least long enough to see
how they do in the first few iterations.

And perhaps that's the deal you should make with them, and with
yourself: they should be showing you thinks frequently and regularly
enough that you don't have to make a leap of faith from beginning to
end. Your faith just has to last through the first few iterations, until
you can judge their efforts.

Does that help?

William

Alexander Johannesen

... I just got back from another planet, it seems, so pardon me for asking dumb questions, but what *did* you expect? I myself do a lot of agile UX (note,

> Without any hard feelings intended, the best thing I could do here is to simply
> stop engaging in this conversation. I'm sorry if this bothers you, but this list is
> simply not what I hoped it would be, and I believe I need to explore my
> interests elsewhere.

I just got back from another planet, it seems, so pardon me for asking
dumb questions, but what *did* you expect? I myself do a lot of agile
UX (note, small 'a'; there is no Agile) and I'm on this list, so I'm
curious about your "Great Wall of Agile on this list"; what is it?

Sure, a lot of people have *their* meaning of Agile and their way of
doing things, and as you say, that's ok. Do you feel some people
advocate only one way of Agile, perhaps a tad too much? That their
passion is getting in the way of pragmatism?