What role do architects have in agile development?
Agile methods can seem disconnected from the ugly realities of software development in large and complex enterprise environments. The systems, data, processes and strategies that make up the enterprise have to fit together into a coherent whole. There needs to be a shared understanding of the system design and this is where architects normally find their niche.
However, architects tend to be associated with bureaucratic and slow-moving processes that can seem at odds with rapid delivery. Many organisations adopt “agile” with an almost fanatical zeal precisely because they are not terribly agile to start with. Any barriers to frequent delivery are swept away in favour of the all-powerful team and architecture can become a dirty word. After all, one of the principles of the agile manifesto states that:
“The best architectures, requirements and designs emerge from self-organising teams”
This is certainly an ideal, but do individual teams have the perspective or expertise to achieve this within a distributed, enterprise environment?
Enter the "master developer"
In this case, some kind of design authority is generally required to work across the teams to ensure the integrity of the overall system and spot issues before they become obstacles. This role shouldn't be confused with governance, where design edicts are sent down to teams from the "ivory towers" and architecture boards. It can only be effective with the consent of the teams.
The Poppendiecks referred to this role as the master developer in "Lean Software Development". This idea is based on a study led by Bill Curtis where they found that for most large systems a single or small team of exceptional designers tend to emerge that take responsibility for the system design. The implication is that this authority emerges naturally through superior knowledge rather than being asserted by hierarchy.
This suggests a very different role for agile architects based more on influence rather than structured governance. Sometimes teams will need guidance and help, but architects will have to earn their respect before they can make a meaningful contribution.
Agile Modelling identifies a similar role of the “architecture owner” who facilitates the creation of architecture rather than taking sole responsibility for it. This describes a “hands-on” technical leadership role where mentoring and skills transfer is also an important focus.
This model also offers an approach for scaling up development, where architecture owners collaborate with enterprise architecture efforts to ensure that appropriate strategies are being adopted. In this model architects remain part of the team even at scale rather than forming a separate governance organisation.
Overcoming the urge to control
Many architects have a natural instinct towards governance and consolidation. Should teams be able to choose their own development tools and define their own standards? Wouldn’t this lead to chaos? The fear is that any gains you make from empowering teams might be outweighed by problems associated with development silos.
If you really want to empower teams to act independently then you may have to be prepared to deal with the consequences. They will start preferring technologies and tools that you’re not so keen on. The may adopt design approaches that make you feel uncomfortable. They may start to adopt their own approaches to source code control, test automation and deployment automation that differ from other teams.
By empowering teams you are inevitably reducing centralised control and clearing away governance structures. This is not necessarily a problem as it can be surprising how little you really need to control between development teams. The important thing is to be clear about where the boundaries lie and why you are drawing them.
No team is an island
There can be a tension between the principle of self-organising teams and facilitating collaboration, particularly when working on larger distributed platforms. The more a team needs to co-operate, the more its sovereignty over development is eroded.
In a distributed development teams have to develop services that can collaborate effectively and this does not happen spontaneously. There needs some level of centralised ownership if only to identify the main services, interfaces and protocols that bind everything together. The teams can still be given a great deal of freedom over the implementation detail, but this does have to be within some defined boundaries.
A matter of trust
You can radically reduce the productivity of a team by applying micro-management to it. Agile development is supposed to free teams from the kind of planning and oversight that often serves to reduce velocity. With this comes the implicit need to trust the team. Most of the time you’ll find that teams end up doing the right thing without having to be prodded towards it.
However, this does not eliminate the need for planning or over-sight, particularly when dealing with enterprise development. The trick is to recognise what “just enough” governance looks like and not be tempted to stray beyond this boundary.