Successfully Transitioning to Product IT Operating Model: Four Key Elements to Organizing Teams
In the world of IT, agile is the new currency. With growing agility in development of new business models as part of digital transformations in enterprises, Agile as an approach to develop software faster and better is now getting constrained by the a) Organisational constructs of siloed plan/build/run organizations and b) legacy, monolithic and shared systems. With 97% of IT organizations using agile development methods today, conversations at the CXO level are not just about technology outcomes but about the business value and building an engineering culture - similar to that of leading tech companies like Netflix and Spotify.i
Large enterprises, with traditional IT organizations that are now in the journey of business-driven digital transformation are witnessing changes across four dimensions:
- Shift to a Product IT Operating Model (design of the IT operating model).
- Restructuring of teams to align business and technology capabilities to business outcomes.
- Modernization of application and infrastructure portfolio to embrace decoupled systems and cloud native microservices.
- Scaling up of agile DevOps practices across BizDevOps and DevSecOps.
All are topics of intense debate and research that can amplify insights around agility and experimentation for enterprises looking to make the shift. One of the most public transformations in progress is that of BMWii. The other case study is that of ING, the Dutch banking groupiii. However, there is no single right approach to driving digital transformation given the different contexts enterprises operate in, but the premise is accepted and business cases have been successfully built.
The element of team organization in the context of a large and global enterprise IT function (with all of its complexity around multi-vendor outsourcing, global spread of business and monolithic legacy systems like mainframes or SAP) is core to the change. The key hypothesis of a productized team is that they are organized structured according to capabilities based on business relevance and within the boundaries of enterprise architecture. For instance, in the retail industry, Buy Online Pickup in Store (BOPIS) is a business relevant capability.
Basically, product teams own the ideation, planning, building, testing and running of IT value streams (increasingly called squads) - a term popularized by the Spotify model. However, enterprise IT teams struggle with the twin challenges a) of defining a product. b) scaling problem, for example a business capability could have multiple squads/Pods/teams spread across vendors and geographies.
Designing team structures: Four key elements
The first design element to think about in the context of team organization is capability. Do we have all the capabilities required for delivering the business outcomes? Have we defined the product ownership aspect? What are the core capabilities that we need to keep funded long term?
The next design element is capacity. The traditional model segregates planning, development, testing and operations into different teams and organizations. This model has its merits, but today businesses are technology driven. As ING’s CEO puts it, “he wants ING to be seen as a tech company with a banking license.” Therefore, planning for capacity that integrates and aligns well with outcome-based effort rather than activity-based work becomes critical. Capacity planning also feeds into budgeting which is typically done on a quarterly rolling basis. The key element for the squad capacity design comes from business and IT (both in terms of demand and issues), creating long term themes (spanning over a year) and short-term epics (spanning a year or less). This is the key differentiator for enterprise IT as it still has to think about enterprise compliance and standardization.
Team Placement is the third design element for large enterprises that have global internal and outsourced teams. Much ink has been spilled on this topic with Dean Leffingwell's Scaling Software Agility: Best Practices for Large Enterprises classic leading to the incorporation of these ideas into SAFe & LeSS framework and multiple working point of views across enterprises. The fundamentals are the same and the below graphic highlights Mindtree's framework for distributing team effort based off the same. We call it Global Agile Teams for Enterprise (GATE), where we design the teams' placement according to interactions with business stakeholders. Our model proposes 20% of the product team effort be located close to the business, helping improve responsiveness and ensuring IT team's context alignment with business needs. The rest of the effort focusing on core engineering and support work that could be 3-4 time zone away.
Figure 1: Mindtree Framework for Distributing Team Effort
The final design element to consider while organizing for Product IT operating model is metrics and measurement. This model proposes to focus on business outcomes. This calls for a shift, especially for enterprises that have traditionally focused on effort and schedule therefore tracking activity metrics. The product teams run on the ethos of “working software is the primary measure of progress” and “you build it, you run it.” and therefore definition of what constitutes a successful business outcome is necessary before the teams can take responsibility for it.
Based on my experience of working with our clients that are at an advanced stage of the team transformation journey, the effort is delivering results. Some of the other major enablers in these successful journeys are softer yet critical elements that were embraced early on, such as organizational change management, creation of product owner dojos and agile coaches academy – all of which bring business stakeholders and IT practitioners on to the same playing field.