Hello hello,

Good morning from beautiful Poland. Yep from Poland; My fiance and I travelled 20 hours from London to Bystrzyca Kłodzka. 

I still can't believe it when I hear some people saying they don't like remote work! I probably should dedicate an article to remote working and how to make it work. I've started working remotely way before lockdown and way before it gets inflicted on people.

Anyway, that's not our topic for today. You probably guessed it from the title :)

Today is about Agile!

You've probably heard a lot about Agile. It's a word that gets thrown around all the time. A lot of times it's used to shut people up. A lot of other times it's used to disguise a lack of any knowledge of what's going on in a company or a project. Many other times it's used because well everyone else is using the term and we just want to be like everyone else. The problem though, I really believe not many understand what true agility is, why it's needed, and how it's truly achieved.

At this point, I'd very much like to start writing about my story and experiences with Agile. At least to establish some credibility, to show you I really know what I'm talking about. 

I basically started studying the topic more than 8 years ago. I have introduced it to companies and projects. I have helped teams embrace it. I've seen teams greatly fail to do it and completely misunderstand it. As well as amazing teams succeeding and doing it really well.

I could dedicate this post to that, but I will actually leave it for another day.

If you've read my previous post Professional Scrum Master - Some thoughts, you might remember me saying I'd be writing a jargon-free article explaining what Agile is and what really is about. 

So here it is; put your seat belts on!

Agile - Back to the basics

Wait! Agile, agile, but what is Agile?!

Agile is very simply an approach taken to develop software and to manage software development projects.

But what is it exactly? Why do we need it? Where did it come from?

Well, these are all important questions we need to ask if we want to get a real understanding.

Step back for now. Forget about Agile

Let's go back to square one. Forget about Agile for a bit. Imagine it doesn't exist; you've never heard the word before.

Let's talk about projects in general. Let's talk about project management. How do you usually start a project and what are the different stages one usually goes through to get a project to completion?

Remember we're taking a step back for now, so it doesn't necessarily have to be a software project.

Let's build a house

Let's say you or I want to build a house. You want to build your own house!

How would it look like? You probably already have an idea of how you'd like it and how you'd want it to be. The kitchen, for example, you might want an open plan kitchen. If you're like me, you probably want something really slick and modern. Maybe you're the complete opposite and want something more traditional?

Well whatever your taste is, you have a big chance of knowing what you want.

What about your budget? You surely must have some budget you need to stay within. Well, guess what? That's fine we can build you a house to your liking and that's within your budget. It's usually sort of easy to estimate costs, right? It's not too hard to know the cost of materials and the cost of building with different materials.

So now what? Let's start our project. Let's build our house.

We can hire an architect. They'll gather our requirements.

Requirements being gathered, we can now start planning. Our architect can start drawing some plans. The good thing about those plans is that they're very clear. Once we agree with the architect on the plans, we now know what to expect. The kitchen will be 4x5 meters. We have a duplex. En suite for the parents, and the bathroom has an Italian shower.

That's fabulous, that's getting so exciting. We haven't started building the house and we already know exactly how it will look like. We know exactly what it should cost us. The architect showed us all the plans, he even showed us in 3d!

Requirements: Done.

Plans: Done.

Now we can start building that beautiful house! We can start with the concrete, putting things in concrete.

This is how projects are usually undertaken.

We decide what we want → gather requirements → plan → then implement and bring to completion.

If everything goes well by the end of the process, we should have something that looks like what was initially agreed on. When our project is done, if no one messed at doing their job, we should get what we were expecting. In the end, we shouldn't have any surprises. Obviously, there could be some mistakes here and there, but these can usually be fixed. What's for sure is that our duplex is a duplex, and the open plan is an open plan, there's an arch, and the dimensions are correct...

Now let's build a bridge

Well, we're not going to go through the bridge-building process. It's mainly just to show the similarities with how we previously built our house.

We know what we want; a bridge from point A to point B and there's a river in between.

What are the requirements? What's the maximum weight or load to be supported? Some more questions to understand how that bridge will look like, and hopefully, we should be ready to start planning.

Here comes our civil engineer. He makes plans, he makes some analysis. He does his calculations, he follows a set of rules/theories/laws and that's it. Not saying it's easy, but this is engineering! It's following rules and designing according to those rules.

Requirements: Done.

Plans: Done.

Now we can start building our bridge.

Do you see the similarities with the process of building a house?

Hopefully, you get the gist of it.

We always start from an initial stage where we agree exactly on what we want. 

We always end up having what we exactly agreed on.

Now let's try to build software

Let's try to build software the same way and following the same approach.

What were our steps again? 

Gathering requirements → Making plans/designs → Implementing

Obviously, we forgot to mention earlier that when it's all done we probably would have wanted to verify the result. Isn't it? That sort of goes without saying; I hope you didn't build your house to end up not even checking on how it came to be.

Also over the years, we'll need to keep maintaining it if we want to keep it in a good state.

So here are all our steps:

We go through them one by one, and we'll hopefully have a working piece of software at the end.

Well done. You've just learned about Waterfall!

If you've been following all along, well done!

You now have an idea of what it takes to build software. You have an idea of how to build it the traditional way.

This traditional way of building software is what we refer to as the Waterfall Model.

If you have another look at the above picture, I believe it's quite easy to understand why it's called the Waterfall Model. It actually looks like a waterfall and it keeps going downwards as we go from one step to the next one.

But software is not a house and Waterfall doesn't work!

Well, all great so far but guess what! I have bad news for you.

Unfortunately, the nature of software projects is very different to other types of projects.

Waterfall doesn't really work well for software projects. It is not the best approach and is not well suited for software development projects.

Don't get me wrong, it still can be useful for some types of software development projects. It still is used for some smaller-scale software projects. There's nothing wrong to follow it when and if it makes sense in certain situations. 

But for the majority of software projects, Waterfall will usually be a bad idea.

It has been used for decades and software leaders came to that understanding after many software failures...

I would actually suggest you google about the biggest software failures in history. It's quite funny, and scary at the same time, to see how many software projects fail!

Small/Medium/Big software projects fail all the time. Some cost millions, some cost billions! Some take many many years of work.

One of the biggest software failures ever is the Ariane 5 Flight 501. For those who didn't know, Ariane 5 had failed and exploded only 37 seconds after its launch and that was due to a software failure.

Why is Waterfall bad? What's a better alternative?

That is probably one of the most important questions in this whole post.

Why do software projects fail and why is Waterfall a bad idea?

• People rarely know what they want when it comes to building software
• Even if they know, there are high chances it's an illusion and they just think they know!
• Software Engineering is not really engineering! Yes, there are best practices to follow etc but there are no set rules to follow. Writing software is more like an art. Writing software is like poetry. Writing software is a craft.
• There's so much that goes behind the scenes. What might look like a simple form on a screen, might involve so much that non-technical people cannot see and cannot understand.
• For example, it's easier for a non-architect to understand what his future house is going to look like.
• People who want to build software will change their minds a lot! It's almost impossible to agree from the beginning on all aspects of the software and on all requirements.
• Requirements will change.
• Software needs to evolve. Facebook as you know it today is so far from what it looked back in 2008. Your house will usually remain the same.
• It is much harder to follow and stick to a plan when building software. New technologies emerge all the time, older ones become obsolete. What cannot be done today might be doable tomorrow and vice versa.
• And so much more... This is just to quickly list of few reasons as to why Waterfall doesn't really work.

The following image sums us pretty much the funny reality of many software projects:

What's the alternative you asked?

If you've got that far in your reading, I salute you, my friend! I thank you as well for keeping up and following with me.

That being said, I think we better keep the answer to a later discussion.

Ok here's a hint: Agile🙊 Following Agile methodologies is a better alternative.

At least we know why Agile is needed

For now, at least you understand why Agile is needed. It's needed as an alternative to traditional ways of managing software projects. Traditional management methods don't work for software projects.

Next time we'll try to focus more on Agile and understand what it is exactly, how it's different, and how it can be done.

And as always my friends, until next time! 😉

✌