The Agile method of software development took the software world by storm in early 2000s. It has continued to grow significantly in the last two decades. So much has it grown that its predecessor, the waterfall model, is now seen as an outdated Jurassic method of approaching software. Very few companies still stick to the waterfall model. And those companies are considered luddites!

But is the Agile method as good as the hype surrounding it is? Or is it just another management fad that software engineers are tolerating in silence to keep their jobs? Turns out that Agile is superior to waterfall model on several counts. But a 100% move of each and every process in a company from the so-called outdated methods to the nimble Agile methods can do more harm than good. How? Read more to find out.

First of all, what is Agile?

You can read the full details on Agile in the posts, How agile is your project: Part 1 and How agile is your project: Part 2: Scrum and Kanban. But here is a TLDR. What if one can deliver a project in parts rather than in one full go? That’s what Agile makes possible. Let’s see a real world example.

Let’s say that you are a carpenter building a table for a client. One way is to ask the client for a full specification, i.e. asking for everything up front. The shape of the table top, the dimensions, the height of the legs, the colour of the table and the finish on the table top surface. Since you have everything you need, you don’t need to communicate with the client anymore. You take an advance pay and get to work. Two weeks later you deliver the table exactly as the client wants. You are thinking to yourself, “Work done. Dues will get paid.”

But wait! Is the real world so easy? No. Clients are unsure of their requirements at the start and change their minds often. While some changes are unreasonable and need complete renegotiation, other changes are easy to accommodate if the client mentions them on time, i.e. before you have done any significant work on the very thing that the client wants changed. What happens if you take the table to the client after two weeks of work and the client wants to change the height of the legs? Oh, while at it, he doesn’t want a glass top anymore, but a sunmica top. And what about a round table instead of a rectangular table? And enough changes for you to roll your eyes.

Why did this happen? Because the client was unsure of what he wanted. He only gained clarity on what he definitely did not want after he saw a tangible table, instead of the one in his imagination. This happens often. Abstract and numeric specifications fail to provide a client with a visual idea of what a product will look like in the real world. But a finished product suddenly makes things clear.

What if you can adjust your table making process. Two days after the speaking to the client, you take a sheets of wood to the client’s home, exactly where he wants the table. A rectangular sheet and a round sheet. In software terms, this is a table ‘prototype’. Using various props around the house, such as a few stilts, cardboard boxes, etc, you prop up the wood sheets at several heights until the the client is happy with a certain height. Of course you do this with both round and rectangular sheets and ask the client for a preference. During the next prototype, you take a few 1-by-1 inch square swatches of table top finish, such as sunmica, rust, etc and stick them on the wood surface. From this, the client can make a selection.

And so on, until the table is built exactly to client specifications. Step by step, with client being asked for feedback every one or two days instead of at the end of two weeks.

The Agile manifesto

Agile is based on the following four principles.

1. Individuals and interactions over processes and tools: Most tasks can be achieved when people quickly speak to each other instead of following a lengthy process or hunting down things inside complicated tools.
2. Working software over comprehensive documentation: Both clients and software developers gain more clarity by looking at tangible software instead of abstract documentation in words and diagram. Feedback can be instantly given and developers can understand exactly what the clients are asking for.
3. Customer collaboration over contract negotiation: Customers often do not know exactly what they want before they see something tangible and pick likes and dislikes from those tangibles. It might be futile to draw up a contract based on uncertainty.
4. Responding to change over following a plan: Plans are made as guidelines in utopia, but they often fail in the real world. The only good plan is to anticipate change and act accordingly.

Perils of Agile

All the four points are excellent ideas because they eliminate the rigidity of the waterfall model, which fails at the first sign of uncertainty. But is Agile really panacea? Like its own definition, Agile itself is full of uncertainties. A process fraught with uncertainties is not enough to help you in your quest to finish projects on time.

In any project, one wants a solid and rigid foundation to build on. 100% Agile casts uncertainty over everything in a project. It is not a good idea to unleash Agile on a complete scale in any project. A 100% Agile approach is a recipe for chaos. Let’s take each point from the manifest to see the perils of total Agile.

Individual and Interactions
over processes and tools

This point from the manifesto encourages you to ditch tools and processes when you need things fast. It encourages you to pick up the phone, open a chat window or walk to the person who is in charge of something and speak to him/her directly. It gives you the idea that raising tickets and requests or poring through documents and files are a waste of time and that to get things done, direct one-to-one interaction is the best. Inherently it also encourages flash meetings (meetings without notice), unsolicited phone calls, chat messages and instant collaboration at a moment’s notice to get things done.

Is that good? It depends on your role in the project and in the company. It works wonderfully for managers and staff whose role is taking care that things are done by their direct reports. E.g. a CFO, who is working out the cost of a project, should ideally contact the CTO directly to get to know the licensing cost of the software they are using. If the CFO visits the website of the software, he/she may get confused about the different license plans, because that information is too technical. The CTO will have that information at the tip of his/her tongue.

But it is a terrible idea to tap the shoulder of a software developer or a graphic designer who is engrossed deeply in their work, to ask for their progress or for the latest release of their work. This means that they have to drop their concentration to fulfill some petty request such as emailing you a file or notifying you their status. Nor should you call them to flash meetings to ‘discuss something quickly as it will take only 5 minutes’. It takes an incredible amount of effort to get into the sweet spot of total focus and takes more so to return to that zone after a distraction. It’s best to ask the designer and programmer to upload their latest work to a repository every morning and always use the latest version from the repository for your use. If you want something done, do not suddenly raise its priority at the drop of a hat. Instead submit it as a request in a ticketing system and let the professionals get to it at their natural speed. Processes and tools are better here than distracting and productivity-killing interaction.

One terrible side effect of this manifesto point is that it encourages a lax attitude towards putting in the work to learn processes and tools. “Why learn a tool when I can directly talk?”, say some people too lazy to learn tools or read documentation. Such people cause constant chatter with the alibi of ‘collaboration’ and set up a highly distraction-rich workplace.

PS: I think that open plan offices are one of the most terrible things ever designed on this earth.

Working software
over comprehensive documentation

This is the most practical manifesto point among the four and the most productive. We have already seen that clients are often unsure about what they want until they see something tangible and pick their likes and dislikes. It is futile to ask them to document their needs or to ask them read documentation about what our plan for the software is. A prototype works wonderfully to part the clouds in the client’s mind and make it as clear as a bright sunny day.

But how much is too much? Consider a client who says, “Make me something just like Instagram!” If the client wants a clone of Instagram, what is their value proposition? What is their offering within their app, that is different from Instagram? What will cause users to consider their app over Instagram or cause Instagram users to flock to their app?

“We are not sure. We are not good at making or reading documentation. Make us a prototype first, then we’ll decide from there”. Huh?

Sorry, but this client is just a wannabe. They have no idea why they are making a software app in the first place. I am not going to toil myself into making an Instagram clone and then wait for this client to nitpick their likes and dislikes from that clone. At the very least, a client should be able to clearly articulate and document in extremely precise and comprehensive words what their software’s unique points are going to be, which type of users it will help and how it will help them.

Customer collaboration
over contract negotiation

This point is my personal unfavourite since I have burnt my fingers severely as a freelancer working for clients. The idea behind this point is to be more friendly with clients, rather than cause an us vs them. It empathises that clients are unsure about requirements and that they will make mistakes to start with. The point says that it is futile to shut the client out with non-negotiable points in a contract and instead invite them to be part of the software building process as often as you can accommodate. Agile believes that it is wiser to be often lenient when the client suggests changes to their own requirements. It believes that during the whole process, the clients are learning too.

The leniency plan works wonderfully because it practically shoos the client to your company rather than some other company who will be unaccommodating. It sends out a message that you understand them and empathise with their uncertainty of requirements. They will work with you for this project and possibly for many more, because you care.

The plan works….. until it doesn’t anymore. Because to be lenient, you no longer can stand upto the client. You bend over backwards. You give in to the client’s whims. You say ‘sure, will be done’ when the client changes the background colour of the screen from azure to sky blue to mauve to cyan to cerulean to…. other colour names that you haven’t ever heard of! Driving your UI design team to their wit’s end, because it’s the umpteenth design they have worked on this week. Of course, for all this extra work, their salary remains the same.

What about a contract clause? Only 3 changes of colour allowed within current contract. Any more and there has to be a re-negotiation. That’s better. This sends out a strong message saying, “Be surer about what you want. Don’t pass on the risk of your experiments to our shoulders. Our time is every bit as valuable as yours is.”

Responding to change
over following a plan

“The only thing constant in life is change”, goes a boring cliche that’s repeated so often that we have accepted it as a gold standard. And so people uproot themselves from one city and plant themselves in another, believing that change is healthy. No, friends. Change is only healthy if some things are constant. As humans, we look towards some familiarity and stability even when everything around us is changing rapidly. A total change always causes chaos, because then people have nothing familiar to hold onto and it causes total confusion.

So what am I trying to say? Do not encourage working with a client who switches his software from one that hires taxis to something that sells perfume. Imagine the amount of massive change that has to go through the entire system, right from branding, all the way to the lines of code written by the software developers. For a pivot to work well, something has to stay stable at one place. That’s why it’s called a pivot.

The ideal situation is to follow a plan to the dot, so that you stay on track. But the next best thing is to stay focused on a foundation and then make changes based on that foundation. E.g. a pivot from hiring taxis to renting self-driven cars is okay, because the foundation of the pivot is a person’s need to use a car that belongs to someone else and to pay for every use.

Conclusion

Agile has melted the long time ‘us vs them’ standoff between software companies and clients. Instead, the two parties work more congenially and collaborate more often to get work done in a way that makes both parties happy. But there are examples of companies embracing Agile far too aggressively to the point where they affect progress due to distractions, chaos from too many changes and complete confusion about how to proceed. As with anything in life, Agile too is good when consumed in moderation, so tread cautiously.