Old school organisations with traditional silo’s as Front Office/Mid Office/Back Office/IT/Risk…. will die. Like the dinosaurs they cannot adapt quick enough to changing circumstances. The solution for that are multi-disciplined teams where all relevant disciplines are represented. But is this also a realistic scenario for large organisations with hundred or even thousands of teams? In this article some best practices are shared on this leading to the answer ‘yes, that is possible’, even in large organisations.
Multi-disciplined teams in itself are not enough as a solution
All organisations are or should be constantly searching for the best way to stay relevant for their customers or civilians. And this is not an easy task as the challenges are quickly piling up. Challenges that may disrupt the status quo that sometimes existed for a long time. But for the major part of the organisations, changes in technology, new eco-platforms, changed customer expectations are reality. A common approach to be able to cope with these challenges is to re-organise into an organisation that is much better equipped to quickly adapt to changing circumstances. The famous buzzwords used here are ‘do the right things’ and ‘do the things right’. An important element of this new and more agile organisation is the usage of multi-disciplined teams. In those teams various disciplines that used to be organized as separate departments work together.
In the former organisation, the different steps in the development of new features and even new products, channels or markets were taken in a more or less sequential order. This in itself already causes relative long delivery times but was in a lot of cases even worsened by the fact that the usual habit was to organize the work packages in rather big chunks. We all considered it ‘normal’ that for instance the Risk department only wanted to react on the full design instead of small increments. This way of working was fully facilitated by the way the different departments or silos were operating and steered. The Risk department in the example was reporting to the Chief Risk Officer and not to the ‘Chief’ responsible for new product features.
But apart from these ’reporting lines’ issues, there is another aspect worthwhile mentioning. The concept of small multi-disciplined teams of max 10 persons, working iteratively and incrementally, sounds great but how to do that with disciplines that you do not constantly need in the team? The answer to that comes from careful designing of the new agile organisational model.
Designing of the new agile organisational model is not easy
Organisations that exist for a longer time have usually gradually grown in size too. This caused for the necessity to constantly adapt and improve the internal processes. At a certain moment these internal processes have created the internal silos as mentioned before. This can be silos like Front Office, Mid Office and Back Office where it is difficult to act according to ‘the voice of the customer’. But it can also be with silos for the different products where a customer oriented approach is difficult to achieve if the organisation only thinks in terms of products. By applying all kind of process improvements, the result for an organisation was that the focus was entirely on the fulfilment of these processes. In a lot of cases ‘the voice of the customer’ was difficult to recognize and even created situations where the customers were confronted with the rigidness of the internal processes. Do you recognize the situation that for instance a call centre employee is not able to handle your request as ‘another department using a different system’ need to become involved.
An important driver in a transformation towards a more agile organisation is to improve the time-to-market for new products and features. But easier said than done in practice if the general opinion within the organisation is still build around the way things are organized nowadays. A good approach to change that is to start thinking from the real customer perspective. From that perspective the customer journey is derived from the line of thinking ‘what would be the preferred interaction between the customer and your organisation’. If those sets of customer journeys would be used to design the new organizational model, the organisation would be best equipped to adapt to changes. This comes from the idea that the purpose of multi-disciplined teams and groups of teams are connected to one or more customer journeys where a team is capable of handling the full customer journey from an end-to-end perspective. Although this customer journey based approach for designing your new agile organisational model is theoretically the best option, reality calls for a more hybrid model where the balance is found between a customer journey based model and a model that best fits the current constraints for the organisation like the existing IT landscape. As a result of this approach the most logical composition of the teams is created; what disciplines do you need available in your teams? This also implies that the non-permanent or partially needed expertise is defined.
The price for this more hybrid model is the fact that the end-to-end responsibility of the teams and groups of teams (tribes, agile-release-trains etc) cannot be hundred percent met in the purpose of the teams. The logical consequence is that processes are logically cut in parts being the optimal result of looking from a customer journey perspective as well as the existing organizational constraints.
How can you solve the reporting line issue in multi-disciplined teams?
This can be organised in several ways like 1) professionals with the same craftmanship permanently organised within a cluster of teams by a chapter lead (Spotify model) responsible for the correct appliance of that craft (for instance java coding) or 2) professionals permanently of temporarily assigned to a team or cluster of teams (for instance Architects, Legal advisors, Risk professionals etc).
The first model is a best practice for those disciplines that are permanently required in teams in order to fulfil the customer needs in terms of maintaining and changing the set of products and services needed. In a team that is responsible for a specific product or service, it is common to have the IT related professionals work in the same team as the business oriented professionals. Depending on the purpose of each team the actual composition will vary. This desired composition is the result of the agile organizational design activity.
The second model is a more complex model to design. Let me explain it with two examples that are illustrative for the associated design patterns.
The first example is from an IT architectural perspective. In a lot of the larger organisations, there is an important task on the shoulders of the IT architect discipline. They are supposed to pave the way towards the desired IT landscape coming from the existing IT landscape. This is often resulting in assigning an architect to a cluster of multi-disciplined teams. This architect then becomes familiar with the characteristics of a certain functional domain (for instance a related group of products and services) and at the same time is able to make sure that the cluster of teams is developing towards the desired target IT landscape. Although not in line with the agile concept of teams capable to take full responsibility within their purpose, in large organisations this is often handled by a dual reporting line in this case for the IT architect. For instance a functional reporting line within the group of teams (to the tribe lead or Agile Release Train Engineer) where the business value of the work is handled and a hierarchical reporting line to the Chief Architect Lead for the appliance of the architectural path towards target landscape.
The second example comes from a professional discipline that is only needed for a short period of time (a couple of sprints for instance). This can be for instance the usage of Legal Support. Most teams or cluster of teams do not need legal support on a permanent basis. They only need that competence during a specific set of sprints where the design of a new product or product feature need to be compliant with existing laws and regulations. In those cases a person from the Legal Support team is temporarily assigned to the team or cluster of teams. During that time the same dual reporting line situation is created as for the IT architect in the first example. The only difference between the two examples come from the fact that the IT architect is permanently assigned to the cluster of teams where the Legal Support professional is temporarily assigned to the team or cluster of teams.
Please refer to the article ‘agilize the support functions too’ for a deeper explanation on these patterns.
How can you stay agile in case of not completely end-to-end responsible teams?
As explained in the article ‘aligned autonomy’, teams in organisations can be seen as birds operating in a flock. Autonomous in their art of flying but always as part of the flock. Although the metaphor is not sufficient for that, we just concluded in the previous paragraph that the composition of teams is the result of proper agile organisation design. Due to the fact that real end-to-end autonomy is hard to achieve in large and complex organisations, the concept of assigning professionals with certain expertise on a fixed of temporary basis was used. Combined with the fact that an organisation may have hundreds of teams and tens of clusters of teams, a proper scaling mechanism need to become in place. A scaling mechanism where amongst others the dependencies between teams is managed is a prerequisite for the flock to act as flock or to put it in more business perspective, a scaling mechanism where every team is always aware of the current strategy and able to value the contribution of the team towards that strategy. A best practice for such a scaling mechanism is the combination of a for instance quarterly Aligned Autonomy process where strategic priorities are translated in the quarterly or programme-increment planning of the teams. This scaling mechanism need to be combined with an adjacent process that is synchronized with the sprint rhythm of the teams. A best practice for that is the use of Obeya. On the portfolio wall of the Obeya room the result of the Aligned Autonomy process is visualized with bi-weekly updates from the teams. This Aligned Autonomy process also caters for the use of the temporary professionals needed for a couple of sprints. As the capacity of those professionals is limited, the assignment to teams should be part of the business valued based prioritisation. The process also caters for the necessary dependencies as a result of the per design handovers in the agile organisation model.
So the more dependencies per design are needed, the more relevant but complex becomes the Aligned Autonomy process.
Conclusion
The intention of the article is to show you that ‘silo busting’ is also possible in case of large organisations with complex dependencies and numerous silos. It requires a proper agile organisation design, scaling mechanisms to support the dependencies and clarity on reporting lines.
Henk Venema
Henk Venema is an experienced consultant helping organizations in their transformation towards agile organizations.
He combines his experience on Programme- and Portfolio Management with his experience on large scale agile transformations.
Partner in a cool agile startup company
