Agile and architecture (3/7)
The focus of the previous articles in this section was the need for agility and the role which architecture and architects play in developing the evolutionary path of the organisation. But what is the relationship between Agile and architecture?
The starting point for Agile is the Agile Manifesto. The Agile Manifesto is a document with assumptions. As befitting a manifesto, it formulates principles, the practical application is left up to you. Don’t forget that the manifesto was a backlash against the culture of software production under oppressive governance.
The Agile manifesto doesn’t say anything about the role of architecture. In fact, it is often turned around, because governance and architecture aren’t explicitly mentioned, some say that there is no longer a place for the architecture process.
In discussions about governance or architecture, there is always someone who brings up the following principle:
““Responding to change over following a plan”
Which then leads to the conclusion that project planning and planned architecture don’t belong in an Agile world.
However, everyone omits to reads the side note
“Although there is value in the items on the right, we value the items on the left more”.”
And that is exactly what matters. The emphasis needs to be on results, on meeting targets. Planning is important in this, but it is only an instrument. If you have been working for any length of time, it won’t be hard to think of a number of examples where meeting the deadlines became an aim in and of itself.
The principle quoted actually contains two messages:
- Don’t be blind to change and be prepared that you will have to change (‘Change Will Happen’)
- Adapting also means that you can be agile at the moment when change occurs. In an environment where the pace of change is high, you need to be nimble and not sluggish.
The principles in the manifesto do touch on a need for architecture. This becomes clear in the following principles:
“Agile processes promote sustainable development. The sponsors, developers and users should to be able to maintain a constant pace indefinitely.”
“Continuous attention to technical excellence and good design enhances agility.”
“Simplicity, the art of maximising the amount of work not being done, is essential.”
“The best architectures, requirements and designs emerge from self-organising teams.”
The last principle fuels the flames of the discussion about architecture processes in an agile organisation: See! Get rid of the architects! It is more nuanced than that. It doesn’t actually say anywhere that you can’t have an architect in a self-organising team.
What the principles make clear is that you need to give the responsibility for the quality and usability of information products to the people who are using and making those products. This is only possible if they work together and are allowed to take their own decisions.
The various Agile methods develop these principles into different models for working together. There is, however, one practical problem. How do you ensure that there is some level of consistency if you work according to the above principles or if you want to scale up development across the boundaries of the individual self-organising teams?
If you don’t think this through carefully beforehand, you’ll come up against limits. In their “Engineering Culture” films, Spotify explains their experiences with large scale Agile development activities. One of the points is the conflict between consistency and ensuring agility, or as they call it ‘Alignment versus Autonomy’ (the fragment starts at 3:05).
Spotify’s central motto is: “Alignment enables Autonomy”. This is consistent with our own experiences, admittedly on a much smaller scale. In order to achieve alignment, you work from coarse to fine.
In order to explain architecture alignment, I’d like to first clear up a misunderstanding which I often come up against: Working with Agile means that you have no idea where you are headed or what you want to achieve. It is not as if you just put a team in a room and let them work out what they are going to do.
A team contributes to achieving organisational aims. One of the good aspects of working with Agile is that all the knowledge you need is gathered together and this collective is mandated to seize their responsibility in order to achieve results. How that is worked out is up to the team.
An architect can be part of a team or be outside a team and set conditions for a team. The most suitable form depends on the situation. You need to estimate what is going to work best in order to ensure that it fits the organisational environment (alignment).
Agile teams don’t work in a vacuum. Giving them clear boundaries and aims allows professional autonomy to flourish. And architecture knowledge is just one of the necessary ingredients for this.
Within that framework there are all kinds of requirements which need to be agreed between the team and the users and which can lead to various different solutions. The architect, inside or outside the team, can check if the consequences of the alternatives fit into the framework and if they could lead to future limitations in keeping the solution itself agile. The argumentation for the final choice which the team makes ensures a joint picture of where the boundaries of the solution lie. It is easier for a team to decide to let go of a solution if a change in the environment necessitates it.
While working towards a solution, a team can make demands about the working method, about templates, naming conventions, standards for data modelling, for ETL. All of these standards are aimed at producing technically predictable, maintainable and, especially, adaptable information products. The aim of working with Agile is that you are easily able to adapt to change. By standardizing a joint working method, an operational form of alignment, you create autonomy in the actual development and you can concentrate on what is really important: delivering value through information.
The method of alignment described provides flexibility at the moment you need to adapt to change. And because teams can take their own decisions how they react to a major change, the resistance to such a change is lessened. Within the architecture process we are used to working from coarse to fine: from guiding principles up to working out solutions and temporary workarounds. In an agile environment, the responsibility for taking decisions in the architecture process is taken in a different place than more architects are used to. That requires an attitude change for the architect. I’ll be going into this in more detail in the next instalment.