Agile: to be or not to be (a very opinionated take)

Imagine two teams: one (team A) is doing the typical two-week sprints; the other (team B) indicates they do eight-week sprints (that's at least how they call their cycles). Which one is more "agile"?

I guess, on its face, you would be inclined to say the former. But you know better and decide to further dig into it. And you learn two interesting insights, a bit counterintuitive in fact:

• Team A will rarely put something live after (or even during) a sprint. Their actual cadence for going live is closer to quarterly. Best-case scenario monthly.

• Team B will in fact put things live quite often, potentially within each given week, as they take their eight-week planning cycles (which they mostly use to give some slightly longer visibility to stakeholders) and detail out what they are going to focus on each week.

Which looks more "agile" now? I hate to say it, but if it is with a capital A, like in an "Agile industry" sense, many would stick to the surface and their team-centric views and could still insist on something different from what their eyes are seeing… Unfortunately.

This all can get considerably worse once we take a broader, true end-to-end perspective. You might be surprised to learn that the whole process will often look more like this:

Having that understanding has led me through a process where I am now very conscious of when I use the word "agile", or even if I should still use it at all. Yes, I still do it occasionally, but it's mostly driven by having a common language that, in context, will resonate with people.

Additionally, the realization also comes from the fact that knowledge does evolve. And in that sense, there's not necessarily a good enough reason to stick to the whole "Agile" thing wholesale. The principles are alright, no one would reasonably question what is in the manifesto. But again, things have evolved since then, and not in ways that are so well captured there.

In that sense, I do like a recent framing I learned from Jurgen Appelo. If we put it in a kind of chronology, one could make the argument that this is how software development has evolved across time:

That is to say, "Agile" emerged mostly in the context of software projects, and then we eventually understood that it should be treated as a product for as long as ongoing needs were still there. And now we realize that this is primarily about creating an experience, rather than necessarily being too tight on how to define the boundaries of what the product is about.

Put in other, perhaps better words, software is a means to an end, and that end we now recognize as being to deliver a service, an experience, which is done in the context of identifying ongoing needs, which we can frame as products, and whose development, hopefully, is truly done with adaptability and nimbleness, or agility.

In all that process and context, I still believe and live up to, the principle that there's due importance to "how" we go about that. In that sense, there truly is such a thing as a better way, or process, to achieve certain outcomes. And if that is what you have in mind when you say you are aiming for "agile" (let's keep it to small 'a' though…), so be it. I can live with it. But I'm afraid that is not what is commonly seen after you only scratch the surface, and you can only see "Agile" ("the industry"), with its focus on team-level deliveries and ways of working. So not from the right angle of what truly matters, which is whether the customer experience, end-to-end, is good enough.

It's not about "throwing the baby out with the bath water", so to speak, as I even made a case for one aspect of embracing an "and/both" perspective (instead of "either/or") literally in my last week's post. But it's a matter of focus and how to channel all of that, keeping the right perspective in mind, oriented towards the customer experience, and taking an end-to-end view on how you go about it from idea to product (value). And how easily you can adapt things along the way as you learn more as well.

To put it bluntly, unless we are talking "agility" from that angle (focused on customer experience, taking an end-to-end perspective), then I might as well be "done" with it. And don't get me started on the pseudo-solutions to scale towards so-called "business agility" either.

P.S.: I warned from the title that it would be very opinionated. Hopefully it mostly makes sense; if not, and as usual, I am open to hearing anyone else's thoughts, even if they diverge from my own.

By Rodrigo Sperb, feel free to connect (I only refuse invites from people clearly with an agenda to ‘coldly’ sell something to me), happy to engage and interact