In a world of uncertainty, complexity, and rapid change, agile business approach - and consequently agile project management - is a valuable asset. This is especially the case in software development.
Agile projects allow us to plan the near future in more detail, while things further down the line are envisioned with less detail, in order to accommodate uncertainty associated with things further ahead. In other words, we can be more certain about our near future, while the distant future holds lots of uncertainty. We explained some of these concepts in an earlier blog post:
Planning your projects: Does the future allow any certainty?
Sounds great, you might say, but how do we do it in practice, when running complex and critical software projects in enterprise enviroments? They usually extend over a year or two. They involve multiple departments and teams, hundreds of busness epics, thousands of functional requirements and several thousand user stories, all that in a fast-changing environment. The latter will inevitably throw in a couple of surprises during the project lifetime.
Traditional waterfall model was all about planning software projects in advance, and in great detail. It took many months to collect all the requirements and compile specifications. They were detail-heavy, down to the very buttons on each screen. Only after specs were ready, development would start. It took a year or two to build and ship the product, with no room to change project budgets and deadlines. Because of that, the development process had little flexibility. It could not change to accommodate new business and market realities that appeared in the meantime. By the time they were delivered to the client, applications were usually outdated, out of sync with fresh tech concepts and new business needs.
In contrast to the waterfall model, agile project deliveries are adjusted to the fast-changing needs and circumstances, while staying within budget and delivery time. Agile projects introduce flexibility, and they can literally save the day (and budget!), by making sure that software will match business needs when we deliver it.
It can be challenging to run agile projects in non-agile surroundings. Having that problem in mind, some enterprises, while not yet planning and budgeting on agile principles, are still successful in integrating concepts of agile into contracts and deals they are signing with software development partners.
In our experience, it is much about finding common ground with software development partners when structuring the project. The two parties usually start by acknowledging the following principles:
These traditional project elements are then complemented with the principles of agile:
These principles are then incorporated in the project plan and contracts. In developed markets like the USA, companies buying bespoke software have experience with these types of arrangements, in which both parties take on a level of risk. This is accepted by both parties and reflected in legal agreements. But even if an organisation does not perceive itself as operating on agile principles, there is still room to structure and contract projects in this way. Mutual trust plays a massive role in the process.
We have seen that, in reality, many companies use agile and lean principles. Some may not call it that, and they might not know that aspects of their operations are excellent examples of agile. We have come to believe that flexibility and responsibility on both sides are key to shaping and starting agile software projects, and bringing them to a successful end.
Our CEO and founder Goran Mrvos spoke on this topic at the recent PMI Croatia monthly meetup. Get in touch if you want to learn more about agile project planning and how we do it in practice.
If you’re looking for a results-driven, innovative software development partner to help capitalize on new, profitable opportunities, reinvent your brand, or deliver incremental value to your business, we can help.