6. Alignment through supported self service
Why it matters
How do you align self-organizing teams to follow a common intent and architecture?
In traditional organizations, the overall architecture (across systems and/or modules) is controlled by a small group of decision-makers. These decision-makers announce directives and rules that all units have to follow. It’s not unusual that conformance is implemented through a gated process where teams developing new (generations of) services have to present their solution to a council and seek approval.
This type of operation model works against the idea of self-organizing teams and groups of teams releasing frequently with ever-evolving architectural solutions. The self-organizing teams should be trusted and enabled to make informed decisions while simultaneously being aligned towards common technical goals.
The good news is, alignment doesn’t always mean top down, smart alignment can also happen bottom up. This practice is about how you can make this happen.
How it works
The key mantra here is “make it easy to do the right thing” and the “right thing” is making solutions that work with everyone else and aim towards the same overall technical goals (not specified solutions) That’s alignment without the requirement of conformance.
Supported self-service
The way to achieve this is through supported self-service. Support comes in several forms at the same time:
- Documentation
○ Agreed guidelines
○ Agreed principles
○ Patterns/solutions we like or recommend - Community
○ A common forum for updating the above guidelines, principles, and practices
○ A community of practice to deliberately share experiences and learn new things - Available expertise from senior architects that can provide
○ Facilitation
○ Training
○ Coaching - A set of helpful tools made available to the teams
○ Test frameworks
○ Code quality checkers
○ Recommended frameworks
○ Examples
Enabling supported self-service
It’s not unusual that two types of teams are created to support the self-service idea:
- A team of experts whose responsibility is to support the teams in making informed decisions by cross-pollinating, facilitating, training, and coaching. This is a completely different way of working compared to the old decision-making model mentioned above.
- A “toolsmith” team that focuses on creating IT support for the development process that makes self-service easy.
Example 1: Making an architecture shift happen across the enterprise, using supported self-service
Are you trying to modernize your architecture or refactoring old legacy? The companies that have succeeded with these types of shifts have understood that this requires an aligned self-service approach to succeed. Often, this insight came at the price of a few failed earlier attempts.
The starting point in this example is a shared objective in our technical roadmap: “Enable Software as a Service in the cloud”. The company currently has on-premise solutions spread across multiple clients.
The architecture shifts self-service support
The self-service support given to the teams who have the power to make this shift happen is supported by:
● Guidelines
● Principles
● Training
● Recommended framework and tools to ease the transition (with a high degree of automation)
This support is created by a front-running research/recommendation team.
With this support, other teams are onboarded incrementally (team by team) to work in the new architecture.
While the overall timeline of the transformation is monitored by a central research/recommendation team (who often also slices the overall architecture shift into a few incremental steps), each onboarded solution team has its own mandate to decide when the shift to the new architecture should happen in areas of the they are responsible, for including how best to achieve the shift. This allows them to merge context understanding with a researched and prepared approach.
The net effect is a stronger drive and resilience during such big architecture shifts.
Example 2: “It would be great if all teams used automated tests”
In this example, the game company Mojang wanted to get better at using automated testing building Minecraft. The approach that Mojang took was to make automated testing so easy to use that essentially, all teams would want to use it.
Full story here from Henrik Kniberg, Game designer @ Mojang here
References
“Let’s talk about test automation, or how we use Minecraft to test Minecraft”, Keynote. Crisp Day 2021