Agile and architecture

Tom Breur

20 July 2014

Recently me and my team were faced with a series of, say, “unfortunate” technology choices. None of us are particularly happy with the platforms that have been imposed on us. We don’t own it, and we don’t like it. But it’s “the corporate standard”, and allowing us to choose ourselves might well have led to a further proliferation of technologies, and further rise in maintenance costs.

There seems to be widespread concern that Agile methodologies might entice quick and dirty solutions. I debunked that myth in an earlier post. But because Agile promotes shared responsibility, the question arises how you can leave concern for architecture to an anonymous group like an Agile team?

The Agile Manifesto reads:

“The best architectures, requirements, and designs emerge from self-organizing teams”

It seems mostly the self-organization that scares management and enterprise architects. They wonder how something like “architecture” can emerge?!? Traditionally, we were taught to build architecture in, by designing it upfront. Typically, some “master designer” (“Architect”) would take ownership of this.

An Agile team may still have a team member with an architect like profile, but the whole team participates and tries to understand the pros and cons of design decisions that materially impact the architecture. By publicly posting important principles

Every team member needs to understand why a particular architecture was chosen (and what assumptions were made…), in order to contribute to discussions about alternatives. What are the pros and cons of one solution over another? The more team members know about these considerations, the more they will be able to contribute to the discussion. Which ultimately leads to the best possible solution. This is what Japanese refer to as Nemawashi.

Dissent among team members that may seem to slow down decision-making, but it serves several important goals (e.g.):

1 – it improves mutual understanding of perspectives and needs (provided these discussions are moderated well)

2 – it hardens the solution, because all possible viewpoints have been taken into consideration

3 – everybody will be on the same page, there will be little need to brief people about guidelines, etc.

4 – because a shared understanding led to the chosen solution, the team as a whole is strengthened

Now all team members fully understand the implications and consequences of this particular choice (among several proposed alternatives). They have “lived though” their mutual viewpoints and assumptions. This deep understanding will serve them well as the solution evolves and matures, and when new evidence comes in that may refute earlier assumptions.

When the rubber meets the road, you discover how well (or poor…) your options have panned out. As a team you can now shoulder the consequences of your joint choice. The best architectures are not invented in ivory towers. They are owned by teams that rally behind their choice, and feel free and safe to reconsider their options at any time.

Knowledge work is teamwork. The best teams are shaped by processes that enable them to truly “own” their work. Does your architecture do that for you?