Agile — Say What?
A jargon-free explanation for non-techies
I work in tech and I’m as guilty as the next nerd when it comes to using unintelligible terminology. In this post I’m going to explain the term Agile without using any Agile-specific terms. In particular, I’m going to cover what it actually is and why you might want to learn about it in relation to software development.
What is Agile?
Essentially Agile is a way of delivering software a bit at a time.
Based on priority, tasks are tackled and completed throughout a defined period of time (usually periods of two weeks). After each chunk of two weeks the planned set of tasks for those two weeks is delivered.
You then review the work you’ve completed and plan the next two weeks.
Rinse and repeat. That’s pretty much it.
It doesn’t sound like there’s much to it: why is it such a big deal?
The reason it’s a big deal is because its simplicity belies the huge gains that working in an Agile way brings to a project.
The simple ideas behind Agile force you to work in a particular way: sticking to the process enforces working practices that really help to deliver the best product possible in an exceptionally efficient way.
Aren’t people just jumping on another bandwagon?
Agile has been around since the 1990s really.
In the VersionOne 9th Annual State of Agile survey 94% of respondents (covering a broad range of organisations in the global software development community) said their organisations were practicing Agile; with 45% working in organisations where the majority of their teams are agile.
So it’s not some new bandwagon to jump on because all the cool kids are using it.
How is Agile different?
There are loads of benefits to using Agile for delivering projects, but the big three for me are:
1. Less upfront design and technical specification
You know what projects can be like: changing requirements, shifting priorities, acts of God.
These issues raise two questions about the design, technical specification and documentation of planned work:
- Why spend all that effort and cost upfront for things that you aren’t certain you are going to build?
- Why gamble all that effort and cost on assumptions made before a project is underway; a time when you have less information available on which to base your assumptions?
In more traditional projects where you plan everything you want to build in fine detail upfront there is almost always wasted time and effort. This is wasted effort that could have created amazing value for the product if spent elsewhere. This is wasted effort that pushes back deadlines.
In Agile we specify the details of features as we go along, only going into enough detail for what we plan to build in the next two weeks. This reduces the risk of spending time writing documentation, doing design and so on for work that is no longer required. It also means that the impact of unforeseen circumstances are minimised as the timescales are so short.
2. Constant delivery and review
We get a new version of the product we are building every two weeks; there is no ‘big bang’ delivery after months of waiting.
This incremental delivery of features means that understanding of and confidence in the product is built up throughout the project. Stakeholders and the public can potentially engage with the product early.
Delivery is the aim with every digital project. Committing to doing this every two weeks massively decreases the likelihood that your project will fail.
The fact that you deliver in priority order also means that you are ticking the boxes as you go along on the most important aspects of your project, relieving pressure throughout the entire process.
3. Adaptability
The way things are put into our two-week periods of work is through a single prioritised list. This list is constantly reviewed, based on up-to-date information rather than information or assumptions from before the project began.
Delivering every two weeks means we can use the latest version of the product along with all other available information to inform what we do next. The real product steers our development.
Through user testing and other analysis we can ensure that we are always moving towards a final product that best suits our overall project goals.
Contrast this with the traditional approach of attempting to specify all our work upfront; we have so much more flexibility to adapt based on new information or changing requirements.
Implementing Agile
As mentioned above this stuff isn’t rocket science but it can be challenging to transition to an Agile way of working.
It’s a highly collaborative way of working that involves a lot of trust from everyone on the team. It’s this trust and collaboration that makes the process work and subsequently produce exceptional results.
I’ve purposely not gone into too much depth in this article; if you’d like to find out more, check out our other posts at cogapp.com/agile.
If you’d rather have a chat get in touch via http://www.cogapp.com/contact-us or through the comments below.
