Agile projects in non-agile surroundings

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.

How does that happen?

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:

• We still need deadlines, i.e. key project dates.
• We still need project duration, i.e. a time span.
• We still need project deliverables, i.e. business areas and key functionalities.

These traditional project elements are then complemented with the principles of agile:

• When diving deeper into business epic and features, the two parties work together to agree on details, whilekeeping things on budget and within deadlines.
• We allow the order of priorities to change. Instead of x, it is perfectly doable to promote y as more important at some point. This means dev teams will have no problem shifting to y, and delivering it earlier.
• While key business topics are firmly set, details of related user stories and tasks are flexible. Features and user stories can be added and removed.
• Instead of scope, we think in terms of work item size. By work item size, we mean project size, epic size, feature size, user story size. Size is not an estimation of hours needed to do something, but a relative estimation of some work item, according to other work items.

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.