Agile is not dangerous for the architecture – if done well

In my 10+ years as an agile coach, I have encountered a lot of different interpretations of the term “agile” in different organisations and in different teams in the same organisation. 

One thing that I often (over)hear is that with agile comes anarchy: “No one cares about architecture in an agile project.” “Everyone just does what they want all the time.” Of course these statements come in different flavours. Some really believe this literally, but there is often an agenda to remove all ideas of agile from the organisation by frightening people.

This agenda comes from fear. There can be fear about what the inspection that lies inherently in agile will reveal (“Will the management notice that I have been stuck in this problem for three months?”). Fear about their own skills in an agile process (“Can I work like that, when I have done waterfall for 20 years?”). Fear that the agile journey will lead to people becoming redundant, e.g. project leaders, and architects.

One way to help people overcome this fear, or help others do the same, is by counterbalancing that fear. You can do that by helping them understand, reducing the fear, and making them curious. If you can succeed in doing that, you can start talking with them, but before you have managed to do these three things, they might have a hard time listening to you, because they are caught in their own fear.

I want agile to meet architecture and I want to focus on the role of architecture in agile development. 

To help them understand, I want people to see that there is still a need for some architecture up front, but that you need to revisit it when your in-built feedback loops show there is a need for changes. I want them to understand, that agile does not mean no more architecture. That there is still a need for architects and discussions about architecture.

To reduce the fear, I want them to see examples of how other companies are succeeding in doing that, but also give them some bad examples to laugh at and learn from. You often discover the tension by noticing it in their behaviour: How they talk about agile, what examples they choose to talk about, what experiences they focus on. Tension is most effectively reduced with laughter.

To make them curious, I would like them to hear from experts how you can design an architecture that can be adapted to what the inspections show. E.g. when discussing why the plan for the sprint did not hold, what architectural decisions got in the way and which did we miss to make and need to make now for the future of the system. 

I always try to do these three things when I meet tension among developers and architects during an agile journey. Sometimes I spend 5 minutes at the beginning of a meeting creating understanding by showing the agenda, and that we will not change the world in this meeting, just look at options or small decisions. Then I try to make everyone laugh to reduce fear, either by saying something surprising, making them share a story from work or private life, or showing a cartoon about misconceptions about agile development. I then try to make them curious by telling a story about what I have seen other companies do, or show them different options for how the meeting will move on, and what possible outcomes it could have. 

When this is done, they can start to listen and share and the real meeting e.g. about the architecture process, can start. When this happens you can help them introduce the parts of agile that will help the architecture. Agile is all about inspection and adaptation, the feedback cycles introduced in the different flavours of agile actually helps the architecture become sound. Retrospectives helps us learn from failures, code reviews help architects and developers see the actual consequences of the architectural decisions. Here I assume that the architects use code reviews to get feedback on the architectural decisions they have made for the system.