Technology is always riddled with jargon. No sooner have we mastered one jargon term that another twenty head our way. It is just impossible to keep track of all of them. However one jargon has been flying around for too long now and very few people are actually able to make good sense out of it. That jargon term is ‘Agile’. This term is so often used nowadays. Every day you will come upon a company that announces that they have adopted Agile methods. But ask them what they mean and they will not answer in simple English. That is what I want to do in this post.

Traditional project management

Let us say that Aditya needs a shirt sewn. Bharat is the tailor who is tasked with the sewing. In a traditional scenario, after Aditya has handed over a cloth material to Bharat and the latter has taken measurements, their next meeting is directly when the entire shirt is ready. Typically this would be 2-3 days later if Bharat’s work load is regular. During festive seasons, Bharat might be taking in more orders and he would need upto 7 days for delivery. Meanwhile Aditya waits. On the day of delivery, Aditya finds that the shoulders of the shirt don’t line up properly. He doesn’t like the spacing between the buttons. He needs fewer buttons with more space between them. The collar is too floppy and he wants them stiffer. Bharat goes back to the sewing machine and Aditya plays the waiting game again. This goes back and forth until Aditya likes the shirt. Aditya has had to wait too long and Bharat has had to undo some hard work and redo new work.

The only time that Aditya got to see the shirt for the first time was when Bharat claimed that it was finished. Could Aditya have been more involved in the sewing process? Could Bharat have asked Aditya more questions and tested assumptions along the way before every step in the process?

The traditional way of shirt-making is akin to software development’s waterfall model, where one step cascades after another. One step has to be completely finished before another begins. Bharat has to take measurements of all the vital body contours of Aditya, i.e. chest, shouders, chest, collarbane, etc. before starting to sew the shirt. Aditya can try the shirt only when it is completely sewn. The waterfall model assumes that the world is a utopia and that every step has been worked to detail. E.g. Aditya has already specified to Bharat that he wants four buttons on the front of the shirt, while the clothing standard calls for 5. The waterfall assumes that Bharat is an exceptionally accurate tailor and that he has stitched the shirt with no human error, making sure that the shoulders fit perfectly as per the measurement given.

The real world is fuzzy. Aditya never told Bharat about the buttons until he saw the result. In fact that is when he even remembered the point. Bharat assumed that Aditya required a shirt with 5 buttons as is the clothing standard of leading brands. Bharat took the measurements of Aditya’s shoulders, but somehow the shirt he stiched doesn’t line up with Aditya’s shoulders. There was a small human error somewhere. The waterfall model is stretched when faced by the real world of imperfection.

Increasing the agility

Bharat can be a bit smart about it. He can make the shirt in incremental steps and show Aditya the result of each step, along with the prototype of the next step. E.g. what if Bharat simply sews the chest and the back of the shirt, with no sleeves or buttons yet. He can ask Aditya to wear the shirt and check if the shoulders and chest fit properly. If no, he has immediate feedback. Meanwhile, he can wrap a sheet of cloth around Aditya’s hands and tell him that is how the sleeve would look when finished. Aditya can point out any differences there before the sleeves are sewn. Likewise, Bharat can place a few loose buttons on the shirt, where they are intended to be sewn. Aditya can quickly point out that he wants only 4 buttons spaced longer than usual, instead of 5 buttons with regular distance. No sewing has been done yet. These two ideas showcase prototyping, i.e. putting together a crude demo to show how the final result will be like.

Bharat has just used a method called ‘Agile’. This method uses small, but more frequent deliveries to keep the client happy and in continuous knowledge of the progress. Agile uses prototypes so that the client can see what’s coming up and how it will behave and look like. Agile uses continuous feedback from the client so that there will be more communication, less rework and happy parties who like to work with each other.

The Agile manifesto

I do not like to spring jargon on you, but this post will be incomplete if were not to include the official manifesto of Agile by those who conceptualised the term. I promise to unjargonise them for you. Here goes.

Agile seeks to improve software through the following manifesto.

• Jargon: Individuals and interactions over processes and tools
  Dejargonised: What if Bharat leaves his measuring tape behind and simply asks Aditya what is favourite measurements are? Aditya might have got plenty of shirts done before, such that he knows his measurements by heart. Hopefully, he hasn’t changed much in size and his favourite shirt still fits him. Leave the tools behinds and talk first. A tool is exactly just that, a tool. Communication is the key to a great experience. The right tools can come out after a good session of conversation. Bharat may find that a measuring tape is necessary. He directly needs a pair of scissors. Conversations can also build relations which help the two parties work better together.
• Jargon: Working solution/prototype over comprehensive documentation
  Dejargonised: We talked about this in the examples of prototypes. Instead of taking measurement of Aditya’s arm and then recording it somewhere, Bharat can simply drape a sheet of cloth on Aditya’s arm and ask him how he would like the fit. The sheet of cloth serves as a prototype for the sleeve. Aditya can immediately see how the sleeve will look on his hand and how it will feel. Instead of abstract numbers like 18 inches, Aditya has seen a glimpse of the future. Bharat can simply use a pencil to mark the points on the cloth that he needs to cut through.
• Jargon: Customer collaboration over contract negotiation
  Dejargonised: What if Bharat were to prepare a multi-page stack of paper that said ominous things like, “The client is allowed no more than two alterations on points he did not cover when gathering the initial requirements breaching which, each additional alteration will cost ₹ 50. The decision of the service provider on such matters is legal and binding”. What if Bharat pushes the stack to Aditya, has him read tens of pages and sign on a dotted line. Later, if Aditya asks for an alteration too many, Bharat points out to the stack of paper and says, “You are breaching the contract, that will be an additional ₹ 50”. In contrast, what if Bharat says, “Listen Aditya, I would like you to speak out any specific requests that you may have right now. Or let’s say you have two more days. Whenever you feel there is something you forgot, please call me or ping me on WhatsApp. Let’s talk about it and if I think it is extra effort, I will let you know and we will work out how to proceed further, possibly for an added fee”. Notice how the second sounds friendly, collaborative and leaves room for discussion on disputes, while also saying that Aditya shouldn’t be abusing his freedom and being too demanding or clueless about what he wants. He is reminded gently that too much effort on the part of Bharat may cost extra, if Bharat so feels.
• Jargon: Responding to change over following a plan
  Dejargonised: Because Bharat is working shorter goals and showing flexible prototypes and Aditya is being shown every increment, the two can work together in a flexible manner. Aditya does not have to wait until the shirt is fully done before his feedback is taken. His feedback can be instant as soon as he sees prototypes. Bharat doesn’t have to undo any previous work and can take up the feedback immediately, since what is showed was a prototype and not a finished shirt, from which he’d have to cut out threads and sew again. In the traditional method, Bharat took measurements and made an irreversible plan to stitch the whole shirt. But with Agile, he is open to feedback and changes at every step.

Implementing Agile principles

Agile is simply a set of principles that talk about using iteration, prototyping and feedback. To execute Agile, you need a good system that ensures that a team works together, that every person in the team has a role, that teams’ capacities are considered fairly and that everything is planned and recorded correctly. There are two common Agile systems in practice: Scrum and Kanban. We will see both the systems in the next post in the series.

Conclusion

From a simple example about stitching a shirt, you can see how much more flexible and streamlined Agile methodology is over the traditional waterfall model. At first, Agile methods looks more chaotic than the traditional stick-to-the-plan waterfall model. But over time, you will see how liberating it is and how the work actually gets done faster.