Get in touch
+44 (0) 7960 995 269

Back to Blog

20 Jul 2015

Top 4 differences: PRINCE2 vs Agile

by Melanie Franklin

Agile is different

Running an AgilePM course this week, my delegates and I have had a chance to share our experiences of working within an agile environment.

4 key differences

We identified 4 core changes between PRINCE2® and AgilePM™

  1. Users/customers not getting everything they ask for
  2. Welcoming feedback and change
  3. Getting used to rolling-out things that are ‘good enough’ and not perfect
  4. Empowering the team and avoiding micro-management by the Project Manager

I have expanded on each of these 4 areas to describe how these differences come about and how to incorporate them into your new ways of working.

Users/customers not getting everything they ask for

In PRINCE2 we pride ourselves on gathering all the requirements up front and creating a plan that knits them together into a cohesive ‘end deliverable‘. The fuel that drives an agile project is ‘prioritisation‘. At every step in the project lifecycle we are trained to ask

‘is this feature a must have?’

  • does it create benefits for any of the users/customers?
  • does it protect the safety of users/customers?
  • is it a legal requirement?’

If the answer is NO! this doesn’t mean that we ignore the requirement, it just means that it is not guaranteed.

The focus will always be on delivering all of the must haves, and after that we can get to the others which are categorised as Should Haves (next level of importance) or Could Haves (lowest level of importance). Sounds simple but there is a lot of work involved in encouraging users/customers to clarify what is vital to the success of the project and which of their ideas are nice to have, will add to the quality of what is delivered but are not essential and could be worked around if time is tight.

Welcoming feedback and change

Agile projects deliver their outputs throughout the project lifecycle, rather than saving up all of the work and handing it over as one complete package at the end. This means there is plenty of scope for users/customers to change their mind about what they need and add in new ideas. This sounds great in practice but it means that project team members have got to develop the ability to take this feedback and use it constructively, even if the feedback is given emotionally and critically!

Successful agile working relies on feedback to help ensure that the project deliverables are exactly what is needed to meet the business need. To achieve this we need to recognise that giving effective feedback is a skill and be prepared to train and coach users/customers to deliver this in a way that points out what needs to change without unduly criticising the original work. If not, negative criticism will inhibit the willingness of the team members to show their users/customers what they have created so far and miss the opportunity to learn what works and what doesn’t.

Getting used to rolling-out things that are ‘good enough’ and not perfect

This challenges the professionalism of team members who can feel as if they are not doing their best if they are creating deliverables that work, that are fit for purpose but if given a bit more time could be so much more. It takes personal discipline to hit Send on an email where the attachment is an OK document but not a great document because it covers what was asked for, but doesn’t have all the possible information or research.

It takes courage to present a basic version of a new website, with only a few pages created even though that is all that is needed to get the service launched, when ideally the developer would have included original imagery or built a payments facility into the site. It is facing up to this feeling of embarrassment or fear of being criticised for poor quality work and overcoming it that is key to working in an agile way.

Empowering the team and avoiding micro-management by the Project Manager

Giving the team the objective, the high level acceptance criteria for their work and the deadline by which they have to deliver and then stepping back and letting them get on with it is hard. Many Project Managers are used to being in charge of all the detailed planning of all the work, and allocating that work to specific team members. In AgilePM it is the team that self-organise and use their skills to work out exactly what needs to be done and when. Even worse for the Project Manager is that these discussions are often held among the team, facilitated by the Team Leader but not directly involving the Project Manager.

There has to be a high degree of trust to achieve this level of team empowerment and emotionally this can be hard for the Project Manager, especially if they are used to more control. A simple way to encourage the transfer of responsibility is for Project Managers to think more in terms of questions than instructions. Instead of issuing detailed instructions about how something is to be done, ask the team to present back to you how they are going to undertake the work. Instead of allocating work to individual resources, ask the team to explain who is going to work on what and when, so that you get a sense that the team know how to get things done, so you get your necessary reassurance without dictating how the team should work.

Melanie Franklin
20th July 2015
agile, prince2