I have been reading a lot of articles lately about whether Agile actually works, or whether it’s simply a dream for businesses looking to accelerate business outcomes. Ultimately, the growing view seems to be that Agile doesn’t work – that it is a hype that consulting firms are thriving on, and we’re actually better off going to traditional delivery methods that provide predictability, consistency and the ability to hold someone accountable to get things done.
This debate stems from a need to find the ‘magic answer’ – the silver bullet to take all of our worries away, especially when we are looking to transform. We like Waterfall because we can allocate responsibility to someone else, whereas Agile requires us to get more involved through evolving design, constant prioritisation, showcase presentation, and ultimately owning the outcome (scary stuff). Waterfall means I can document everything I want and then point to someone else to deliver the outcomes. Any delays, errors or increased costs are totally on them, right? (ahem). However, with Waterfall delivery we tend to forget the wonderful concept of change request, where it tends to have a growing number of change requests over time, and then finishes with a resignation of taking what can be delivered with the remaining budget. Now, some might say that if you plan things right you don’t need change requests, but in today’s era of constant change, avoiding it is challenging, to say the least. Historically, in a market where market change was measured in years and for the most part manual (or at best, half yearly) the scale of change was manageable, today however, we are faced with two types of businesses: those that were born digital and those that aspire to become digital. In this dynamic, the extent and scale of change is huge and the challenges this brings to Waterfall delivery means we constantly ask for changes to our delivery plans to evolve with the market.
On the other hand, Agile provides a degree of unpredictability and tends to shift directions based on the priorities set by the business and, more specifically, the product owner themselves. The timing of when a specific capability is completed can be a little vague, as the definition of ‘done’ comes down to when the product owner is actually happy with the capability, and whether they feel it’s fit for purpose. While there can be a desire to go fast with Agile, the concept of minimum viable is always in the eyes of the product owner and thus velocity is determined by the business. For those looking to test in-market quickly, you could achieve a faster launch, but with the knowledge that there might be errors or adjustments to make ongoing. For others who like a capability to be holistic and low risk, it can mean numerous sprints are necessary before it is deemed “done” and as such ready to share with colleagues and / or customers.
I am not going to say that Agile is faster or cheaper – in fact, it can be more ambiguous, frustrating, and lack accountability, which ultimately means there’s no one to point the finger at in pushing toward an outcome. However, this is also why I believe Agile is our future.
Agile represents the cultural change a business needs to go through. We need to be comfortable with a degree of ambiguity and we need to share ownership of the outcome. One aspect that Agile does outperform Waterfall on is the ability to learn faster – and if a business is willing to learn through quick tests and recognises that early failures ensure a program is on the right track overall, then Agile can be a great vehicle to achieve business outcomes. My concern is that Agile has been branded in the tech market as a vehicle to move faster, which means the expectations are wrong from the get-go. Agile will help you learn faster and pivot as the needs of the business evolve or the market drives change, which can create a sense of speed, however it is simply an ingredient in the recipe for broader business agility.
The challenge we keep facing is that our world is not the stable working environment it was before. The predictability of having a three-year outlook that could merely be followed through with minimal disruption is rapidly diminishing, with software that felt more like hardware because it was very much standalone and constant. Today, change doesn’t happen in a two or three-year cycle; it’s happening in months and, if you are really unlucky, in weeks. This is why Waterfall is struggling, as the changes we need to make means we would need to constantly raise change requests and our costs keep going up.
This doesn’t mean I have suddenly prescribed to Agile as being the answer to everything, but it’s about knowing what has the right outcome for your business. If you are doing a migration to the cloud of premise-based applications with fixed scope and deliverables, then Waterfall is likely a better path. On the other hand if you’re developing capability that you know will continue to evolve, then Agile can actually help drive a better outcome.
So, to answer the question in the headline of this article, Agile can appear fragile because it means accepting that we are all accountable for its success. When we struggle to accept ambiguity, the need to change the way we work, or accept joint accountability in partnership of realising outcomes, we make the process fragile.
All of this is simply leading to one key reason - We are the reason why Agile is fragile. We don’t like change, we don’t like being responsible for things which in a traditional IT world was always the ownership of others. In fact, I remember my first project with Agile ways of working, I was constantly asking the delivery partner if this is going to work. My big realisation was when one of the team leads from the delivery partner turned to me and asked me back, “I don’t know, you tell me.” After my heart skipped a couple of beats, I realised this was the difference, and what I didn’t like was that there wasn’t the same clarity that I felt I had before. On the other hand, following our initial delivery, I realised it was that constant ability to keep improving, evolving our tools and external facing systems that was giving us the ability to continue to evolve.
I look at Agile as being a reminder that the business needs to take accountability for the delivery of projects. The time of simply pushing the problem to someone else is over. The introduction of Agile has added another tool to our bag to support our business in become increasingly digital. In doing this, we can enable the business to be less fragile and more adaptable, innovative, disruptive, and, well, agile.
