Agile - Back to the basics (Part 2)

Hello hello,

Have you read Agile - Back to the basics? If not, now is a good time to read it 😉

Surprise! Today is the 2nd part. We'll continue from where we left.

Waterfall: recap

Just a quick recap first.

Last time we talked about the Waterfall model, how it can be used, and why it may usually be bad for building software.

Waterfall is a project management approach in which all requirements are gathered at the very beginning of a project. Once requirements are gathered, the project is broken down into a set of sequential stages.

Those stages are:

Gathering requirements → Designing → Implementing → Verifying / Testing → Maintaining

We mentioned those stages being sequential which means one cannot just jump from one to another randomly. Following the Waterfall model, one needs to completely finish and sign off a specific stage to go to the next one.

Here's for example how it could look like:

• Spend 2 months gathering requirements and understanding needs
• Spend 3 months designing the solution
• Spend 4 months implementing it
• Spend 3 months verifying and testing
• Maintain for as much as we like/need/can

This is very rigid. It doesn't give us much room for flexibility and adaptability.

This model takes many assumptions; the first one being our requirements will be 100% correct from the beginning.

That can be true when building a house.

It very possibly won't be true when building software.

Do you want to know why?

Because in the tech space things are moving so fast. We are competing every day against new competitors, each bringing new solutions and new ideas to the table. We can't afford to be rigid.

In the digital world, what is true today can be wrong tomorrow.

Trends change, customers change, everything changes.

Cite me one tech company or product that has existed for a decade and that is still as it was when it was first created. Exactly! You probably won't find many.

Your parents' house, on the other hand, is probably still standing the same though.

That's on one side, on another is the fact that making software changes is not always as easy as it may look! It can be very costly!

What if we've been doing work for 9 months and we just got to the verification stage, and guess what? We find a gap in what we built. Something has been designed and built not as the end-user expects it to be; what do we do now? Do we go back to the drawing board? We scrap everything we've done? Well, let's hope it's not a big big change that's needed!

For that reason, we need to be agile!

We need a better, faster, more flexible way of managing change!

We need for example to be able to find design mistakes as soon as possible. We can't afford to wait for our developers to finish building the whole product before we tell them there's a defect. Plus if we had a way to identify problems early on, then wouldn't it be better to tell our developers "Hey wait! You don't need to build that. Don't waste your time on it."? We could for example also tell them "You know that assumption that you had about how our system would integrate with that other external system? Well don't work based on that assumption, don't waste time cause it won't work". Would it not be much better for everyone? Happy life for the developers. Happy life for the investors. Happy life for everyone.

So what is Agile exactly?

Agile is a methodology used mainly for software development. With time it has proved though to be very effective in different types of projects as well.

So what's so special about Agile then?

Agile takes an iterative and incremental approach rather than a sequential approach as the one we've seen with Waterfall.

If you're comparing that to how Waterfall looked like, you might ask:

"But Jad isn't that the same as what we had before? Don't we still need to finish the design step before going to the development step? Did you just turn your waterfall into a tornado? It's now just a circle!"

Very well, that means you're still following :)

How about that then?

Are you getting the gist of it? Do you see where I'm trying to get at?

Yes, that's how the whole SDLC (Software Development Life Cycle) now looks like when doing Agile.

We now have iterations. Each one of these loops is an iteration.

At the beginning of each iteration, we gather some of our requirements. Remember we need some and not all requirements! Otherwise, we'd be doing Waterfall.

"But Jad what's the point of only making decisions on some of the needs?" you may ask.

Well, the point here is to not waste too much time taking too many decisions that may end up being wrong or that may need to be changed at some point later.

And guess what's a great advantage of doing that!

You only make decisions and work on what you know. You leave what you don't know for later!

Example:

Say we're building ERP (Enterprise Resource Planning) software for our big company to use internally.

Our software will be used for accounting, CRM (Client Relationship Management), and e-commerce just to name a few.

For the accounting part, we need some information from our accountants and from our head of accounting. We need to know for example what formats they'd expect from us; do they want their numbers in CSV format or Excel format? Not only that; we need to ask them so many more questions to understand what they really need.

Well, guess what! It's August and our accounting director is on annual leave. Want to know what's worse? He also has a 3 months sabbatical.

Oh damn does it mean we're stuck? Do we need to wait before we can start implementing? Nope, not at all. Not if we're working in iterations and producing small increments at a time.

Why? Because we don't need to gather ALL THE REQUIREMENTS and make ALL THE DECISIONS to be able to start building!

In this iteration, we can start with the e-commerce side of things 😉 

We have all that it takes to understand what needs to be built for that. We can then start building it. We can then immediately start testing it! If we find any problems, it'll hopefully be much easier for us to fix things cause we haven't spent so much time that every single change is now almost impossible. If we're really great, after deploying it, our users could have even possibly used it and passed feedback to us.

Do you get the benefits of what we're doing now?

Please let me know in the comments box below 👇 I'm really interested in knowing how easy it's been to follow so far.

Well if it's still not crystal clear and if you still have confusions as to what incremental and iterative approaches really are, and because a picture is worth a thousand words, here's one for you:

That's not enough, I want to know more about Agile!

Did you really say that? I hope you did :)

Well I know that's not enough.

What about the Agile manifesto? You might have heard of that; we need to talk about that!

What about going more into details and knowing a bit more about how to start doing Agile? I need to write about that separately.

What about the cons and challenges of Agile? Well as nice as I made it sound so far, Agile comes with its own cons and its own set of challenges. To be honest not everyone can be really 100% agile. Being completely agile is not for the faint-hearted.

Agility needs courage, agility needs openness, agility needs a will to continuously improve...

We can talk about all that later on for sure.

Please let me know if there are any specific areas of Agile that you're especially interested in. Let me know of any of the challenges you've faced or you're currently facing. Have stories about how your company embraced the modern ways of developing software? You already know, all that goes in the comments box below 👇

Even better! If you're interested in sharing a story and writing about it, please be my guest! I'd be more than happy to share your article, and guess what? You'll appear as the author of that article(s) 😏

And as always my friends, until next time ✌

Kowabunga 👊

P.S: 

Reaching true agility in software is not easy, but it's not that difficult either! It all starts by understanding some key things. 

Anyone telling you:

• You need a Scrum Master to succeed
• You need an Agile Coach
• You need to be doing Scrum. Oh, no Kanban is better!
• You need this, you need that
• You can't do it
• It worked for company X and team X that way

Don't listen to any of that crap. Don't follow the hype blindly and don't just listen to the buzzwords.

Remember the tech industry is broken and is unfortunately full of crooks.

First, find someone you can trust. Find someone who really understands software.

And if needed Beyond Scopes are here and ready to help!