Still on 'is Agile dead': further insights and some guidance
My take on the "Is Agle dead?" (or if you want to reframe it: "where-is-agile-going") debate has been briefly presented in my previous post. That was a gist version. And since it did generate a couple of interesting interactions, I thought of further elaborating on it.
Now focusing on further insights into the external pressures that led us where we are, what kind of observations corroborate my view of the ongoing phase-shift, and what it might mean for people still operating as a team-oriented agilist (hopefully serving as some practical guidance).
I believe this can be useful because precisely the kinds of interactions I have had based on my take gave insight on a twofold manner:
A feeling of being somewhat stuck because operating at a team level as an agilist has been someone's focus. How to deal with the added complexity of the changing circumstances?
Examples of transitioning beyond having a dedicated agilist at the team level, which turned out to simplify things although at some cost of the team having to take on some overhead.
By the way, the second pattern was something I experienced first-hand quite some time ago. At a time I was leading a cross-functional unit primarily focused on software engineering, I used to have a Scrum Master, who all of sudden decided to leave. After consulting with others in my management team, we decided to repurpose the backfill with a different profile, as we suspected that having a fully dedicated agilist at the team level had reached diminished returns.
My personal experience was a gentle transition. But I have heard of much more abrupt approaches being taken by organizations (e.g., getting completely rid of the "Agile team"). In a challenging macroeconomic context, organizations might feel like having to face some hard choices in terms of personnel. Roles that might be fundamentally seen as an overhead (non-directly adding value to products or services) tend to be the first to be scrutinized.
Add to that the promise that if the agilists have done so far their work sufficiently well, at least there should be something left that the (tech/product) teams can just continue building on, without having the specialty in a separate dedicated role within a team, then you are into a reasonable choice (to rid or drastically reduce the number of agilists) – e.g., this was famously the reasoning used by the massive layoff of the Agile team by the US bank Capital One.
And that is what I described in the original post as the phase-shift: from dedicated roles to just an expected skill that teams should have.
So, with all that context and corroborating insights, what someone currently focused on being an agilist within a team and feeling somewhat stuck could do? How to sort of pivot and de-risk the current likely fragile situation?
Here are a few thoughts from me (that hopefully can serve as both insight as well as guidance):
Look at ways to "de-fragilize" your position by going beyond the fragile team-level focus. Teams are fragile, services are robust. I mean 'service' in a couple of different ways: (1) you provide a service that's largely applicable in different contexts and regardless of the level of managing work; (2) you find out what is the 'system of delivery' that your team contributes to, that's linked to a product or service offering of the organization, and define that as where you want to influence the improvement of flow of delivery, at the broader level of what matters from a customer standpoint (instead of the team focus only).
Speaking about flow, learn (in case you don't have that knowledge yet) and make use of flow and related metrics as a way to enable efficacy. That implies that it only matters when focusing on the level of work items that do represent delivery at the hand of customers (every deliverable is both a liability but also an opportunity to unlock value; for as long as it is not at the hand of customers, it's only the former).
But flow is just the practical mechanism, while we are really after is creating focus and hopefully with bigger leverage (beyond team level). Ask yourself: how can I help to create more clarity for the organization of the impact of having so much in flight in parallel and perhaps get buy-in to do something about fixing that? So to focus on getting further on fewer things (those that matter most).
There's probably more I could say, but that's already a good starting point. In fact can already be quite a lot, in terms of setting yourself into a journey that, in my humble opinion, should have a bigger chance to stand out (from the masses of team-level focused agilists). That's about what it takes to start paving the way towards a more strategically influencing agile, which is still pretty much the gap that has never truly been filled (despite so many attempts of "scaled agile" processes), and is the part that I still believe will be worth a specialization (as opposed to a taken for granted skill teams should already have).
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.