Blog

In Agile, Following a Plan is Rarely Better Than Listening to the Client20 Jul 2021

One of the core ideas put forward by the Agile Manifesto was for teams to welcome changing requirements from the customer, also when they're already well into the project's development. Arguably, it's one of the ways Agile gives teams a competitive advantage. More openness to what the customer wants should translate into products better fitting their purpose and happier clients.

We believe that, for a software development company to remain successful, embracing fluid requirements is a must, not an option. Leaving the clients who do not know what they want out of the equation, it's worth noting that the most common reasons for changing requirements are: a market change, a mistake in writing them down originally, a defect in the existing product, or a change in the law that the product must abide. None of them is within the clients' control. Hence, unless you open up to fluid project requirements, your clients will likely take their business elsewhere.

But achieving satisfying results and keeping a team sane is not easy when the demands keep changing. What strategies should you employ to respond well to changing requirements?

Don't spend too long estimating and planning out a project

Place the few core requirements, described well enough for the developers to understand, but with no excess frills, on the project Kanban board. Let the team members pick one task each, or one for each pair, depending on how they choose to work. It's better not to assign tasks to people in a scenario where changes are expected.

Keep batch and tasks size as small as possible

Not spending any time on work that is not crucial for a feature will be imperative to limiting waste. Focus only on the core idea of a request. That, combined with keeping the general batch size as small as possible, will keep tabs on the amount of work that is later recognized as unnecessary.

Set and honor the WIP limit

Work in progress limit is an easy way to keep work quality high and project waste low. A good rule to follow when setting the limit is for it to be smaller than the number of people on the team. Respecting the WIP limit will maintain order in the project, stopping the incoming change requests from piling up in front of the developers, causing a sense of urgency and instability. The projects' trajectory will, inevitably, be unstable since the demands can change at any time. But the perceived progression of items on the board will balance out the chaos.

Make the process flow visual for all involved parties

If you're going to take a shot at managing the process and keep the evolving requirements in check and waste under control, the flow must be transparent and accessible to everyone: the team, the clients, and management. Visualizing the process and every individual task on a Kanban board will have a few key advantages to the changing requirements subject matter. It will make it clear what items got done already and which are still in the backlog. So, if the client has a change of mind about a feature present on the board, they can edit the unstarted card to request the new design. Or, they can halt the development of a no longer wanted thing to minimize waste.

Another advantage is that showing the scope of work already done to the client, in the light of them having a change of heart about the core idea, will make them aware of the cost already spent. It will either make them think twice about requesting the change or, at the least, better prepare them for the bill value at the end of the project. To make the cost clear, feel free to use your Kanban Tool boards' custom fields showing a task's hours worked directly on it.

Summing up

The fundamental point in opening up to fluctuating project requirements is to have the changes themselves not cause havoc nor create new organizational problems. If this is what it looks like for your team - an alteration in the requirements breaks your process and costs you tens of working hours of waste, you are not doing it right.

A well-known issue with teams staying open to accept requirements updates throughout the project is the impossibility of estimating the final cost. It can be worked around by keeping the projects themselves very small so that the general estimate and total cost differences are not as stark.

But an advantage that accepting fluid requirements gives you is more important than the downsides. If you'll only be working on projects with demands set from start to finish, so those where the entire plan is clear and available to the client - what's bounding the client to you? They can take the schedule to a more affordable developer or outsource it at any time.

For as long as you're open to working with them, not just for them, they will stay satisfied by having their completely custom needs met. You'll be giving them a bespoke service, not a closed-off product that may no longer be what they need after the time it took to produce it.