An architect’s attitude in an Agile world (4/7)
Working with Agile requires architects to have a specific mindset towards their work. It is not just about doing it in an agile way, but mainly about being agile, as an attitude. On the one hand, you are ensuring agility by providing a framework, on the other hand, you are often a pioneer for change.
This is true of the enterprise architect, but also of the architect or architect role in an operational self-organising team. Together you need to devise the governance which guards the continuous agility of your organisation.
Architects come in all shapes and sizes. Some are reflective and others are results oriented. The strength of a reflective architect lies in guarding a relative position towards other organisations in the changing environment and the results oriented architect is necessary in order to keep the organisation on the right course on its evolutionary path. A good mix of these qualities improves discussions and results.
How do you ensure agility? The principles of the Agile manifesto talk more about the required attitude than about one single recipe for achieving an agile organisation. How is this translated into the fundamental attitude of an architect in an agile organisation? I consider several principles to be clear about this.
Have an active attitude
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
This is the basic assumption: “change will happen, be prepared”. The sentence begins with a verb: ‘welcome’. An active attitude is essential, as an architect-explorer you go looking for signals which announce the need for change.
A condition for success is that architects need to be given a mandate and earn support as an explorer and guide. The exploration only makes sense if the explorer is a serious partner in discussions in the decision making process. Without that support, you become a lone voice in the wilderness.
Stimulate dialogue
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Take this principle to heart. Maintaining communication is crucial, both inside your team as with teams. Talk about bottlenecks, the consequences of various options or about what you see on the road ahead for the teams. This doesn’t mean, by the way, that no more written documentation is required. Architectural documents are still important, but it is documentation for communication and for reference.
Be the can-do guy
“The best architects, requirements and designs come from self-organising teams.”
As an architect, you can support an agile team or be part of it. However you do your work, keeping on top of it is important. And that doesn’t mean being suffocating, but that you keep looking for agreements within the team or between teams. You are more the can-do guy than the top dog.
Motivate teams to design their own ETL standards and data modelling. Taking decisions in an agile team is a collective responsibility. That doesn’t mean that you have nothing to add. Whether you are part of a team or outside a team, you can still put your technical and organisational knowledge to good use to help the team reflect on the consequences of the options under discussion.
Take care of consistency in solutions
“Continuous attention to technical excellence and good design enhances agility.”
Quality assurance is an important task for an architect. There are always more roads which lead to Rome. It is up to the team to choose which road. Respect the choices which a team makes, but watch that successive choices lead to consistent solutions.
Increasing insights are part of the learning process within a team. Ensure that functions which have already been delivered are changed if the design, design patterns, standards or templates change. Refactoring is not a waste of energy, but anchors future agility.
Defend a team’s right to deliver quality, as an architect you are often in the opposition in an organisation’s political arena, pitted against short term results oriented thinking.
Be a flag bearer for the motto ‘Less is more’
“Simplicity, the art of maximising the amount of work not done, is essential.”
Practise the art of balancing. Carefully maintaining the tricky balance between delivering exactly what is needed on time and the future adaptability of a complete information eco-system. The latter flourishes through technical excellence and a good design. This may however never lead to endangering the structural timely delivery of functions.
When helping design the evolutionary path, saying No is also an option, as long as you keep looking for support and communicate about the consequences in a way that is also comprehensible to your discussion partners.
An evolutionary path is not straight and neither is it a six-lane motorway. In fact, shorts are often needed to be able to keep delivering at a constant speed.
However, nothing is as permanent as being temporary. We are all being very agile by taking agile actions, but we are often not as good at bringing the solution back onto the right path. Even though this is actually the crux of remaining agile.
This is partly the fault of the architects themselves, as they do not always object enough. Dare to state your limits. For example, by requesting budget for the way back and by translating the consequences of deviations in terms of either unmet aims or business value.
You will be heard when you show that you understand what is feasible in the context of an organisation and when you demonstrate the necessary agility yourself, without making any concessions to the organisation’s ability to continue evolving. Architects are not police officers; architects work actively to ensure consistency in solutions to make it possible to achieve organisational aims in the short and long term. That is governance.
If you don’t want to keep returning to a Groundhog Day situation, then it helps if you embed architecture thinking into the working method of self-organising teams. Ultimately, that provides the most returns for the organisation. It marks the crossover point from doing Agile to being Agile.