Preparing your organization for an agile project

Project Managers faced with such a challenge must accept they can’t do it alone: you need people with a digital mindset; not technologists, those people who embrace 21st century work practices such as operating with networked power, taking decisions based on having enough but not all data and accepting that development is a public and shared process. Just as Amazon invited user feedback on its early website iterations, you need the “perpetual beta” approach of constantly improving, which needs education to change the way people behave.

So, what should you do before an agile project begins?

1 Work the network not just the hierarchy.

Project Managers need to decide the “emotional choreography” of the project: every project has a story but are you managing a story or a process? If it’s the former, you need to work the network and understand where the power is.

While many technologists involved in projects are more comfortable with processes and hierarchy than networks, the Project Manager needs to demonstrate emotional literacy to create a more resilient project based on mutual trust with the stakeholders. Otherwise, you can end up with a clunky, mechanical project that is vulnerable to failure.

To understand whether you’ve got the right people involved, you need to have the conversation about stakeholder engagement; deciding who is responsible and using the network approach rather than selecting stakeholders based on job title.

2 Who’s got the monkey?

In the classic management scenario, the “monkey” is a business problem that gets passed around. In an agile project, the Project Manager needs to be clear who is responsible for “feeding the monkey”. In our world of email and broadcast (one-way) communications, the risk is to fling out monkeys without knowing who’s catching them.

You need to ensure your communications are good enough that people actually catch the monkey; equally, throw out only as many monkeys as people can feed!

3 Unscripted time

Never underestimate the benefit of unscripted time – this comprises the actual conversations that happen outside of the programme board; governance is about people coming together to agree on how to manage the right risks. Unscripted time hooks into agile methods in which the development team is often likely to surprise you. Handling that needs time built into the process which allows for you not to treat it as a threat.

4 Dealing with spanners in the works

Everybody arrives at the start of the project – a time of hopes and dreams – with the best version of themselves. But once you enter the grind and the detail, life gets in the way of the shiny project launch.

A Project Manager is a change agent as well as managing a project, so how do you maintain the energy of doing something differently, such as adopting agile principles, and channelling positivity?

When people are surprised by the approach you will get questions coming back up the food chain. And you need to manage the “delta” between what they’re getting and what they were expecting. This needs more time for stakeholder engagement to understand what the sponsors will, or won’t, like. When using a new project methodology, you need to spend time with those who are unfamiliar with it because, at a first sprint review, you don’t want the sponsor freaking out the first time a sprint doesn’t go to plan. Just telling people it’s an agile project doesn’t overcome this – you have to work with them until they are comfortable with this change in order to manage this risk. This extends also to the realm of managing programmes and where projects sit within them, though the issue of coordination across delivery, project and programme management is a story for another day and another blog post.

The start of a project requires space to allow different behaviours to happen, while acknowledging the inevitable friction between agile and business-as-usual teams. Having a clear narrative – the ‘story’ of the project - will help to minimize that friction.

5 To define or not to define…

Before a project, to achieve a better result, get enough information from the stakeholders but without over-defining. This helps to avoid juggling a huge set of requirements. Stakeholders’ natural urge is to over-specify and they will be anxious if they don’t understand the process.

Explaining the process and communicating with all the stakeholders throughout is about managing the potential disconnect between the sponsor and development. Without this, at implementation stage, you might not get the level of adoption you need as what the project has delivered is so different from what was imagined at the start.

By co-designing the product with the users, they are much more likely to use it. This approach both de-risks the project and exploits the value within agile.

See our PRINCE2 Agile® section for more information about agile project management.