While there is much written about Agile, it’s important to understand not only the principles of the frameworks but also what it means to be Agile.

The demands of customers, the changing landscape, the speed at which technology is growing and the rate at which we learn means that we cannot afford to be anything but Agile in our pursuit to deliver projects that make a real difference.

In years gone by we’d follow a waterfall methodology to deliver projects. There’d be much activity at the start of the project while requirements were gathered and the project was kicked-off, followed by a quieter period of development before wrestling with testing bottlenecks and change requests when everything attempted to come together at the end.

Today, we’re dealing with significant demands from all angles, the rate at which we need to respond introduces risks that we need to manage, the requirements we define at the outset are almost guaranteed to change, we’re continually encouraging feedback that we then need to respond to and the pace of delivery starts high and continues throughout.

Agile frameworks such as Scrum are intended to help us deal with change but there’s more to it than adopting a framework. To make Agile work we need to be Agile. Being Agile is a mindset, one that seeks learning, user feedback, acceptance and improvement. Change is not seen as a barrier to delivery. Change is positive, a response to feedback from users to improve the quality, effectiveness and usability of the solution we’re building. It’s the knowledge we gain from reviews, the understanding of the level of fit-for-purpose that we use to inform the decisions we make throughout the delivery lifecycle, as we build a solution based on facts, not assumptions, about those for whom the project is intended.

Being Agile is also about developing products iteratively, releasing them as an MVP to the public before they’re complete, gathering feedback and continuing to build based on what those users tell us. This is a seismic shift from traditional ways of delivering, releasing products before they’re complete and working more closely with the users to understand what is really needed to complete the product.

For stakeholders and sponsors, the MVP approach is an important tool to start achieving the savings and implementing the efficiencies that the project is tasked to deliver. Rather than waiting until the entire product is complete, releasing an early version of the product, whether to expose the mobile trading market, enabling the call centre to offer new products or to improve the efficiency of the ecommerce checkout process, this will enable the improvements and savings earlier. Working with the users, we can use their feedback to focus the efforts of the project on the opportunities this exposes.

Being Agile is not exclusive to IT projects. Consider Formula 1. There is a huge investment from teams to design and build their cars, to put together the team, to attract the best drivers, to attract sponsors, to win points, races and championships.

Formula 1 teams put a lot of work into preparing in pre-season. They develop the initial technology and then work closely with their users (the drivers) to iterate through their build, test and review cycles. You could consider their MVP as having the car race ready for the start of the season.

Once the MVP is launched on day one of the season, the work doesn’t stop there. Suddenly the product (the car) is exposed to the other products on the market. The teams study the performance of their own product and competitor products, and they speak regularly to the driver who provides his feedback about his experience with the product. That feedback can be turned into improvements, all in the pursuit of success.

The teams have the risks of collisions, weather, tyre choice, budgets and changing tactics to deal with. Dealing with those risks and the challenges of continually developing their cars means they have to have an Agile mindset to maintain flexibility and encourage continual learning and development in order to succeed in a very difficult competition.

Encouraging change and providing the facility to capture and continually respond to user feedback and metrics is essential to the success, and continued success of a project. While we can test a product to make sure it works it’s not until it’s released to users that we know whether it’ll be accepted and whether it’s fit for purpose.

Customers often respond to products in ways we don’t anticipate. They discover those edge cases we never thought about. These unexpected responses and use cases need a delivery framework that captures the feedback and a mindset that sees this as an opportunity.

Whether you’re handling code or cars, nginx or engines, it’s your ability to measure, listen, respond and adapt that will lead you to success.