Unpacking the basics: agile delivery.

In our “unpacking” series so far, we’ve covered the “what” (digital transformation), the “who” (change management) and the “where” (the cloud). Now, we need to talk about the “how” — how do we actually get the work done?

If you have stepped foot in a corporate office in the last decade, you have heard the word Agile. You’ve probably seen walls covered in multi-coloured Post-it notes. You might have seen teams standing around in a circle for fifteen minutes every morning — there might even have been some cheering and clapping… You may have even been told that your project needs to run in “sprints”.

Unpacking the basics: agile delivery.

But like many business buzzwords, “Agile” has been misused to the point that the original meaning is barely recognisable. Is it just a fancy word for “working faster”? Does it work in some settings and not others? Or is it actually a better way to deliver value?

Let’s unpack it.

The origins.

We need to go back to 2001, when a group of seventeen frustrated devs met at a ski resort in the US.

At the time, the industry standard for building software was miserable. It was heavy, slow and bureaucratic. You would spend months writing requirements, then months building it, then months testing it. By the time the software was released, the world had already moved on and the product was either obsolete or at great risk of being so.

The group wanted a better way, so they wrote the Agile Manifesto. It was a rebellious document that valued “individuals and interactions over processes and tools” and “responding to change over following a plan”. The point was fluidity and dynamism, something which reflected the growing speed at which the tech was facilitating development.

They were pushing for a mindset shift.

Waterfall vs agile.

To see why this shift matters, we need to compare Agile to the traditional method, known as Waterfall.

Imagine you are planning a road trip from Sydney to Perth.

Waterfall: Before you leave the driveway, you plan every single kilometre. You book every hotel for specific dates. You decide exactly where you will stop for lunch on Day 4. You print out a rigid itinerary.

The risk with this approach is that if you get a flat tyre on Day 2 or there is a fire blocking off part of the highway, your entire plan falls apart. You miss your hotel bookings. You are stressed. The plan has failed because it couldn’t handle reality.

Agile: You want to get to Perth (the goal). You start driving. At the start of each day, you check the traffic, the weather and the general state of the car. You decide on a goal for just that day. If there is a roadblock, you detour. If you find a nice town, you stay an extra night. The result is that you still get to Perth, but you adjusted your route based on real-world feedback along the way.

The pros: why do we do it.

In the business world, Agile delivery (usually broken down into two-week blocks called “Sprints”) offers various advantages which can be substantial:

• Speed to value: Instead of waiting two years to launch a perfect product, you launch a basic version (an MVP) in two months and improve it based on feedback.

• Risk reduction: If you are building the wrong thing, you find out in week two, not week fifty-two. You fail fast and cheaply.

• Adaptability: The market changes fast. Agile allows you to pivot your strategy without throwing away years of work.

In the right environment, these advantages can be substantial.

The cons: well, it’s complicated.

Why, then, do so many people roll their eyes at the mere mention of “Agile”?

For a few reasons. Firstly, Agile has become an industry of its own, with many various bells and whistles which help businesses feel like they have gone Agile. But many organisations fall into the trap of “Fake Agile” (or “Zombie Agile”). This means they adopt the framework at a high level — but not the mindset. They force teams to have daily stand-up meetings, operate in sprints, hire expensive “Scrum Masters” and use some of the jargon… yet they still demand a rigid, fixed-scope, fixed-budget plan for the next 18 months.

This is the worst of both worlds. You get all the annoying elements of Agile with all the rigidity of Waterfall.

Agile also requires a high level of trust. Because you aren’t defining the exact outcome at the start, leadership has to trust the team to find the best path. For traditional managers, this is terrifying. For employees, the friction it creates can be a major impediment to getting actual work done.

Which brings me to the next issue with Agile: to properly adopt it as a delivery framework, or at least an effective version of it, the team needs to be on board. They need to understand why the approach has been taken — and believe the reasons — so that they actually toe the line. This is where change management is crucial. And, if it’s not done properly, you’re in trouble, because Agile takes discipline. I mean that quite literally. Adopting the vocabulary, understanding how to write a ticket and keep boards updated, knowing what to raise at daily standup, and the importance of these things, is critical but not intuitive. Management needs to make Agile make sense to the people who are obligated to use it. If someone in the team stops updating cards on the Kanban board, the whole thing falls over.

Oh, and on that point, there are multiple versions of Agile — but that’s a whole other discussion.

In summary.

In the 2020s, Agile isn’t just for software developers.

HR teams use it to roll out new policies in stages rather than all at once. Marketing teams use it to test campaigns, measure the data and pivot quickly, and it works — I know, because I have personally implemented Agile in a Marketing department. Toyota famously use a version of Agile for motor vehicle production — and Spotify have their own, very successful take on it. It has evolved from a coding methodology into a general business philosophy of iterative improvement.

But Agile is not magic. It won’t fix a bad business strategy or a toxic culture.

However, in a world where customer needs change overnight and tech moves at lightspeed, rigid multi-year plans are a dangerous gamble. Agile is acknowledgement that we don’t know the future, so we should build a system that allows us to learn as we go.

In a nutshell, it’s about delivering value, getting feedback and doing it all again.

Is your organisation stuck in “Fake Agile” — going through the motions but not seeing the speed? We can help you get the work flowing again. Get in touch.