A lot of organizations by now recognize the benefits of working in multi-disciplined BusDevOps teams. Teams where IT engineers closely collaborate with business oriented colleagues coming from Product Management for instance. We recognize the fact that these teams are much better equipped to deliver products and services that customers really want. Do the right things and do the things right.
This could be viewed as a pattern where IT is completely integrated with the business lines. Although IT is the backbone for many organizations it was considered for years as a support function. Support functions amongst many others like HR and Risk that do not directly offer products to the market but facilitate the core business functions.
In this article the Business/IT pattern is also projected on other support functions in order to strengthen the end-to-end responsibility of teams. Integrating them in the agile delivery organization in the same way as done between IT and Business, will help to increase the agility of the organization.
The marriage between Business and IT
If you would have asked senior leaders in large organizations a couple of years ago what they considered as the support functions in their organization, you would probably have received an answer like HR, Finance, Risk, Legal and IT. With regards to IT however a lot has changed. As an answer to the complaints that IT was underperforming, delivering too late and with the wrong output, IT has re-invented itself inspired by the well-known Agile Manifesto. They started to make use of frameworks like SCRUM and SAFe for scaled agile ways of working. Also the benefits of DEVOPS was recognized as an added value in order to break down the silo’s within the IT discipline; you make it, you own it, you maintain it, you delete it. But there was a kind of glass ceiling on the impact of all these IT initiatives. As the whole idea was that organizations should become as adaptive as possible towards changing circumstances, this could not only be solved by introducing agile ways of working within the IT discipline. The next logical step was to integrate IT within the business functions in a scalable way. This was picked up in frameworks as SAFe and the so-called Spotify model (tribes, chapters and squads). IT and business roles were combined in the multi-disciplined teams. The craftsmanship for the various roles (IT and business roles) was secured by mechanisms as chapters. A chapter lead is responsible for the way the expertise is applied for in the teams. As an example for this a chapter lead for Java Development makes sure that Java code is made in alignment with the IT strategy for that. In a similar way the business expertise was handled by chapter leads for instance in the way Customer Journey expertise was performed in the teams. And although changing the organizational structure is not enough to become agile as an organization, it at least moved away the barriers in the old organization of the hardly collaborating silo’s. All those teams, and groups of teams like tribes or Agile Release Trains (ART in SAFe), were driven by their purpose that is unique within the organization. This also implied that the (group of) teams were also the owner of for instance the applications they were delivering and maintaining. This has changed the role of a CIO quite substantial. Instead of being responsible for all systems in the organization, the CIO became responsible for the craftsmanship of the IT people in the teams. This implies that it became logical to remain the hierarchical reporting line for IT team members via the chapter leads towards the CIO but in a different manner. The reporting was primarily driven by craftmanship and less by the existing systems. This guarantees the fact that IT work was always compliant to the IT strategy of the company. At the same time it created the situation that the IT members in the teams were functionallysteered by Product Owners and Tribe/ART Leads. So a clear split between HOW IT was performed by the IT staff in the teams and WHAT was performed (driven by delivering maximal business value).
In reality not all IT staff became part of the multi-disciplined teams. Some teams were dedicated within a pure IT purpose, the so-called IT-for-IT teams. These teams are working on generic parts of the IT strategy used by all multi-disciplined delivery teams. An example of this are the teams that create the technical possibilities for continuous deployment within the tribes/ART’s.
So the pattern I am referring to consists of two elements:
- Total integration of IT staff in the business via multi-disciplined teams
- Ownership of generic IT domains.
Projecting Business & IT pattern on support functions
This pattern could also be applied towards the other support functions in an organization. Not doing so might hamper the agility of the organization as it still operates in silo’s. Take Finance or Risk as an example. If they are still operated as separate silo’s there is the chance that changes coming from the combined Business/IT teams are not approved from a Risk or Finance perspective. And this kind of additional hand-overs are what we would like to avoid in agile organizations. Even worse, it may also happen that the strategy between Finance, Risk and the Business/IT teams is not aligned because of the siloed approach and the fact that these reporting lines only come together at Board level. An example for that could be a different view on what it takes to be in control between the Risk discipline and the agile multi-disciplined teams.
Integrating support functions into to agile business organization may not be helpful in all cases. But in those organizations where there is a strong relationship between product delivery and a particular support function, it will increase the autonomy of the teams if the craftmanship of that support function is part of the team.
So let’s explore how the IT/Business pattern could be applied on the other support teams. Take the Risk function as an example.
Risk experts could become part of the permanent staff of the agile teams if that fits in the purpose of the team. If for instance a team’s purpose is to deliver reliable services to the customer, like a mortgage application in a bank, it might be an advantage to have the operational risk competence permanent available in the multi-disciplined team. This will assure that the interpretation of the NFR (Non-Financial-Risk) requirements during development will lead to secure products.
The same things as for the IT staff in the IT teams would apply; the responsibility for the Risk craftmanship applied in the agile teams is with the Risk chapter lead in a reporting line towards the CRO. It is the responsibility of the CRO to facilitate the agile teams with the right risk expertise.
It can also be the case that there is no permanent need in an agile team for risk expertise. Only for one or more sprints the expertise might be necessary. In that case the expertise is supplied by an expert team of risk-experts, under the responsibility of the CRO. The Product Owner deals with the priority setting of the backlog in such a way that maximal business value is delivered. If for a specific backlog-item risk-expertise is required, the expert team will deliver that.
It can also be the case that the risk discipline also owns a certain risk application that is generic for the whole organization. That could be organized as a Risk tribe or ART, directly under the responsibility of the CRO.
All these examples within the Risk domain should make clear that we are not debating how crucial it is to manage the risks in an organization. It should be seen as another way to organize this. In such a way that the total risk is managed at least in an equal way as done before. But at the same time organized in such a way that it helps the multi-disciplined teams to make optimal use of the risk competence during the development. All risk experts will operate in the teams according to the risk strategy, their presence in the teams will avoid misinterpretation. It will increase the possibility within the teams to deliver secure products to the market without unnecessary hand-overs. So the teams in the tribes have an increasing responsibility to manage risks. Combined with the management of the risk craftmanship and risk strategy delivery by the CRO it should maintain the required level of risk management but in a more efficient and effective way. I hope this shows that the integration pattern between IT and Business could very well be applied for support functions like Finance, Risk, HR, Legal etc. So CRO, CFO, CHRO, CLO etc is responsible for the craftmanship in the respective domains and the tools these experts need.
Making the support expertise available to the teams
A further detailing of applying this pattern comes when you take the size of the different domains in consideration. Take for instance Legal Support. I really hope that there is no permanent need within any of the agile teams for Legal support. This may be the case in only a few sprints every now and then.
It is also not common that a Legal support team also maintains their own systems.
So for small support functions it might be sufficient to organize the expertise in an Expert team with a team lead responsible for the Legal craftmanship. Every member of the Legal Expert Team applies legal support to the agile teams on specific request during one or more sprints.
So the way how the craftmanship of the different experts becomes available to the teams is depending on the need within those teams (permanent or only when relevant) and the total amount of experts available.
If an organization intends to apply the further integration of support functions into the agile business organization, it is recommended to implement this for all relevant support functions together or at least according to the same organizational design principles. This will avoid too many interim situations where some support functions are already part of the agile way of working and some are not yet.
As part of a transformation towards an agile organization, a common way of doing that is designing the value streams that deliver value to the external or internal customers.
If you would include the support functions into your organizational value streams as well, it could lead to efficient collaboration. It could lead to value streams consisting of various support domains formerly operating in silo’s Take as an example the domain of Product Compliance. This could be seen as the combined responsibility of the Compliance, Legal, HR and ORM (Operational Risk Management) departments. If you would recognize in the organizational design the need for a value stream called Product Compliance Management, it could be organized by putting the Compliance, Legal, HR and ORM expertise in one multi-disciplined team. The individual craftmanship for each of the expertise’s will be assured by the chapter leads into respectively the C-Compliance-O, C-Legal-O, C-HR-O and CRO, following the same pattern as described in this article.
Conclusion
In my view the integration of all support functions as described above where applicable will help an organization in its strive for agility. An agile organization is suited best to react to changing circumstances by quickly collaborating with the relevant teams.
The strong idea is that those organizations that are best equipped to adapt to change will be the ones with the biggest chance to survive. And those changes can be pretty disruptive as recent examples have shown like the discovery of smartphones. An IT company like Apple, disrupting the existing marketplace for mobile phone manufacturers. Some survived, some did not.
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.
