The impact of the cultural values of agility: architecture thinking (5/7)
“Individuals and interactions above processes and tools”
Empowering people means giving them autonomy. But autonomy often leads to coordination problems. To prevent everyone autonomously choosing a different direction, it is necessary to focus the collective energies. The role of architecture in an agile organisation is promoting cooperation and agreement between people and teams.
Up to now I’ve mainly written about governance, structures and processes. In other words, about the right-hand side of the above sentence from the Agile manifesto. The success of an agile organisation is determined by the culture, the values which are expressed in the left-hand side of the sentences in the manifesto. Agility is 80% culture and 20% framework.
The culture which belongs to an agile organisation enforces setting up the architecture process in a fitting manner. If the culture of agility has been well embedded in an organisation, you’ll notice this in the experience and implementation of the process. Even if the steps in the architecture process look the same on paper, the experience and output from the process is definitely different than when agility is not anchored in the business culture. I call this experiencing architecture thinking.
Architecture thinking is living by the rules of the game to enable autonomous choices. If everyone in a self-organising team can help to figure out what is feasible and what the advantages and limitations are of choices in terms of adaptability, integration options and applicability of solutions, then you have already gained the world in terms of agility. All agile methods foster the message that ‘change will happen’. Architecture thinking must ensure that self-organising teams are not just agile now but are also robust when absorbing change. This makes sure that they remain agile in the functions that they deliver.
Agile methods are aimed at creating suitable and useful products. It stimulates thinking via use cases, instead of based on technology. Architecture is a means of determining which technological solutions are suitable based on use cases.
You have to find a balance in the focus on, on the one hand, delivering what is required and, on the other hand, being ready for future change. One-sided focus on delivering function reduces future agility. It means you lose the capacity to deliver new functions. One of the principles in the Agile manifesto is not without reason:
“Continuous attention to technical excellence and to good design enhances agility.”
Evolution also means that the technology used is adapted to what fits at a moment of time or a particular course of action. Occasionally rebuilding to remain agile is a necessary part of an environment where technology is the motor for change. A lot of organisations find it hard to accept that teams temporarily don’t deliver any new functions to concentrate on remaining agile and they don’t want the pace of delivery to be delayed by too many technical debts.
Architecture thinking can help teams look at not only the functional requirements via use cases (what does it need to do?), but also the non-functional requirements (how does it need to work?). Examples of non-functional requirements are, for example, the requirements which are made about how up-to-date the data is or about the quality.
Non-functional requirements are only a means of arriving at a supported idea about what a suitable solution needs to be able to do at a given point in time. These requirements will also change. Knowing when you should deviate, temporarily or in your course, is the undefinable culture aspect of architecture thinking.
Exploring the organisational environment is a daily task if you want to see changes coming. If you don’t do that, change will take you by surprise and you will be constantly chasing after the facts instead of being agile. In a technology push period, such as the current one, constant evaluation of new and alternative methods and techniques is part of a team’s daily work. You need to understand what new technology can bring you in terms of value and limitations to estimate the impact on your organisation. Continuous evaluation of technology should be a value in your organisation and not, as is now often the case, be viewed as being at the expense of productivity.
A tried and trusted way of evaluating is by carrying out a Proof of Concepts or Proof of Values. To avoid a semantic discussion, I will refer to them as prototypes. The aim of prototypes is to stimulate the interaction and discussions between and with users.
- Trying and selecting – trying out new options, with users.
- Testing and proving – testing alternative solutions against the requirements.
As befits an Agile way of working, the prototypes are short-cycling and have a pragmatic approach. In architecture thinking, the focus always lies on the value for use. If there is no such value, then the investment is minimal. If there is some value, then you want to harvest it as quickly as possible.
Pragmatism is built into architecture thinking, where the consequences of choices for the whole organisation are borne in mind.
The impact of changes which go beyond a single team will need to be addressed jointly by the teams. But how do you do that? The answer will be set out in the next and last content section of this series. Formalizing the governance structure: agility with architecture.