Architecting while Agile? Yes, you can.

f you’d been in one of my trainings a while ago, you’d have heard someone ask me this question. “You Agile evangelists are always talking about these new roles: Product Owner. Development Team. Release Train Engineer. This, that and the other. Fine and good — but where does my work fit in? I’m an architect. And I can see my role is changing, but I’m not sure how exactly. Why is it changing, and more importantly what can I change to stay onboard?”

Memory lane

The question triggered a flood of competing thoughts. Mainly it brought me to go back several years in memory, to review some talks I listened to, books that I’ve read, conferences I attended. Because this person had a very interesting point. And I realized: we don’t talk that much about architecture in the Agile discourse, do we?

Architecture overlooked

With the relentless focus on customer-valuable increments that Agile preaches, most of the time we are discussing new releasable functionalities, their UX, their built-in quality controls and other end-game variables. What about the architecture to support all of this though? What about the roles that lay the groundwork that enables customer value to flow through the systems?

I came back from the short mental detour and calmly wrote the gentleman’s remark down on a sticky post: “I need to park your question for now. By the end of our two-day of training, if I haven’t answered it yet, it will be first on the list.”

Structure vs agency

The core of his dilemma is this.

Ideally, Agile Development Teams — while doing their autonomous work in splendid isolation from everyone else, each one developing its own elegant piece of the product range — are supposed to have the mandate to decide how and what to improve on the architecture. As features develop by order of highest demand, so each team should grow the architecture needed to support them. This is…