Are we done with Agile?
A quick review of Agile up to this point
Although it has it’s roots dating back to the early 20th century, depending on how far back you want to go, for the purposes of this blog we’re considering the ‘birth’ of Agile to be 2001 when the Manifesto was created and popularised. Throughout the Agile era there has been an incredible amount of theory and subsequent application of new-age practices that, at the end of the day, serve to better connect organisations to their customers through rapid inspection and improvement.
That previous statement is a mouthful in itself, however, as the continuing debate of what is considered Agile and what isn’t seems to have spun up a swathe of controversy both inside and outside the practicing community. Even beyond this, Agile has seen it’s fair share of critisism as adopters find the most popular frameworks and methodologies out there aren’t necessarily the silver bullet to solve all their problems. We now have the rise of the ‘anti’-framework community, which raises a whole host of new questions we now need to answer.
More and more we’re finding out that the notion of managing complexity is a constant battle, and the context surrounding an organisation mandates a high degree of tailoring to achieve a ‘fit-for-purpose’ system, something few have dared to claim victory towards. So in the spirit of continuous improvement, of inspection and adaption, of the pursuit towards customer fulfilment, what should we do not just with the application of Agile, but with Agile itself? Do we continue to forge down the same path? Do we change the purpose of Agile, or do we drop it altogether and start from scratch?
Option 1: Pause Agile, and create a new way of thinking
You might have noticed I was particularly vague in the introduction about putting labels on what Agile is, and that choice has been very deliberate. That’s because what initially started out as a pitch (of sorts) to shift the mindset and practices between software developers has since expanded to be an all-encompassing vortex of anything even remotely related to the way a company conducts its business. Agile now goes beyond software development to cover any service provided, both internal and external. It covers more than a simple mindset shift, and now has become ingrained in the way entire organisational cultures are defined. Hell, one of the key learnings in the pursuit of scaling agile across multiple teams is that if one part of the organisation wants to do it, the whole organisation must follow suit, or we will never reap the full benefits.
In short, it’s become increasingly difficult to say when we aren’t Agile, to the point where you could theoretically claim the Waterfall process, it’s arch rival, can fall under the same umbrella if you want to get down to technicalities.
To use business terminology, this creates a terrible user experience, and the inertia of the market’s adoption towards Agile makes it equally frustrating to grant some kind of global repreive. One where we take a step back and reflect on what we’re truly trying to achieve in the first place. If we want to change, we have to come prepared with an alternative that has been pre-tested and works right out the gate.
Ultimately, this is where the difficulty in ‘dropping’ Agile has left us. We can’t simply start fresh without creating something that has already been in practice for longer than we needed it (aka the ‘developer interview’ paradox).
We also somehow need to fence off the ever-evolving scope of Agile so we can solve the issue of distinction; this is what Agile is, and this is what the alternative does differently. But maybe focusing on this problem in isolation could yield us some benefits.
Option 2: Pivot the concept of Agile towards a new path
Rather than creating an entirely new product (for lack of a better term), we could instead focus on fixing what already exists. This could take us in a few different directions, depending on what we want to focus on. For example, we could try the following:
- Fix the disconnect between making software delivery Agile, and the rest of the company Agile. Focus on one of these, and refine (or recreate) practices based on that scope
- Fix the disconnect between delivery and product. Again, we can focus more on unifying these two aspects that yield customer satisfaction, or focus entirely on the latter (seriously, how much product-centric frameworks or methodologies are out there?)
- Fix the disconnect between the business and the customer. Most Agile frameworks to-date focus on getting a product out the door and into the market, but the bottom half of the customer feedback loop is still yet to be really explored
The three ideas above are a significant shift away from the current path Agile seems to be taking; an ambiguous movement, with roots in software delivery, that tries to maximise the number of feedback opportunities from the customer. When you think about it, this has always been a fairly close-ended premise when you consider how many other aspects of running a business, even one based in software development, needs to succeed.
But even though this path means less volatility and effort on the behalf of the Agile community to fully realise, there is still one glaring gap that we’ve yet to explore. Have we even properly proved the current state of Agile is flawed to begin with?
Option 3: Persevere with Agile and stay the course
As we continue the trajectory towards coming full circle, we must finally explore the third and final option for evolving the way we work, and that’s essentially to double-down on everything we’re currently doing with regards to Agile thought leadership. We allow Agile to be the all-encompassing, ever-expanding beast we’ve come to know and understand, but make one small change to focus our efforts on measuring the success of Agile in it’s current form. Namely, as a starting point we should aim to quantify the following proof points we signed up for:
- Are we maximising the number of possible opportunities we have to learn about our customer?
- Are we using these opportunities to learn about our customers’ evolving patterns, problems and needs?
- Are we taking these customer traits and developing products and services to satisfy these gaps?
I find these questions to be especially powerful in my day-to-day as a kickstarter to some healthy debate and conversations, but there’s one small caveat here; these three statements are really hard to measure. The degree of subjectivity, ambiguity and overall uncertainty in these fields means that we would need to make some broad generalisations and assumptions before we can gain any meaningful empricial view across the Agile landscape. That’s not for want of trying, however, as there are many academics following this pursuit in particular (and the outlook is mixed).
In closing
So we’re left at a crossroads with the path we need to take. Hopefully in reading this opinion piece, if nothing else, you now have the courage to take a good hard look at the state of Agile, and what it means for your environment. Whether you want to change the notion of adaption itself, redefine the increasingly ambiguous or bravely traverse the established path you’re ultimately making a commitment that you’ll be owning for years to come.
Whatever your belief, follow and apply the principles of Agile unto itself and constantly reflect on it’s purpose and validity in a rapidly evolving world.
Check out my Dependency Mapper app for Jira!