Agile - Back to the basics (Part 3)

Hello dear readers,

I'm finally back in London after 3 weeks in Poland and 1 week in Belgium.

A month has already passed since our last 2 discussions about Agile.

If you haven't read the previous posts or need a refresher, here are the links:

Agile - Back to the basics

Agile - Back to the basics (Part 2)

In the first part, we described the process of building a house and then described building software. That helped us spot the differences between software and other types of projects. We understood why the Waterfall model doesn't usually work well for software development, and why it can be a bad idea to manage software projects linearly and sequentially. We realized we needed a better way for building software and we called it Agile.

In part 2, we focused a bit more on what Agile means. We explained how Agile takes an iterative and incremental approach rather than the linear and sequential covered in the Waterfall model. We gave an example of how we would build an ERP system following the Agile methodology and saw the benefits of doing so.

I think that's been good enough so far. That's been a good introduction. If you've read those 2 previous posts, I believe you should by now be getting the gist of how things work or should work when developing software.

Now the reason why I'm still writing this third part is mainly to introduce the Agile Manifesto. There's no way to introduce Agile methodologies without mentioning the Agile Manifesto. This, for me, constitutes the essence of what Agile is. Understanding the Agile Manifesto properly will allow you to become truly agile.

Agile Manifesto

How it all started

The Agile Manifesto is a set of principles that emerged in 2001 when a group of independent thinkers and software pioneers gathered in a ski resort for 2 days to discuss and find common grounds around how software development as a profession could be improved by new ways of thinking.

This is how the Agile Manifesto came out to be. You can read the whole Agile Manifesto history here.

What it values

The first and most important thing to understand about Agile is what to value most:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That doesn't mean that there's no value at all in the items on the right. 

Processes and tools are surely important, but individuals and how they interact is by far more important.

Comprehensive documentation is definitely still needed in many situations, but we'd rather have working software that in itself is easily understandable and self-documenting when possible over having some big piles of crap documentation that are sitting somewhere in some closet and are useful to no one. Makes me think of how many times I've read phone/computer/TV manuals; I think close to 0.

Anyway, I'm diving deep into these this time; maybe I'll leave it for some other time to give more examples and real-life scenarios.

The 12 principles

Now that we know what to value most, it's also really important to have a look at the principles behind the Agile Manifesto.

Here's a screenshot of the 12 principles as they appear on the Agile Manifesto website:

So that's it when it comes to the Agile Manifesto. I'm sure there's still so much more to cover about being agile, especially some real-life lessons and tips that I need to share.

Please let me know what you think of this third part of the "Agile - Back to the basics" series; as always in the comments section below 👇

Do you have any questions? Do you need any clarification on anything that we've already covered? Maybe even something that we haven't covered?

If yes, I'd be really happy to have some additional conversations.

For now, let me go get ready and enjoy the rest of the day in London (while maintaining social distancing).

And as always until next time!

Take it easy!

✌