During a casual chat, I told my friend about Breathe Agile. She asked me to explain Agile in layman terms. I did give her an answer, but I was not very happy with it. After some introspection, I decided to create a post, and you are reading it now. In this post, we explain what is Agile, in simple and layman terms, with real life examples.
By the way, What is Agile?
I know it still sounds a bit theoretical, so let’s take an example.
You are planning an exciting jungle trek. Someone told you there is a beautiful waterfall, and that’s your end target. But unfortunately, the walking trails are sparse, and the GPS coverage is poor (though it exists in some spots).
How do you go about this adventure? Here is one possible approach.
- You make a rough plan with whatever information is available
- In the plan, you make a note of remarkable landmarks that help evaluate the course of your trek
- You start your trek with this less-than-perfect but reasonable plan
- At periodic intervals, say every 1 hour, you assess progress
- Using various parameters like landmarks crossed, available walking trails and the unreliable GPS, you try to gauge the progress towards the end goal
- It is very much possible that the course needs correction
- You make this decision at this checkpoint and modify your original plan as needed
- You repeat this evaluation and correction until you reach the final target
Here is why this approach makes sense:
- There is no way you can make a perfect plan, and you have to make the best use of available information
- Modifying your plan as you go helps you to make regular course corrections
- At any point, if things go haywire, you can quit the mission to avoid risking your life
Apply this analogy to Software Development
In many aspects, Software Development is a knowledge intensive activity (we will discuss some exceptions in the next section).
The problem is even worse than the jungle trek because:
- End result is uncertain – Most customers don’t know what they need unless you show something to them
- Solution or Means to the end result is unknown too
In the jungle trek example, only the means was uncertain!
We use the similar approach to software development like what we did with the jungle trek:
- Understand the customer needs to make reasonable assumptions about the end result
- Create a good enough plan, with whatever information available, to reach the end result
- Split the plan into multiple steps, where you make incremental progress towards the end result
- Review after each step together with the customer, make course correction as needed and continue
- Do this iteratively, until the end goal is accomplished
As you may appreciate by now, Agile is a more pragmatic approach to software development, which is otherwise unpredictable.Agile is a pragmatic approach to software development, which is otherwise unpredictable Click To Tweet
Exceptions where Agile may be redundant!
Does this apply to all projects? Not necessarily.
Consider a project to install Windows 8 on all desktop workstations. Let’s simplify the problem by assuming that it is already tested and given a “go” to be deployed everywhere. In this scenario, the end result and means are clear. Agile may not make a big difference in the execution or outcome.
We talk about this in detail here – Agile is NOT one-size-fits-all. Do check that out!
- In projects or initiatives, where either the end result or means to achieve the end result is not clear, perfect plans are impossible
- In such cases, the pragmatic approach is to start with reasonable assumptions and a good enough plan
- Periodic reviews with the main stakeholders indicate the course corrections that may be needed
- Most software development projects are knowledge intensive and fall under this category
- In projects, where the end result and the means are well defined, Agile doesn’t add a lot of value
I hope this post gave you a simplistic overview of Agile. If you have further questions, feel free to ask us (use comments below), and we will be happy to answer. Happy Agile!