Thursday, April 18, 2013

Agile and Prince2

Since Agile doesn’t say much about how to structure a project on a higher level, apart from release planning, it might be interesting to see if and how Agile practices can be combined with for instance a methodology like Prince2. I am going to limit this exercise to Prince2 since I have a certification in and experience with that particular methodology.

Prince2 divides a project in stages. There is the initiation stage, and then you can divide the remainder of the project in as many delivery stages as you see fit, followed by a closing stage.  Prince2 doesn’t say anything about the activities of these stages, except for the initiation stage. In that stage, a project charter, business case, risk register and so on are to be produced. This makes sense in an Agile environment too. You will have a run-up towards the first sprint where you need to define the vision, an initial story map and backlog, provide estimates, establish a fist release planning, do resource allocation, and translate this into a budget that can be included in a business case for approval by senior management. All this qualifies as an initiation stage as defined in Prince2.

During the delivery stages, you can plan whatever you see fit. This means you can take your release planning and consider the various releases of your project as stages in a Prince2 sense. You can create your stage plans as per Prince2 and describe in them the high level scope, risks and a baseline release burn-up or burn-down.  If you need to add teams or change team composition from one release to the next, that too can go in the stage plan. The stage will consist of several Sprints that make up the release. Prince2 mandates that the business case be reviewed after each stage to see if the project still makes sense and that comes very close to Agile practices indeed.

As for the roles, the central figure in Prince2 is the project manager. He has one or more teams working for him each with a team leader. There is no reason why these teams shouldn’t be Scrum teams with a Scrum Master. The project manager then becomes a sort of overall Scrum Master for the project, with all the responsibilities of a project manager in Prince2, as well as supporting the teams and other scrum masters in removing impediments. In Prince2 the users are represented in the Steering Committee by the Senior User. This person could take up the role of the Product Owner, or delegate that to someone in his organization, as long as the delegate has full autonomy and authority to make decisions the correspond to the Product Owner role.

Prince2 is based on a set of principles, that are listed in the table below.

PrincipleDefinition
Continued business justificationA PRINCE2 project has continued business justification
Learn from experiencePRINCE2 project teams learn from previous experience (lessons are sought, recorded and acted upon throughout the life of the project)
Defined roles and responsibilitiesA PRINCE2 project has defined and agreed roles and responsibilities with an organizational structure that engages the business, user and supplier stakeholder interests
Manage by stagesA PRINCE2 project is planned, monitored and controlled on a stage-by-stage basis
Manage by exceptionA PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority
Focus on productsA PRINCE2 project focuses on the definition and delivery of products, in particular their quality requirements
Tailor to suit the project environmentPRINCE2 is tailored to suit the project’s size, environment, complexity, importance, capability and risk

These are compatible with Agile principles and practices like iterative development, the focus on working software, clear definition of roles and empowered teams. As long as the project stays within tolerance for budget and schedule, the teams can proceed in the way that they think is best.

In short, I don’t see any fundamental incompatibilities between Prince2 and Agile. I think the combination of these two can go a long way in addressing senior management concerns on for example development teams doing whatever they want or scope not being fixed up front that you sometimes hear when an organization wants to move to Agile.

No comments:

Post a Comment