Since the Agile Manifesto was first published in 2001, many business leaders I’ve worked with have understood that adopting Agile processes means drastically changing their organisation’s way of working.

For an Agile product development process to succeed, it involves letting go of traditional Waterfall processes and knowing what questions to ask your software development team. And, of course, which ones not to.

When will the product be finished?

Thanks to Waterfall’s influence, many still see software development as a linear process where each stage is signed off before the next can begin. Even if the business has bought into an Agile framework, there may still be a reluctance to go live until the product is “finished”. 

In reality, a digital product is never finished; there is always an opportunity to improve it over time. With Agile, there’s rarely a single finish date because development is ongoing. In the world of banking, retail and telecoms, changing customer demands may require daily, even hourly, updates.

Rather than asking: “When will it be finished?”, IT teams should ask themselves: “Why are we building this product?” and “What are our customers looking for?”.

What’s the deployment date?

This is the real reason IT teams ask about a product’s completion date. Many Ops teams hark back to the days of develop-test-deploy and packing several features into an alpha version and deploying it by a certain date.

Focusing purely on the deployment date is problematic because it prioritises speed at the expense of quality. Instead, IT teams should focus on the functionality of successive deployments. Ultimately, they should be asking themselves what’s really changed since the last deployment, and how the latest iteration has improved the customer experience.

Can I keep elements of Waterfall?

In our view, this is a hard “no”. In most of the projects we implement, we use Agile principles, and scrum, Kanban or even extreme programming (XP). Nevertheless, I still see IT teams wanting to reap the benefits of Agile while sticking to the Waterfall methods they know all-too-well.

A Waterfall-Agile hybrid process will typically combine the weaknesses of both, with reporting being an example. A Waterfall-style project uses regular and formal reporting, at clearly defined steps, and an Agile approach uses regular stand ups where each participant develops an understanding of the process, achievements to date and objectives. This can include a scrum board, often built in Jira, or a Kanban board, to minimise bottlenecks.

In Waterfall systems, managers like to keep track of people and the time people spent on a project, but in Agile the focus is on the problem and the impact it has on the customer. However, if Ops teams attempt to use an Agile approach, with scrum boards, and produce time-based estimates expressed in a Gantt chart, for example, the process ceases to be Agile. Implementing a holistic Agile process and embracing all elements of the framework is a much better approach.

Sometimes it feels safe to stick to what we know, but embracing Agile in its entirety means totally rethinking approaches to product management and entering with a fresh outlook.