In the previous article we exposed the mantras that must be assimilated to move towards DevOps. As an accompaniment, organizational models exist for implementation and execution. Compared to old models, these models are truly disruptive, and undoubtedly disturbing. There is no special obligation to impose them in bing-bang mode to transform an IT structure. Nevertheless, the idea of the models’ complementarity will not allow a benefit from an agile organization, because it is necessary to choose between autonomy paradigms/dedicated teams vs command and control/shared competencies. The recommendation will mostly be to proceed by iteration but on perimeters or products where the autonomy will be complete, from build to grave!
Below are some organizational models that allow us to begin reflecting.
In the SAFe world first. SAFe probably offers the smoothest path to DevOps. Some key concepts of SAFe need to be explained to understand:
- The SAFe organization is structured around Trains, which are an assembly of SCRUM teams developing systems in a coherent functional scope and linked to a specific business value chain.
- The teams that make up the train are not autonomous teams, it is the train in its entirety that carries its own autonomy.
- Trains must incorporate DevOps’ principles, including the ability to deliver full versions on demand.
- For this they rely on an infrastructure as a service.
- This train organization can extend to the granularity of a solution, which represents a set of trains synchronized over time in terms of sprints and increment delivery.
To meet these requirements, SAFe introduces a System Team that offers all the services of the products’ technical integration for all the train’s teams. The system team can even be shared within a solution between its different trains. Insiders talk about cross-train teams…
The solution has the merit of allowing technical production teams to remain in their field of competence. On the other hand, it tends to pool this competence and brings us back to working in silos by expertise, and thus in the end by the formation of workflow bottlenecks for all the SCRUM teams that become dependent on the system team. It is therefore very important to associate the train’s system team with the responsibility of the overall outcome.
For its part, the DASA offers a sharper approach that make a lot of sense from an Agile point of view. The concepts that DASA wishes to put forward in its organizational approach are indeed a little bit different:
- Agile teams are self-sustaining additions. This is a strong principle of DevOps seen by DASA. The focus is to ensure that a team should not be dependent on any other service in order to reach its goal.
- For this it relies on an infrastructure as a service that is explicitly provided by a dedicated platform team. This platform team can offer an in-house infrastructure or level 3 services to the cloud.
- The team’s members are easily interchangeable although each has a preferred technical field (test, ops, dev). This is referred to as T-shape skills.
- The DevOps’ organization must be simple. This responds to the famous principle that an organization builds the systems that resemble it: a simple organization builds simple and maintainable systems and conversely, a complex organization builds complex systems (most often similar to gas plants).
DASA’s organization is therefore simplified: Each team (feature team), integrates an Ops and a technical architect (or both in one), which assumes the needs of the team to provide environments and ensure the application’s implementation. They rely on the platform team for provision technical resources and to provide level 3 support. They transfer some of their skills to other team members so a delivery bottleneck does not ensue and they also participate in other team activities (dev and test).
This solution is ideal for a team produced on a small scale. Moreover, it corresponds well to the Craftmanship spirit and to the idea that a general software engineer forms part of the product’s design. For example, the “full cycle developer” model presented by NETFLIX is really close in this sense.
On the other hand, it is clear that this entails a profound challenge to HR management for key accounts that are familiar with silos and careers that focus on expertise or hierarchical positioning. However, DASA does not say much about scaling needs when there is a strong need for synchronization between different product teams.
We can imagine a small adaptation on the side of SAFe that will aim to take into account the idea of the teams’ complete autonomy when taking a good look at these two organizational proposals. In each train, rather than creating a pooled Ops team, it would be interesting to integrate an Ops that makes it autonomous into each team, and that can potentially support test tasks and also development on the lowest layers of developed applications. We will also see below that the SPOTIFY model offers an interesting role through the system owner who becomes a sort of technical guarantor and could easily adapt to a train.
It is therefore useful to position the model proposed by SPOTIFY using its feedback, which is now a few years old and may have evolved. SPOTIFY, like DASA, takes as the imperative to have teams as autonomous as possible in its model of organization at scale. However his model is closer to that of SAFe.
- Indeed if the squad is the autonomous feature team, the Tribe represents the Train.
- So there is an Ops squad in each Tribe that makes a service Ops shared for all the Dev squad.
- The infrastructure teams are also separated, a sort of Tribe in its own right offering a provisionable infrastructure service on demand and evolving according to the needs of the Ops squads.
- The Spotify model also proposes a role that we will develop in the next part, namely the system owner. The spotify’s vision is to have a person presented as the “go to person” for the technical needs and architecture for a system.
The idea of the “System” perimeter is a little disturbing because it does not correspond to any entity in SPOTIFY’s organization and this therefore comes down to a very cross-functional role. However it will fit very well with the train concept in SAFe which is usually attached to a complete system. In DASA’s domain, this also corresponds to the idea of associating a system architect who is directly in the team but who would also have broader skills.