When I first started software development I had no idea what Agile was. Two years in I still had no idea what it was but I kept on hearing the word pop up in talks and the importance of it was always emphasised in job descriptions. Indeed, I practiced it at my company, according to the description on our website, but no one had ever explained how what I was doing was Agile. So I decided to do some research and figure out what everyone was talking about.
The history of Agile can be directly traced back to 2001 when some software developers got together and proposed a new way of working on software projects. The problem was that initial commercial software projects were treated the same as a normal engineering project - a big plan made by 'smart' people was designed and then the 'dumb' workers would follow the plan (obviously this is a horrible way to look at it). An example of this is an architect designing a blueprint for a building and then labourers following the plan to build it. This project management practice is known as Waterfall.
Software didn't adapt well to this. Software projects, and their requirements, tend to change shape a lot more than buildings - and so our agile founding fathers drew up some principles for more suitable practices based around flexibility, feedback and adapting to changing requirements. These are enshrined in the Manifesto for Agile Software Development
Rather annoyingly for us software engineers a lot of these principles were left intentionally vague. Perhaps so they would stand the test of time or to have them apply to as broad a range of situations as possible.
The principles
A large part of the Agile manifesto's principles champion direct feedback between business people and developers. It prioritises the individuals and teams over organisations. And places working software with technical excellence as one of its goals.
So basically an Agile project is the antithesis of a bureaucratic, cumbersome project run by a committee of managers who don't listen to any feedback from customers or workers. This helps us know what agile isn't but still doesn't help us know what it is. Feedback is good but how much is too much before you get bogged down in meetings? Should you have standups? How many people before it gets too big? Should managers always consult with their teams before making any decisions? How do you actually decide what working software is? Should it matter what you think at all if the only purpose of the project is to satisfy the customer?
We still don't really have a good answer to the question of what Agile is, mainly because there isn't a good answer. Agile varies company to company, team to team. It is just some guidelines of how development can happen.
The reason Agile is so confusing is because it has been hijacked by people who have realised that they can sell the concept of Agile to companies who are looking to improve their development practices, even build careers (SCRUM Master) around it. This is a very cynical way to look at it but it also makes a lot of sense in explaining how it's used now compared to how it was intended to be used.
Perhaps there is so much confusion around Agile because people are constantly trying to change it in order to sell it to you - Are you doing Agile? That's not Agile. Let me show you how to do it in my new book.
Or maybe it's because we want to be told exactly what Agile is, and to have the gap left by the writers of the manifesto filled in. Maybe we don't want to have to struggle with the questions that it presents but would rather have someone rigorously define it for us so we don't have to think, and the problem is we can't decide who's interpretation is the most valid or we get bored of one and jump to another.
As Dave Thomas, one of the founding fathers, says we shouldn't really use the word Agile as we do. It's been turned into a noun. It was intended to be used as the verb - as in practices that are agile. As he points out, it's interesting that we now use it with a capital A, the same way we refer to God.
The sad reality
So sadly Agile has lost its intrinsic meaning over time and has become not much more than a buzzword slapped on job descriptions and websites. My advice is not to try to understand it because you'll never be able to keep up with it, or convince others of what it truly is (or more importantly isn't) because they have already formed and latched onto their own idea of it. Put that you practice it on your resume and forget about it.
Top comments (2)
Yeah I agree, I was mainly hoping to shed some light for new programmers to help demystify it. To hopefully help them understand what it is and isn’t, e.g just because you’re doing a stand up every day doesn’t necessarily mean you’re being agile. There was no one to explain it to me when I started, and I was also afraid of asking was, especially since I had supposedly been doing from the start and therefore looking like an idiot.
I love your style. You just keep it real!!!