Agile software development means different things to different people. In this post, we will define what agile software development is with a simple analogy that a five-year-old can understand. The analogy we will use is as straightforward as serving an apple to 4 kids. Yes, it will be that easy, let’s get started:
Atlassian, in their guide, defines agile as:
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments.
Wikipedia has an article on Agile software development, that says:
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.
Until now it is not understood what agile software development actually means. Have a go at it:
Agile software development means developing software in such a way that the end-user feels value is being delivered frequently in the form of working software. This surely includes having the end-users get involved in the agile software development process.
The software engineering team does not take months to write up requirements, then again months to design/architect the software. After that, the team writes the code and delivers the product to the customer. The end-user is part of the process. After the end-user gives some requirements they are able to see part of the working software rather than waiting for the whole thing to finish.
Rather than that, the team understands the most important part, gets requirements for that section, designs/architects it, builds it, and delivers usable software in weeks, not months or years. That is agile software development, in a nutshell. Don’t be agile just on paper, implement it practically.
Around 20 years back in 2001, 17 men met in Utah and wrote up this amazing manifesto as guiding principles for agile software development. There is a long backstory to the manifesto, if you are interested in it, please read it. Below are the 4 main values:
** Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan*
You can always argue how relevant these points are if you work in an agency setting where you do customer projects, not company products. At an agency, you need to come up with a contract with the cost of the project. That makes most of the above values hard to meet. Anyhow, these are the guiding principles for agile software development.
In addition to the above values, there are 12 principles of agile software. The first one being:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Then there are other principles discussing changes, delivery of software, collaboration, etc. So until now it still seems jumbled, right? This is surely not something a five-year-old can comprehend in any way. Follow on to read the over-simplified analogy.
Now let us move away a bit from agile software development and all the jargon that it entails. Allow me to introduce a very simple problem (a bit dramatized) which is a great analogy and example. The example here is to serve an apple to four hungry children.
Imagine this, you have four hungry children and one apple. You need to serve that apple to these 4 children as a snack while the main course is on its way to be delivered. All four children only eat peeled, cut, and diced apple. How can you go about this issue?
If you follow a waterfall software development, you would do the following steps:
Wash the apple you have got
After that, cut it into four similar-sized pieces (halve the apple then halve both the halves)
Peel all the four pieces of apple one by one
Cut the seed out
Dice all the four pieces of apple
Put the dices in four plates
Then you serve it to the four children
Now, notice some of the things that happened in this process:
None of the children could satisfy their hunger until step 6 was done
There was no way to give feedback about the size of the apple’s dices, you had to eat what you got
The children got served all the apple dices of their portion in one go. This may be a good or a bad thing depending on how you understand it.
Surely there was no feedback loop in this process, the children felt a bit left out.
All in all, the process looked normal. Unfortunately, software development is not as easy as serving an apple to four hungry children. So let’s have a look at how agile software development would attempt to solve the same problem.
If you had followed one of the agile software development methods, the process would look more like below:
Wash the apple
After that, cut one quarter out of the apple
Peel that cut out one-fourth part
Cut out the seed from the one-fourth part
Dice it into eight pieces
Put 2 pieces each in 4 plates
Serve the two pieces each to the four hungry children
Get feedback, go to step 2, and repeat until the apple is finished :)
Again, let us take note of the things that are better this time:
The children got served a lot faster even though it was a smaller portion of apple
They had the opportunity to say if the dice was big or small, so in the next iteration, the size could be customised following the child’s wish. This is a simple example of early user feedback.
Every iteration could be better in terms of the size of the dice if the apple was sour the children would know it faster. These are the advantages of early feedback.
Another important aspect, if the children are not hungry anymore after 4 dices, you can stop and have not wasted the whole apple.
This approach also enables a test and learn phase. You could easily give one child smaller apple dice if the child was having any issue chewing bigger pieces of apple.
On the whole, the agile software development method was more collaborative and provided more satisfaction to the four children.
It provided more satisfaction not only by serving the apple dice faster but also by letting the children have a say in the next round of dice they would receive. That is the beauty of agile software development.
You can easily draw parallels between both the processes of agile software development and serving the apple. Requirements analysis can be mapped to washing the apple.
Similarly, software design and architecture can be linked to cutting the apple. If you don’t cut the apple correctly, it will be difficult to get well-shaped dices and so forth. The same goes for software development.
Even serving the apple can be associated with deploying the software. In agile you will deploy and release software early providing time and scope for feedback.
This is an over-simplified analogy between software development and serving an apple to hungry kids. Still, I think you can easily identify the advantages of doing agile software development with this example.
Of course, software development work is much more complicated than serving an apple to four children.
Always think of the smallest possible value a software engineering team can deliver to the customer. This will create a win-win situation for everyone involved.
And yes, even a five-year-old can easily understand that agile software development is better as it will satisfy the hunger faster.