Big banks and other financial institutions are still attempting wholesale Agile transformation by just hiring dozens of Agile coaches and embedding them in development teams. They are sorely mistaken if they think they can improve IT performance as perceived by the business merely by getting everyone to adopt Scrum, hard as that in itself may be.
Scrum is not enough
Scrum, even when done right, will only take you to user acceptance testing (UAT). We need DevOps and Continuous Delivery for a fast and reliable path to production. But even this only addresses the IT delivery cycle. It helps with building the thing right, not with building the right thing.
Building the right thing is an iterative process that requires full co-operation of the product management and design organization and other business stakeholders. However, when teams attempt to iterate at this level, they encounter friction on account of the organization’s structure, operational practices, politics and culture. Therefore, true transformation needs courageous executives who realize the need for systemic change, i.e. an Agile-friendly operating mode.
Product-centricity
Product-centricity is one the key aspects of an Agile-friendly operating model. This is a big change for places where enterprise IT is used to operating in project-centric mode. One component of product-centricity is the shift to outcome-oriented teams—teams that own a valuable business outcome. Which brings us to the question of what do we mean by a valuable business outcome? Isn’t every IT initiative (and the projects spawned by it) valuable? Not necessarily. For starters, the initiative may have been funded on the back of a speculative, big, up-front business case. But even when they are valuable, project teams ramp down after a release or two and do not last through the value-lifecycle of what they build.
Learn more about this topic and others in my discussion with Vinod Sankaranarayanan on the ThoughtWorks Podcast series for Tech Leaders.
Outcome-oriented teams
Outcome-oriented teams need to live as long as the outcome is relevant to the business. We call this a build-it-and-run-it team. That’s when they can own an outcome. Anything short of it is only an activity, e.g. teams that are only responsible for development, deployment, testing or UX. Outcome-oriented teams also need to have all the skills necessary to achieve the outcome without too many dependencies on other teams. They may have API dependency with other teams but that’s no different from having API dependency on third party libraries and applications.
In other words, outcome-oriented teams need to be sufficiently autonomous within the larger construct of the organization. Autonomy also helps individual motivation. KPIs, targets and incentives are old school. They are extrinsic motivators and they often have undesirable side-effects. An Agile-friendly operating model is one that deemphasizes extrinsic motivators and emphasizes intrinsic motivators like autonomy, mastery and purpose. For autonomous, outcome-oriented teams, the outcome serves as the purpose.
Defining delegatable outcomes
But what level of outcomes are we talking about here? For example, a traditional retailer’s business strategy may indicate that they are aiming for an outcome of realizing 10% of all revenue via digital channels. Clearly, we cannot form a single outcome-oriented team for this outcome. As illustrated in the figure below, we need to break it down into smaller outcomes while taking care that they continue to remain as outcomes and do not degenerate into activities. Agilists already have a technique for differentiating stories and tasks that can be adapted to correctly split outcomes into sub-outcomes and not activities.
In part 2 of this article series, we'll explore how to deal with streams of work that cut across several outcome-oriented teams and what product-centric IT means for the roles of project and program managers.
