Standardisation and governance are crucial for the success of large-scale agile organisations since there are several concerns like UX design, security, technology stack decisions and architecture principles that must be solved consistently across all teams. Recently, the adoption of digital platforms in organisations or new regulatory requirements in the financial industry make this even more important. Standardisation is typically failing in large-scale agile organisations for two reasons. First, there is a common misinterpretation that teams don’t have to adhere to standards and guidelines when working agile. Agile frameworks often struggle to find the right balance between emergent and intentional architecture design [1]. Second, traditional governance processes established in many organisations are slowing down agile teams, and decisions are detached from development teams since they are discussed and decided only on the management level or in the “ivory tower”.
Whilst the adoption of agile practices reveals many immediate benefits like higher employee satisfaction, faster development cycles and higher customer satisfaction, it is also important to follow a longer-term IT-strategy and architecture vision to support the business goals in the best viable way.
Standardisation and governance are means to close this gap to longer-term goals but introducing them in a large-scale agile development setting can be challenging.
We propose three steps to achieve this challenging but very crucial task.
- Identifying important candidates for standardisation across large-scale agile development teams.
- Establishing communities and driving standardisation as a collaborative effort, e.g., having processes in place to discuss new standards on the team level.
- Informing, legitimating, and socialising standards to make sure teams adhere to them. The underlying scientific theory of this approach is based on institutional pressure and nudging.
The interested reader finds a detailed explanation of these theoretical models in [2]. In the following, these three steps are explained more detailed followed by a set of recommendations to establish architecture standards in large-scale agile teams successfully:
Large-scale agile development requires standards
There are many reasons why large-scale agile teams require standards, e.g., longer-term IT and architecture goals, focus on knowledge building in certain technologies, regulatory requirements or simply avoiding that agile teams lose time evaluating appropriate technologies for common problems. In the first step, it is important to identify candidates for standardisation. Good starting points are the business and IT strategy of the organisation, e.g., for a cloud-first strategy development teams need to adhere to twelve-factor app principles or variations thereof. Often agile teams already have suitable candidates for standards in mind, so they should be involved in the process early on. The candidates can be documented in a simple template (with statement, rationale, implications), or as a short technical whitepaper (max five pages). Vague words like «should» have to be avoided in both cases, bindingness must be clear and requirements for the fulfilment of architecture standards as measurable as possible.
Regarding technology stack decisions, it is important to continually assess new technical developments. An internal technology radar can be useful that is divided into several categories for frameworks, infrastructure, data management and languages. A standard should follow a lifecycle, like asses, trial, adopt and hold. This allows enterprises to evaluate innovative technologies in a few teams before they are adopted across all teams on a larger scale. The opposite of standardisation – called heterogeneity, or diversity – also must be considered: for instance, standardising to one database product could be disadvantageous since diverse types of databases systems have strengths in particular usage scenarios.
Standardization is a collaborative effort
In the previous step, several candidates for standards have been identified top-down as well as bottom-up and documented in a shared repository or template that is easily accessible for everybody. As a second step, the candidates must be discussed with experts on the team level. For this purpose, an architecture community or architecture guild connecting architects across projects, departments, and locations are crucial.
The main idea is to have an RFC (Request for Comment) process in place in which new standard candidates are discussed for a few days or weeks.
Many companies already provide social media platforms that can be leveraged for this purpose. With the feedback generated in the RFC process, the architecture standard can be improved and formally approved as obligatory work instruction, e.g., in an architecture review board, and added to the book of standards.
This approach has two major advantages:
- Relevant experts are involved in the design of the standard which improves the overall quality and considers edge cases appropriately
- The acceptance of the standard is increased dramatically since everybody can participate in the process.
Informing, legitimating, and socializing standards
Once there are well-defined standards in place, the next big challenge is to organise and manage the compliance of teams and projects to the standards. In the past, organisations typically tried to enforce standards through formal architecture boards with rules and sanctions, e.g., by escalating the fact of a team’s non-adherence to management or denying budget approval. As a result, teams will try to circumvent these architecture boards. For large organisations, it is quite difficult to monitor and assess all teams with respect to compliance with standards.
Instead of enforcing compliance with standards through formal architecture or governance boards, another solution is socialising standards through indirect influence.
Recent research [3] proposes to find a balance between these two approaches, i.e., while traditional enforcement will not be omitted entirely there should be a shift towards more indirect influence.
There are several examples of how this indirect influence can be implemented in large-scale organisations:
- Architecture events in which agile teams can showcase their solutions
- Architecture training or architecture deep-dive sessions for agile teams
- Issuing architecture awards for well designed (compliant) solutions
- Introducing architecture role models, e.g., evangelists
- Making architecture success stories of agile teams visible
Another important aspect of agile organisations is the ownership of architecture decisions, which will require more liability within local teams and not (only) central architects and management. Obviously, with this ownership also comes the accountability for these decisions. This is not contradictory to the overall standardisation goal since there can always be valid reasons to deviate from a standard (budget, release plan, technical feasibility), but the team needs to justify deviating decisions and document respective “technical debt”. The main task of central (Enterprise) architects would be to arrange the architecture community, conduct architecture events or pieces of training and clear ownership of the processes described above so that agile teams can focus on the delivery of business value.
Another idea promoting transparency and exerting indirect influence is to introduce a score for compliance to standards.
This could be, for instance, an architecture label for applications (in the style of the European Union energy label). There could also be a leader board showing teams with the highest score in the organisation, e.g., for best cloud or security architecture. Another idea for a tool implementation based on belt colours is presented in [4] that also contains gamification concepts.
Recommendations
Having no rewards and penalties on architecture standards is another deadly sin of agile. In the worst case, it might lead to business stakeholders not being satisfied and solutions that are difficult and expensive to maintain. Architecture standards are not contradictory to agile values and principles when following the steps presented in this article as well as our recommendations:
- Establish a vital community of architects from different departments, lines of business and teams. In this community, architects should be able to exchange experiences and grow knowledge, but it should be also used to discuss and elaborate architecture standards. This ensures high-quality architecture standards and acceptance.
- Management needs to ensure that architects have the capacity to participate actively in the community to discuss overarching architecture standards and decisions. Ideally, architects are encouraged to share their knowledge and experiences with other colleagues (outside of their team).
- Don’t slow down agile teams with formal approval and governance processes. It is more efficient to create transparency about architecture compliance with an architecture score that is visible to everyone. Nevertheless, architecture boards can provide value by consulting and coaching teams to make the right architecture decisions.
- Provide architecture standards on various levels of granularity ranging from high-level patterns to concrete and clear technology stack decisions. Technical whitepapers can be another good vehicle to communicate best practices with detailed instructions on how to implement them. In the best case, these standards come with reference implementations, sample code or software libraries that can be shared across teams.
___
[1] Uludağ, Ö.; Kleehaus, M.; Xu, X.; Matthes, F.: Investigating the Role of Architects in Scaling Agile Frameworks, 21st Conference on Enterprise Distributed Object Computing (EDOC), Québec City, Canada, 2017.
[2] Uludağ, Ö.; Nägele, S.; Hauder, M.: Establishing Architecture Guidelines in Large-Scale Agile Development Through Institutional Pressures, AMCIS: Americas Conference on Information Systems, Cancún, 2019.
[3] Brosius, Maximilian; Aier, Stephan; Haki, Kazem & Winter, Robert: Enterprise Architecture Assimilation: An Institutional Perspective. 2018. Thirty Ninth International Conference on Information Systems (ICIS 2018). San Francisco, CA.
[4] Uludağ Ö., Nägele S., Hauder M., Matthes F. (2021) A Tool Supporting Architecture Principles and Guidelines in Large-Scale Agile Development. In: Zimmermann A., Schmidt R., Jain L. (eds) Architecting the Digital Transformation.
