This article provides a synthesis of an over a year experience designing IT organization in the scope of an agile@scale transformation involving 7000 persons.
It explains how to align your IT organization with business Value Streams and business strategy to optimize the Time to Market on a given axis (or any other optimization axis derived from your business strategy).
1/ Identify your business Operational Value Streams and the associated IT Organization Units
This chapter is dedicated to the identification of IT Organization Units. By Organization Unit, I mean a group of people whose size is less that the Dunbar’s number – a suggested cognitive limit to the number of people with whom one can maintain stable social relationships (the commonly used value of the Dunbar’s number is 150 people; sometime 125 is also used).
First, you should identify your Business Operational Value Streams – high-level business processes providing value to customers. The schema below presents an oversimplified value stream example.
The golden rule is “IT Organization Units should be based on one or a set of Value Streams but a value stream should not cross several IT Organization Units”.
Why? As a change to the system(s) supporting the value stream is managed in a single IT Organization Unit, there is less synchronization need to build the change, leading to better time to market.
But what if several Value Streams cross some centralized big components like data warehouses or referential (these centralized components needing several hundreds of people to maintain)? Should you integrate slices of the data warehouses and referential into each Organization Unit or keep the data warehouses and referential into a centralized Organization Unit? In the first case, you optimize the time to market and in the second case you optimize the coherence and the cost. It’s up to you to choose the best solution keeping in mind the advantages and drawbacks of each scenario.
Note that this article doesn’t address the design of transverse departments that may be needed.
2/ Identify the Feature Teams of each Organization Unit
We will then dive into the design of each Organization Unit and think about how to split an Organization Unit into Feature Teams.
We will first start to define what a Feature Team is: a long live group of 5 to 9 persons, responsible for a range of features, collocated, autonomous, multi-skilled and cross-functional.
Firstly, why organize your Organization Unit into Feature Teams? Because Feature Teams are aligned with value stream and lead to a better time to market. Furthermore, in opposition to a team dedicated to a project, Feature Teams are long lived so they allow the capitalization of team skills and knowledge.
The first split axis of your IT Organization Unit into Feature Teams should be by Value Stream to optimize time to market. Then for a given Value Stream – if the Value Stream encompasses multiple teams – what should be the second split axis? An optimal solution would be that Feature Teams be interchangeable (the blue, the green, the red team) with no scope specialization, allowing with the help of Agile at Scale synchronization mechanisms a dynamic allocation of features to Feature Teams. In practice, this is difficult to achieve because of functional and technical specialization. It is always a compromise: if your split axis leads to a feature team with a narrow scope along a value stream, the feature team may be in charge of too many applications, leading at least temporarily to many specialization silos inside the teams. Bad! An alternative is to have a set of Feature Teams on a less narrow scope but with Agile@scale synchronization mechanisms: there will be less specialization silos and the time to market will still be great due to these Agile@scale mechanisms that will enable teams to coordinate on transversal features.
Before addressing the different split scenarios, I highly recommend that you elicit the business strategy, especially the business transformation expectations and their prioritization.
For instance, I have recently organized a workshop with the business of an Organization Unit on this topic and the results were: for some identified types of features, one should optimize the time to market along the Value Stream. For the other types of features, one should optimize the time to market by activity of the business process as for this kind of feature types, if an activity of the business changes, the probability that it may impact other activities of the business process is low. Moreover, the systems supporting the different activities of the business process were on different development streams. This gave me a first split strategy.
Another important point is to identify the constraints: the ones related to the team localization and the ones related to the team specialization.
After having identified the business strategy and the constraints, you should identify the Value Stream split axis scenarios (again only if the Value Stream involves several teams): for instance, a split may be by client, by group of feature types, by business object, etc… Another split axis may be obtained by analyzing the IT urbanization. If the degree of coupling between two systems is low, it is better to dedicate each system to separate teams. But if you change the organization, the Conway law may play against you.
I highly recommend that you formalize each scenario including, for each one, the advantages and the drawbacks. In the case of my data warehouse example where the Organization Unit is mapped to the data warehouse, the split axis can be either by business line or by using a data type partition. In the first case, you optimize the time to market and in the second one, you optimize the coherence and the cost – however in this case, you will also need Product Owners being able to manage the priorities across several business lines.
You should also pay attention to the fact that split axis leads to long live Feature Teams with a constant distribution of work. This means you should consider the evolution of the business strategy.
I also highly recommend that you involve all stakeholders to select the best scenario. I recently involved all the members of an Organization Unit: it led to many advantages. Firstly, people identified other advantages, drawbacks and constraints we had not discovered. Secondly and most importantly, it involved everybody in the transformation and brought intrinsic motivation.
Chosen split axis leads to Feature Teams or groups of Feature Teams. At this stage, the Feature Teams should only be logical and the team members should not be allocated to them. It avoids political and personal pressure.
3/ Map team members to Feature Teams
The next step is to map team members to Feature Teams. I recommend organizing a workshop in which each Organization Unit member selects his own Feature Team. Of course, during this workshop the Product Owners/Scrum Masters/Managers should present each Feature Team and describe the Feature Team scope, the team size and the required skills. I recently facilitated such a workshop and it was a great success!
Member of inspearit Agile@scale community (community designing an Agile@scale transformation approach)
More detail is available in the inspearit Agile@scale transformation approach including guidelines of the different workshops to be performed.