ALT.NET: Architecture on an Agile Project

I’m clipping this for myself.  😉

It’s a post from Udi on Agile Architecture.

Here are my thoughts:

– What’s hard about doing design in an Agile project?

Battling with YAGNI people. The amount of up front design acceptable
to people depends on their experience. Some want to stop after
setting up 3 layers. Others are willing to continue up to MVP.

I think it’s
easier than Waterfall, but I want to hear from people with a
background in Waterfall or RUP like processes.

I’ve done enough Waterfall and RUP to tell you that those camps tend
to do theoretical architecture and design – pictures and
powerpoints, but rarely actually try out their concepts in code.

– How much of the architecture do you know upfront?

A better question would be how much can you figure out with
reasonable certainty. That again depends on experience, not only in
pure architectural work but in the specific domain. Understanding in
which dimensions these kinds of systems tend to change, and so on.
It’s been my experience that you can get quite a bit done.

How are you
under control and have any chance of successful delivery if you
don’t know every detail of the design upfront?

Screw control. It’s more productive – even if you don’t have all the
details. Good architecture separates concerns enabling you to get
started where you do know more of the details, giving you more time
to figure out details in other areas as you go along. That’s agile
in my book.

How do you make big Architectural decisions without blowing the
iteration plan?

Decisions usually take 1 second – yes or no, and move on. Finding
out what to decide on can take longer. Again, good architecture
enables you to decide on bits and pieces at a time.

Do you just do time boxed spikes?

Also that.

How much architecture work do you do upfront these days?

As much as I get paid to do 🙂

Do you still have a dedicated Architect, or is architecture shared
throught the team or at least shared by the senior folks?

The size of projects I usually work on usually have a dedicated
architect. If members of the team are knowledgable, they are
involved. Regardless, you need buy in by the team doing the work –
nothing works better than pair programming with them for that.

What about technical infrastructure that takes longer than one
iteration to build? Is there really any such thing?

If it’s behind an interface, who cares? Handle its features just
like anything else.

How do you avoid code churn? Do you?
Is it really that big of a deal?

If I had to choose between productivity (in features units / time)
and not rewriting code, I’d choose productivity. Keep your eye on
the ball – that’s my plan.

Hopefully my necessarily colored opinions are worth something 🙂