Agile is all the rage in todays software development, but it can be really hard to get anyone to explain to you what it really is and everyone seems to have a different ideas. You may have heard words like Sprint, MVP, Product Owner, iterative and a bunch of other nonsense words.
In this post I will attempt to explain what agile is all about without going into too many process related details.
Disclaimer: I’m trying to keep this simple and may provide simple hard answers where a lot of options exist. I do this to keep it understandable and approachable, I will dive into all the options and complexities in later posts.
How did agile come about?
The traditional approach to product development is to spend a lot of time at the drawing board figuring out what to build and how to build it before finally building.
This approach comes out of construction where it makes a lot of sense; if you are going to build a bridge you better know how and where to build it before you start pouring concrete and hanging cables.
But software isn’t a bridge.
On the one hand it is often vastly more complex and vastly more brittle; there are no tolerances in software you algorithm either does what it is supposed to do or it doesn’t there is no middle ground and you can’t hedge your bets.
On the other hand it is infinitely more malleable and a cable snapping because it was designed all wrong is not going to kill anyone and the design error can be fixed without rebuilding the whole product.
So even though we borrow almost all our language from construction, software development really isn’t very much like a construction project.
Agile is the consequence of this realization, and the first serious attempt to take full advantage of the malleability of software.
So what is agile really about?
In essence agile is about taking full advantage of the unique malleability of software. We develop the product while using it instead of waiting to use it until it is done. And arguably software is never really done.
And in doing so we learn from and with our users what is really needed and so end up with a product that is far more in line with the true needs of the users.
Unlike the traditional project where you decide to build a bridge and then you go do it, agile software development takes a step back and asks what is the problem we are trying to solve.
In the case of the bridge we may be trying to solve the problem how to get people and goods across the river.
Instead of jumping straight to “bridge” we look for the simplest, cheapest and fastest solution that will improve the situation enough that people will choose to use it - this is what people are talking about when they say Minimal Viable Product or MVP for short.
And you might end up tossing a rope across the river and tying a barrel to it. Now it is possible to cross the river, it is very basic but the situation is massively better than it was yesterday.
At this point you might be saying that is silly we have just wasted time with rope when we know full well we are going to need a real bridge. This is where the malleability of software makes software development fundamentally different from construction.
The rope is a step closer to bridge in software and over time the rope can be morphed into a full blown draw bridge with bells and whistles. And not only that we will have a bridge faster than using the traditional method, it will be a better bridge better suited to the real need of the people using it, and people can cross the river from day one and every following day they will be able to cross the river a little better.
That may sound like magic, but we are not actually building bridges with software we are building abstract information management systems and building a very basic application and then adding more buttons, text fields and visualizations is not hard to imagine.
Software development is hard
In construction most of the people involved do very well defined jobs that they and others have done millions of times before. As a result you only need a few bright minds to deal with what makes the specific project unique.
Software development is a much younger industry and every attempt that has been made so far to standardize development tasks has lead to unsatisfactory outcomes.
The result is that software tends to require highly skilled people with very flexible minds but a relatively small number of them can do a lot. There is quite a few examples of individual software developers building astounding products all alone.
But individual developers of this skill level are the exception, and they tend to be - shall we say - difficult to work with.
Instead agile proposes a way of working wherein we are not simply improving the product continuously but also the workers. Just as we improve the product every day we try to make the people building it a little better in lockstep with the product improvements.
By doing this we can hire a team of affordable developers you might actually enjoy sharing a beer with and make them extremely good at building our particular product all the while making our product the best it can be.
In other words we are creating a group of specialists in building exactly our product while creating the product itself, and as the product grows in complexity our specialists grow in skill.
In Conclusion
Agile software development is a a two pronged approach to developing software in a reliable and cost-effective way.
By growing on both The Product and The Team incrementally we can manage the complexity of developing software without resorting to genius level employees and epiphanies.
We can drastically reduce time to market by releasing the product long before it is “done” and ending up with a much better product in the process.