The agile CoE is about to die

Update March 2023: Also see a follow-up post to this one here , titled "How to transform the agile CoE"

Capital One, a big fintech player, announced the elimination of its agile job family in January. Over a thousand people, lots of agile coaches and program managers among them, lost their jobs. This is essentially the agile CoE, as it is known in countless other large organizations.

Is the agile CoE under threat in 2023 and beyond? I’m afraid so. Capital One might just be the tip of the iceberg.

Misconceived from the outset

I’ve been saying since 2015 that an agile CoE is an anti-pattern. It is an example of an activity-oriented organization. Agile CoEs focus on process compliance, not outcomes. Although they never had a mandate to influence business outcomes, they don’t do enough even with respect to digital delivery outcomes. At best, they try to improve metrics such as delivery velocity, say-do ratios, and defect density—never mind that the first two are questionable goals.

Besides, agile CoEs usually lack the technical expertise to help engineering teams actually engineer and release software better. No wonder that they limit themselves to what they know, which is to facilitate delivery planning and review meetings and retrospectives, and to organize work in a delivery tracking tool and generate reports. What’s transformational about that?

Transformation without Performance Improvement?

A transformation of ways of working must be with a view to improving performance in the large, not just in terms of sprint velocity or other low-level metric. Hardly any agile CoEs track improvements even to delivery lead times (not cycle time) — never mind tracking product or business metrics. It’s because they only concern themselves with the planning and execution of the development sprint, not with what happens after the sprint. Large organizations typically have separate release management teams to deal with the output of a sprint. They might also have a “DevOps” team to help with build and release automation. Therefore the agile CoE is typically not responsible for metrics such as change lead time, change failure rate, or mean time to recovery.

In other words, the agile CoE has had a highly limited transformation remit. It is destined to be retired during recessionary times.

How does that help?

Is disbanding the agile CoE the answer though? How’s that going to help improve performance? Shouldn’t we reform it rather than retire it? Perhaps so, but in the absence of a credible plan to reform it, it is tempting to retire it, especially when times are tough.

Capital One’s official communication on the layoffs said:

The Agile role in our Tech organization was critical to our earlier transformation phases but as our organization matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices.

Read into it what you will.

A sympathetic reading is that the agile CoE did very well to deliver on the transformation. They helped the engineering teams become self-reliant with respect to agile delivery and made themselves redundant in the process.

A more realistic reading is that the results were mixed but it's time to cut where possible.

Transformation vs. Continuous Improvement

Another way to understand the retirement of an agile CoE is to see it as a transition from transformation to continuous improvement. In theory, the latter could be driven closer to the action (inline with delivery) while the former could allow for some orchestration or facilitation out-of-band, as with a CoE. In practice, even continuous improvement needs support from other specialists, especially when it is data-informed . But that’s a topic for another day.

Seen this way, perhaps Capital One is no longer in transformation-mode. A transformation is a step change, it is discontinuous improvement. You might need some extra headcount to power it. After a while, if the leaders think that the change is self-sustaining, what do they do with the extra headcount?

The usual options are to redeploy or retrench. Agile CoE folks are often process specialists — they aren’t readily reassignable to core delivery roles in product or engineering, not that there’s always open positions over there. And in recessionary times, there is no budget to retrain and redeploy.

How not to Die

Leaders of agile CoEs would do well to take note. Think about how you can take responsibility for a metric that matters to the business. Delivery lead time is one such metric. It is the time from when a piece of functionality is ready to be taken up for delivery to the time it is live in production. You might have to work across product, engineering, QA, release management, and operations to achieve it. You might have to make the case for an expanded remit to get the others to collaborate. You might need more technical and data analysis capabilities to execute on your new remit. And you might just prevent your org from being an easy target for layoffs in the process.

Until next time, take care and prosper.

Sriram

agileorgdesign.com

Newsletter Home