For a long time now it has been unclear how architecture and agile delivery can work together effectively. At times the gap between the two can seem like a chasm. This divide can present significant challenges to heads of architecture and product owners who want everyone to work collaboratively and happily, and to the architects and developers who need to find the right way to work together.
Over the years, Cyma has worked with many clients facing these challenges. This blog provides a quick reminder that architecture is important, regardless of how you choose to go about delivering, and then provides a few tips on how to bring architecture and agile together.
Is architecture relevant in an agile world?
Well, yes of course. But also, no. Certainly not the way we usually go about doing it.
Agile development and delivery methodologies emerged as a response to the perceived failures of more traditional waterfall approaches. There will be few people out there who continue to believe that designing a solution in its entirety, as big up front design activity (BUFD) with limited user engagement, is a sure path to success - however you may choose to measure success.
But architecture, in any of its forms, is not a function that exists solely to support waterfall methodologies. Architecture exists to help identify what to build, not how to build it. It doesn’t matter how you deliver change, if it is complex enough then it needs some level of architectural thought.
The way we traditionally do architecture, however, has been strongly influenced by the delivery methodology and its governance structures - take a look at the common architecture frameworks (TOGAF, Zachman, PEAF, etc) and you will see what I mean. So in its current incarnation, architecture can appear to agile teams to be outmoded, irrelevant, and simply too slow.
Architecture is needed, we just aren’t doing it in a way that supports agile teams. So rather than throw the baby out with the bathwater, why not look to see how we can make architecture work within an agile context.
But before we get to the solution, let’s take a closer look at the problem.
Why don’t development teams engage with architects?
There are so many reasons for this behaviour. At the top of my list is the culture and behaviour of architects and architecture practices. It is all too easy to view ourselves as Guardians of the Enterprise, whilst we all too often come over as Doctor No! This is not just a problem in agile environments, but they can make it worse. Instead of fighting it out in endless design and governance forums of death, the agile delivery team simply ignore the architects and move on. Agonising over architecture decisions is not a guarantee of success, but then neither is just getting on with it. Both approaches have their obvious drawbacks and advantages, good architecture can help make the best of both.
The agile teams are not blame free. Some teams are new and struggling with the task of delivery, and simply unaware or misinformed about the value that architecture can provide. There can also be a maverick attitude to how they work. Working closer to the business and closer to the money (product rather than project funding) they feel they have the authority to make the calls. Maybe they do, but it can be easy to miss the wider business context that architecture should be there to provide. Without a wider (dare I say enterprise) view some decisions will be, at best, sub-optimal, and at worst, plainly wrong and expensive.
As mentioned above, the engagement model is also an issue. Architecture typically moves at a slower pace than agile delivery teams and favours BUFD. We produce big documents and have governance gates that make little sense in the agile world. Very few people read architecture documents before, even fewer (if any) now. It is a complete mis-alignment that leads to frustration and disengagement. Good architects should be acutely aware of their stakeholders and audience, and an agile team is no exception. In order to work together we need to change how we engage.
There are many more reasons, but following our blogging guidelines I will leave it at a punchy and beautifully prime 3.
How can we change this dynamic?
So we can carry on regardless, trying to bring together these two different disciplines, hoping that it will eventually work. Or we can accept that something really needs to change. In my view, one of architectures key roles is to bridge the gaps that exist between different stakeholders. So I strongly believe that it is up to the architects to make the change.
Sticking with the blogging guidelines, here are my 5 Hacks For Successful Architecture In An Agile World:
Just enough architecture, just in time
As architects, we have to stop writing big documents. We need to take an iterative and just-in-time approach to design. We should be skilled enough to look at the overall requirements and identify the key areas that need attention and those that can be left to later (or not consider at all).
In many practices, changing to an iterative architecture model will be a significant change. But the end result is well worth it. Less to write, less to read. Instead we get to focus on what is important right now.
A good engagement model
We need to work out how best to engage with the delivery effort during sprints and with the planning effort ahead of sprints. And if there is an overarching prioritisation or capital planning forum, how we work with that too. The level of engagement will depend on the experience of the teams and the problems they are currently working on.
This does not mean an architect has to attend all standups, retrospectives and sprint planning sessions. Work out what is needed and where you need to be. This will affect workload and you will need to think about how much of an architect’s time is chargeable to the team and how much needs to be funded elsewhere.
If the agile team is using a wiki, then the architecture team should use one too. In fact, we should be doing this anyway. No more beavering away on hidden documents until approved. Instead work on living documents in a wiki so that people can review or comment as you go. The same goes for chat or IM tools.
If the architecture team is using some common tools, then make sure the development team can understand what is being produced. There is no point pasting an ArchiMate diagram into your solution wiki page if the team does not know how to read it.
No more Design Authorities that pontificate over how well a solution meets the current principles (often forgetting about the requirements!). No more governance gates that require the submission of a completed solution document. Instead, governance needs to be light and fast.
How you change this will depend on your environment and the skills and experience of the architecture and delivery teams.
One approach could be to drop the idea of solution approval all together. Instead, run an ad-hoc governance forum that looks only at architecture decisions - those decisions that have a significant or cross organisation impact. Trust that the architect has discussed less important aspects of the solution with the necessary people - made easier if it is in a wiki. And differentiate between what is an architecture decision, what sits within the architecture solution, and what can be left for the delivery team to tackle as a design decision.
This doesn’t come easy, but it is the most important attribute to a successful working relationship between architects and delivery team.
Trust is needed in all directions. The architect must trust that the delivery team can make good design decisions. The team must trust that the architect has good reasons to require something be done in a particular way. The architecture practice must trust each architect to do their job and raises appropriate architecture decisions. Trust that you are all working towards a common goal.