Agile, don't go comparing to waterfalls

Today’s article is a little different! I recorded a video for LinkedIn this week attempting to define Agile without comparing it to waterfall. Today’s article is the transcript from that video (edited a little for readability!)

You can check out the video on LinkedIn here.

Last week on LinkedIn, I put a bit of a question out to the Agile community, all the people that think and talk and produce thought leadership about Agile.

And I asked, why does Agile always explain itself or define itself in contrast to waterfall?

Sure, maybe that made sense 20 years ago when we first had the Agile manifesto and we evolved Scrum and all that stuff.

But does it really make sense today when a lot of people maybe haven't even worked in a PMBOK project, waterfall style project before? And many people have probably actually worked in some an Agile context, maybe without any training.

Fair enough, I can ask the question, but it wouldn't really be fair if I didn't have a go at explaining Agile without comparing and contrasting it to add to waterfall.

What you can see here on the whiteboard is my attempt at defining Agile from first principles rather than in contrast to any other way that you might organise a project or organise work.

So here we go.

A method of organising a team's work based on incremental iterative solution building and evaluating that work on customer need or enabling plans to be easily adapted based on changing conditions.

So there's a few things in there that I think are key. And if you're missing those elements, either in the nature of your work you're doing or in the way that you've implemented Agile or your work management system, then you're probably not doing what I think of as agility.

And I'm talking here mainly along the lines of what's been defined as business agility. My experience isn't primarily in software development where Agile was first developed and designed for. And the Agile Manifesto talks all the time about building working software.

But mine definition is for situations where we're taking those concepts that were developed for software engineering and applying them to other kinds of work.

So let’s look at the key phrases within my definition.

It's a method of organizing. Agile doesn't get the work done. It organizes how we approach that work.

And it’s for a team. You can probably use something like Kanban board for your own personal work management. But business agility, as I've seen it out there in the wild, is predominantly for Teams.

And obviously work. There needs to be some work happening. So I think those are probably the basics.

And I think the important thing is that there's lots of methods that can be used to organize a team's work. Waterfall is just one of them. Agile is just one of them.

Next, Agile is based on incremental iterative solution building.

So sometimes maybe I've seen these words used interchangeably, and I don't think that's really accurate.

Incremental is breaking your work down into blocks or steps so that you do a part at a time.

Iterative means that you build a full solution in the sense that it meets the customer's job to be done, but the solution can actually be an approved one. So in your first instance, you build a skateboard. In your second instance, you build a scooter, motorbike, car, etc. If the customer's job is getting from A to B.

So iterative is the idea of your meeting the customer's need fully, but in a less than optimal way. And then you're adding to that to make it more and more optimal.

Agile is about solution building.

So this is why I don't think agility in its purest form really works for things like service desks and those type of environments where you're not building something, but you're responding to problems and there's no releasable increment or solution that comes out of the work that's done.

Agile has a particular way of evaluating. Not only is Agile a method of organizing the work, but also evaluating the quality of the work and how well it achieves what we're trying to do based on customer need.

Customer centricity is a really critical part of Agile frameworks, one that I think is often missed in many of the implementations that I've seen.

And so you need to be evaluating your work based on your customer's thoughts and opinions, not your internal thoughts and opinions or your internal KPIs and metrics alone.

Some of those might be measuring customer, but the focus really needs to be on customer needs.

Remembering your customer doesn't need to be someone external. If you're a finance department, if you're an internal technology department, your customers are your colleagues in the operational areas of the business.

Then next up, plans being easily adapted. I think this is the main benefit that we're trying to get to when we choose an agile approach is the ability to adapt to changing conditions.

Things are constantly moving. We can't be certain that what we decide on today is going to meet the conditions that we'll experience in the future. And that's why we take an agile approach because it's designed to make how we've planned our work adaptable in response to those changing conditions.

So if you don't need adaptability, which I seldom will project teams say they don't need adaptability.

But more importantly, if your conditions aren't changing. For example, if your customers have a very stable need. Or this also can be the case in maybe a business to business setting where it's really clear what the requirements for your product is.

Or it might be where something is buffering the change in conditions effectively or ineffectively.

So this might be where an executive has decided this is what this team is producing, and we're actually not going to change that. For the purposes of your team, the environment isn't changing.

For example, doing work to remediate a cyber security risk assessment. Your executive may decide these are the order findings that we're going to address and we're going to address them by implementing these things, updating this policy, putting in two factor authentication, whatever it might be.

And things may change around you. Things may change within the business. But the executives actually decided that's the outcome that we need by X date.

So you don't actually have changing conditions. And then you might want to think about is Agile actually the best way to approach this because we don't actually need to adapt our plans to changing conditions.

We might need to adapt it to other things like changing capacity on our team. And that's where maybe the adapter can function independent of the changing conditions.

Anyway, I'm getting really deep and nerdy on this.

So this is my attempt at defining Agile without contrasting it to waterfall.

I know I mentioned waterfall in my explanation, but I think this here captures a lot of what we're trying to achieve when we implement business agility.

I'd love to hear your thoughts either here or on LinkedIn.