Introduction
Strictly regulated industries like insurance or banking face multiple challenges when embarking on an agile transformation journey. In this article, we would like to address two of them:
- the need for a high level of (mandated) governance
- the need to build advanced forms of cooperation and communication to prevent new silos from forming.
Baseline: Agile Development vs. Classic Governance
Within industries like insurance or banking, strict regulatory requirements are placed on the organization by regulatory bodies e.g., the German BaFin or Bundesnetzagentur. The subsequent governance requirements lend themselves to waterfall style projects and steering.
However, when organizations transform into agile teams and tribes (clusters of agile teams) these stage-gate style governance structures become a hurdle in agile development.
At the same time the need for cross team and cross tribe communication increases. Communities of Practice (CoPs) are a common format to address the need for communication across a specific domain or topic. Members of the team or tribe can participate and address current issues and concerns, share best practices, and thus support continuous learning. The same applies to non-agile forms of organization – e.g., in traditional centers of excellence, which, like CoPs, cover a topic that is needed again and again in the company.
However, the informal CoPs are disconnected from the governance processes and boards needed to reach approval for the discussed issues. Thus, while CoP members can discuss their concerns, they must seek approval through a separate governance channel. This extra step disrupts the information flow that was previously started in the CoP, challenging their relevance and hindering the decision-making speed of the boards.
This becomes more clear using the example of IT architecture governance in large enterprises. Let’s examine this in more detail:
Complication: Classic Governance as Overhead for an Agile Way Of Working
Existing stage-gate governance bodies face the challenge of quickly changing IT projects: early plans are discarded, projects are split into ever-smaller increments, and the needs of customers change. This results in a continuous change in the architecture. Simultaneously, it becomes even more important to have a good understanding of the current architectural landscape to prevent rework, duplication and different teams and tribes from drifting apart, which would result in complexity. The challenge can be summarized as follows:
- How can we gain continuous understanding and transparency of the architectural landscape?
- How can we ensure that IT governance requirements are met across the landscape, without becoming a major bottleneck?
CoPs address the need for communication and transparency, however participation in a purely informal community of practice is not easy to enforce.
Additionally, the consideration of regulatory concerns is part of the ceremony-external governance process, thus the following questions arise:
- What is the benefit for each individual to participate in the CoP?
- What is the benefit for the team or tribe to dedicate some of the members time to the CoP?
- How can we link the information flow of the CoPs to the governance processes?
CoP+: Community of Practice with a Governance Mandate
You can overcome these challenges by merging the informal Community of Practice with the governance conformance process.
To reduce the overhead and include the governance process in an agile setup (as well as in a more traditional setup), we recommend establishing an architecture guild based on a Community of Practice with a governance mandate.
Apart from the compulsory participation for the tribe representing architects, individual members as well as the teams now have an incentive to participate. It is the same community that not only fosters knowledge sharing and provides a forum to discuss relevant issues, but also has the mandate to approve solutions. This allows for much faster, more direct decision-making.
From a governance perspective, the guild provides the benefit of complete transparency across the landscape as well as a formalized and incentivized ceremony to ensure compliance.
Depending on the complexity of the organization, a guild can be structured into multiple levels. For large enterprises, we recommend the following structure:
- At the corporate level, the guild supports the definition of the strategic direction as well as the operational management. Furthermore, the guild provides the necessary transparency to implement required standards, reduce technical debt and enable legitimate decision-making. The main responsibility for this work lies with the dedicated Guild Lead in close collaboration with the Enterprise Architects. Of course, the EA is an equal member of the guild.
- At tribe or domain level, the Lead Architects form the link between the Enterprise and Team level. Each Tribe must assign a Lead Architect and can actively participate in decision making, thus shaping policy. In turn, there is a bidirectional exchange of information between the tribes and the architecture guild, which considers the individual needs of the agile teams.
- At team level, solution architects are responsible for the solution design within the framework of the defined standards. They are working closely with their lead architect to create consistent architecture. Due to the operational proximity to the product teams, the solution architects act as impulse generators for innovation and decision-making.
According to the principles of lean governance, the guild can autonomously define binding standards, monitor compliance, and actively supports implementation. To manage the associated tasks, the guild has its own backlog to record and prioritize issues. In regular guild meetings, members of the guild work through and discuss new tasks. A Kanban board can be used to ensure that all stakeholders are able to monitor the status of the respective task.
The guild should successively replace all architecture governance boards except for the highest one that the guild itself reports to.
Initially the guild can start as an agile initiative; however, over time it should represent both the agile and non-agile areas of the company.
Summary
In this article, we described the architecture guild as an approach to integrate governance conformance processes within the agile organization while also gaining continuous understanding and transparency of the architectural landscape.
To enable an organization-wide implementation of agile structures, teams and tribes need to work autonomously without having to deal with stage-gate style governance setups.
Additionally, an obvious benefit for each individual to participate in the CoP is needed.
The architecture guild resolves both of these challenges by ensuring autonomy to the teams and tribes within the binding governance standards. With compulsory participation of each tribe’s lead architect, the guild also ensures a regular exchange that leads to higher transparency across all tribes.
Finally, we would like to emphasise that we have also tested and apply the approach of a community of practice with a governance mandate in the areas of UI/UX and security.
