Agile Architecture-Introduction

Attending daily stand ups, sprint planning and retrospectives with your team would not make you Agile. There is equally no Scrum or Kanban board in this world that would by itself make you and your team suddenly start doing the full cycles of your work in short iterations.

Agile does normally require these things. There is however a lot more to it: the mindset, the ways of working — both within the team and with other teams, and with your customers — and even the team composition. It is not an objective of this blog, to explain what those are and how they work. For years there have been more than enough materials out there on this topic and you may already have read some of them, and even if not, you would probably have experimented them in practice. This blog is about a largely unanswered and critical question within that larger theme: if you are an architect in a team that is Agile, how do you do your job in a way that is not in conflict but in synergy to how your team thinks and works?

To answer that question, I draw on my experience of a decade in solution architecture roles in large organisations, both as “individual contributor” as well as leader of architecture teams. A large enterprise context would not apply to all readers here but if you are interested in that same question, I believe that my experiences and reflections should still be largely transferable to your role in other types of organisations.

I do not really have one answer to that question. What I do have is many lessons and reflections to share. My intention is to share those over multiple posts. Look at the titles and pick the ones that spark your interest. Feel free to ignore those which do not. Continuity and the order should not matter.