The business always wants to know what it’s going to get and when it’s going to get it.

Agile development often causes tension with the business. Without question, Agile is a better way to develop and create value, especially with the current software development tools available.

Agile is a fantastic way to seeing progress on a regular basis, but when is the final product going to be available?

Agile Is Just For Start-ups and Operational Change?

In start-ups, Agile development enables revenues streams to be realised much quicker through the concept of MVP (minimum viable products), but in more established organisations, developing new products or updates to existing ones (legacy or otherwise) presents a cost without sight of benefits. It also normally requires an old product to be decommissioned as part of the project too.

In an operational environment Agile enables faster releases of high quality code on a regular basis as an operations expense, but in a project environment where something new is being created costs are approved on the back of business cases. A business case needs a timeline and cost to see the benefits, or it’s not exactly a business case and it should never get approved.

Agile Is Good For Projects Too

But does it make sense to use Agile in project environments? Yes, of course it does, however, there is a simple problem – the business wants to know when benefits come to fruition, and the Agile development team can’t always give a straight answer to that question. But this is no different to normal projects – the initial planning is often guess work. What you do want is for your delivery team to work effectively – then Agile is the answer (particularly if used operationally).

So it is in these defined project timelines that Agile development becomes a challenge, but I think these are perceptions only and brought on by a lack of experience and understanding. Agile often focuses on development. Iterative development and release requires less training and they are small steps. Projects are there to deliver a bigger output with more impact, often related to significant change to the business, technology or both.

Project Managers are then given the challenge to deliver these project outputs to a time and cost budget, but with an Agile team or supplier working with Agile. Many people think that traditional project management doesn’t work with Agile – but it does. It just needs re-thinking slightly.

Make Sure Agile Is In The Business Case

The business needs to be involved in the detail, not just during testing. This means embedded in the development teams – but this is no different any other Agile development outside of a project life-cycle. So, this needs to be part of the business case if you are going to deliver a project with any part being Agile – get Agile and deeper business engagement in there. A project should never be something the business just hands over to the project manager or digital and technology supplier to deliver – and come back later. If your business is managing projects like this, then you’re not actively managing projects.

In any project you should be reviewing the business case on a regular basis. So if you are going to use Agile for any part of the project, go back and update the business case, and get it communicated and approved again. You should also know at this point the broad stages of your project – when and where Agile will be being used. When are where you need that extra focus from the business.

Tips For Agile Success In Project Management

• Make sure Agile is discussed and the business is providing the resource required – put it in the business case or other project documentation you use (no surprises and communicate).
• Have a clear and unambiguous product delivery output defined, in Agile terms, a series of ‘epics’ – the initial epics should be known early on in the projects, this will help with planning stages and drive what ‘sprints’ might be required.
• Ensure that output from Agile delivery includes the delivery into the business as a ‘go-live’ -this should be a ‘sprint’ or several.
• Include training and on-going support, and hand-off into the business and technical operations – again, this should be a ‘sprint’ or several.
• Train people on Agile techniques and how they are being used in the organisation – without this you should expect friction and confusion (also make sure your project board understand it too – with Agile development the business can get more involved if they want too, and you should want them too).

If you’re an experienced project manager but not convinced by Agile then get up to speed with the many online resources. It’s only change – and isn’t that what project management is all about anyway?

Links

Scrum.org – https://www.scrum.org/courses

PRINCE2 Agile – https://www.prince2.com/uk/training/prince2-agile