What Is Agile Product Delivery and Why Does It Work?

What Is Agile Product Delivery and Why Does It Work?

If you want to build a piece of technology, especially at the enterprise level, you’ve got a number of different approaches to choose from. The list isn’t infinite, but it’s long enough to be a tangle of acronyms: V-Model, RUP, RAD… each model has its own strengths and weaknesses, but at PSG, we’re big fans of Agile Product Delivery. 

What is Agile Product Delivery? It’s an iterative and collaborative software development and product delivery model that builds small, functional elements of larger projects and products one piece at a time. And it works because Agile offers a methodology designed to account for the fundamental principle of the universe: things change. And in IT projects, things change all the time.

According to a report by the Project Management Institute (PMI), half of all IT projects in a given year suffer from “scope creep or uncontrolled changes to the project’s scope,” and 31% of projects didn’t meet their goals. That’s almost a third of all projects that fail to measure up, representing a huge loss in time, energy and money for the company. And the culprit? All too often, it’s because by the time they got to the end of a project, the requirements changed.

Accounting for Change

That’s why Agile is a great approach to software development and project management. It allows for the inevitable changes in a product’s outcomes and requirements. In waterfall development models, projects are mapped out from start to finish – before the first line of code hits the screen. Every step of the process is outlined in linear phases, with each step dependent on the prior phase of development. Deliverables are finished sequentially and progress flows (like a waterfall) in a single direction. This process can certainly be effective, but it can also be grueling and inflexible. 

In contrast, Agile planning works precisely because it doesn’t try to map everything out in detail. Where waterfall maps the entire route, Agile focuses on the next few steps then pauses to evaluate. It’s like the old joke: “how do you eat an elephant? A bite at a time.” Instead of focusing on the all encompassing end product that covers a huge range of oddities and expectations, Agile focuses on delivery of incremental pieces of functionality that are usable and reliable. 

This provides opportunities to pivot when expectations and requirements inevitably change. The development team isn’t locked into a particular trajectory and deliverables are iterative and incremental. This leaves a lot more room to adjust course. Working piece by piece, Agile ensures rapid, fully operational delivery of a product and leaves room for the inevitable changes.

Making Decisions Efficiently

We’re all familiar with the long, painful experience of death by committee. How many pet projects have languished on agendas, bogged down in reporting details and endless questions? Too many. If you want to get things done, you need a clear decision maker. 

Agile works best when you have a dedicated team, a dedicated war room and, most importantly, a dedicated Product Owner. While it’s not always possible to assemble everyone in a single room, it is possible to ensure that decisions get made quickly and, well, decisively. Having a dedicated Product Owner for an Agile project is the only way to effectively prioritize your sprints and get things done. Working closely with the project manager (or “Scrum Master” if you really want to delve into Agile nomenclature), the Product Owner makes the calls.

Tackling Realistic Goals – Quickly

The goal of Agile product delivery is to solve a little problem, solve it quickly and solve it well. The Product Owner and Project Manager put their heads together and work their way through an initial backlog. Together, they prioritize which problems (or pieces of the whole) the team can realistically tackle in a small period of time. The Agile approach is great because not only is the product team delivering functionality on an ongoing basis, but the process itself also keeps goals and schedules realistic. 

Agile breaks projects and products down into manageable chunks and then builds those chunks in sprints – usually lasting two or three weeks. The first sprint starts with the most vital piece, the thing the project most urgently needs. Importantly, that “thing” is something manageable. Maybe it’s a login page. It’s not a finished application. If any piece is going to take the team six or eight weeks to build, then it needs to be broken down into more incremental phases. The goals of sprints are to solve problems quickly, effectively and to learn from each phase. 

As a result, Agile continually validates what is realistic by proving our delivery on a sprint by sprint basis. The team goes out, builds something, and does a demonstration at the end of the sprint. They should then be able to say, “this is done, it meets quality standards, and you can use it now!” Agile provides ongoing value to the business by delivering functionality throughout the lifespan of the project. This is a stark contrast to to projects that spend months in development with no concrete outcomes.

Delivering Top Value to the Business

Another major challenge with many of the other approaches to software development is that people are just plain bad at gross estimation. Trying to bid out major business problems by estimating long times to completion (fifteen weeks, six months, etc.) usually leads to delays and miscalculations. Agile takes the overarching goals, pulls out the most important chunk, and starts there. 

Planning in Agile Product Delivery stratifies achievable functionality in terms of priority. Because the Agile approach is built around small, achievable goals, it provides ongoing learning opportunities and rapid process improvements. Tasks are selected and accomplished based on interdependence and how valuable each element is to the business. And, importantly, each phase of development keeps the underlying architecture in view. 

As the team learns more through each sprint, they’re able to feed that understanding back into subsequent sprints. This ensures the value to the business and avoids technology deficits. Sprint One may have involved some shortcuts to deliver the initial login page. But the team can focus on a piece of that architecture and improve it to enterprise level in Sprint Two, right along with the second piece of functionality. 

In other words, the team ensures an architecture improvement in each sprint. This provides a continual ROI not just by reducing the work pieces that need to be done but also by reducing the overall technological debt. Instead of losing months of work to potentially failed or derailed projects, Agile ensures that each step of the process provides value to the business. In our opinion, it doesn’t get much better than that.