PRINCE2 and SCRUM

Prince2 and Agile / Scrum Version 1.0 By Johann TambayahThere are many papers on the internet which detail how the agile methodology of Scrum could be integrated into Prince2 but from what I havefound many of these sites do not go into deeper detail on how this is to be achieved. Many of them suggest that Scrum should only be addressedin the ‘Managing Product Delivery’ process of Prince2 however whilst this is possible the author does not believe this is sufficient in its entirety.Before diving into detail on how this is to be accomplished (and more so tailoring Prince 2 to Scrum) we must ask ourselves why we would wantto integrate Scrum and Prince2.With the dawn of 2011 most job boards in the UK and Australia seem to be flooded with job descriptions for ‘agile project managers’ whereproject managers are sought with formal project management skills (such as those in Prince2 and via the PMP / PMBOK) as well as those withformal training in Scrum (the leading agile methodology today, preferably being Certified Scrum Masters). This is somewhat peculiar given theScrum framework removes the role of the project manager from its project environment. From the conversations I have had with suchorganisations that seek ‘agile project managers’ as well as recruitment agencies seeking to fill these roles, what I deduce is that mostorganisations are not entirely comfortable removing the role of the project manager from their organisation. This may be due to either resistanceto change or perhaps there are other reasons, such as Prince2 being considered the tried, tested and prevailing norm within government bodies inthe UK, Australia and certain parts of Europe. Prince2 does have its major successes and companies are not keen to waiver from this. Withoutfocusing on the justification of the role of a project manager within an organisation what must be remembered is that Prince2 is not a projectmanagement function alone. Prince2 is a framework for the entire organisation. Prince2 is an organisation structure that has the capacity todeliver projects successfully. It provides management frameworks and roles / responsibilities for project executives, programme management,users, suppliers, project managers, team leaders, etc.Prince2 states that a project must be tailored to fit its environment. Within this ‘tailoring’ it is possible to use Scrum to deliver projects. Whywould you want to integrate Prince2 and Scrum? Prince2 provides structure, roles, responsibilities, a framework and the necessarydocumentation that is required on many high-end projects such as government or funded NGO projects. Scrum provides a delivery mechanism 1|Page

built by the ‘builders’ that focuses on the best possible ‘building’ technique that places customer orientation as key and embraces change. Bothframeworks embrace change, customer orientation and delivering in stages or iterations.This document presents a framework for Prince2 and Scrum to exist and succeed in the same environment. It answers the questions – • Is it theoretically possible to implement Scrum within a Prince2 environment? • How do we implement Scrum within a Prince2 environment? • Does a project environment remain Prince2 when you implement Scrum?Please note that this document assumes the reader is familiar with Prince2 and Scrum terminologies and frameworks.Does a project environment remain Prince2 when you implement Scrum? For a project to be deemed Prince2 it must adhere to the 7 Prince2Principles. The table below details how Scrum integrates into the 7 Prince2 principles. Prince2 Principle Scrum IntegrationContinued business justification i.e. the Business Case for the Scrum encourages the Product Owner to revisit the product backlogproject must exist during the life cycle of the project throughout the project to ensure the requirements are prioritized according to the business justification and updates are made to the priority scale based on this. It is possible to change the Product Backlog items in order to ensure business justification.Learning from experience i.e. lessons from past projects are Scrum encourages a sprint retrospective at the end of each sprint where thedocumented and the knowledge passed on team asks itself ‘how could we have done this better?’ and this knowledge is documented for the next sprint or project. Scrum encourages cycles of adapting based on previous learning. 2|Page

Defined roles and responsibilities i.e. Project Executive, Project Scrum has its own set of defined roles and responsibilities e.g. ScrumManager, Senior User, Senior Supplier, Project Support, Project Master, Product Owner and team. Scrum does not use some of the Prince2Assurance, etc. roles however this would not be an issue when the two frameworks are integrated as the responsibilities are never compromised. Where certain roles are removed e.g. Team Leader; the responsibilities of this role are passed on to other roles.Managed by stages i.e. each project must have a minimum of 2 Scrum delivers in iterations called sprints which could be considered stagesmanagement stages (control points)Managed by exception i.e. if tolerances for time, cost, quality, Scrum manages exceptions by either placing incomplete sprints back on therisk, etc. are compromised, an exception must be raised by the product backlog or dealing with exceptions at sprint reviews by consultingproject manager to the project board with the Product Owner. The Product Backlog could be modified at any point to handle exceptions with close collaboration between the Scrum Master, the team and Product Owner.Focuses on products and their quality. This is documented in Scrum ensures that the team reviews the Product Backlog and converts this‘product based planning’ techniques where project and product into the Sprint Backlog. The Sprint Backlog lists tasks to be completeddescriptions detail acceptance criteria and quality expectations however prior to this the team must consult with the Product Owner onfor each deliverable. ‘user stories’ and acceptance criteria which will be used to develop the product and judge its quality at sprint reviews.Tailored to suit the particular project environment Scrum could be used within a tailored Prince2 solution as long as the Prince2 principles are not compromised. 3|Page

Hence it is absolutely possible to merge both the Prince2 and Scrum frameworks.Is it theoretically possible to implement Scrum within a Prince2 environment?Yes.How do we implement Scrum within a Prince2 environment?Prince2 is made up of 7 Principles, 7 Themes and 7 Processes. I will now discuss the Prince2 Themes and Processes detailing how Scrum couldbe implemented within Prince2. 4|Page

Prince2 ThemesWe will briefly discuss each Theme and determine how Scrum could be integrated within each Theme and more so, how Scrum complimentsPrince2.1. Business Case This theme answers the question - is the project is desirable, viable, feasible or achievable? The Business Case is the implementation of the Prince2 principle ‘is their continued business justification for the project?’ It dives into determining what the benefits for the project are, the reasons for undertaking the project, the costs involved, the business options, the timescale and the major risks. The Business Case for Scrum is determined by the product owner. The Product Owner presents a prioritised list of requirements to the Scrum team. The team works with the Product Owner to determine the Sprint Backlog which includes user stories and acceptance criteria. This process is similar to the product based planning approach used by Prince2. The Prince2 Business Case is a high-level document in the organisation and could certainly include the initial product backlog.2. Organisation Prince2 puts into place an organisational structure for projects. The Executive is the key decision maker on the project and the ultimate authority. The Senior User is the end-user representative of the project and the Senior Supplier is the representative of the project suppliers. These three key roles form the Project Board. The Project Manager reports to the Executive. The team reports to the Project Manager most often led by a Team Leader. In addition there are two more roles which are Project Assurance which act on behalf of the project board and may advise the Project Manager on certain aspects as well as conduct independent checks. The other role is the Change Authority which is capable of approving change requests in the absence of the project board. A Project Manager may 5|Page

also have a Project Support function to assist him or her in documentation and other administration functions. The major roles in Scrum are the Team, Product Owner and Scrum Master. The Scrum methodology removes the roles of the project managers and team leaders. The Prince2 Project Manager is responsible for planning, delegating, monitoring and controlling the project within tolerances and motivating team members. So how do we handle the clash in roles seen in the Prince2 and Scrum frameworks? The only solution here would be to administer a ‘give & take’ policy that is reasonable and amicable to both frameworks. As discussed previously Prince2 is an organisational framework for projects. Scrum could be used for the delivery of the project itself i.e. the teamwork; where the team leader could be played by the Scrum Master and the Project Manager would continue his/her work in the start-up of the project, its initiation, other Prince2 processes, stakeholder management, reporting to the board, assisting in the removal of impediments with the Scrum Master and motivating the team. For Scrum and Prince2 to work together the Project Manager would be required to let go of his/her responsibilities in the product delivery. The Product Owner role would ideally be played by the Prince2 Senior User as this individual would know the product best. However it is also possible for the Project Manager to play this role as he/she is involved in the early stages of the project together with the Senior Users in putting together the product descriptions or in this case the product backlog. The Project Manager could request the Senior Users to be present at Sprint Reviews.3. Quality The key purpose of this theme is to ensure the project delivers a product that is ‘fit for purpose’. Prince2 places a lot of emphasis on quality, as does Scrum. In Prince2 the Project Manager puts together a Quality Management Strategy which details what quality standards that will be implemented on the project, the records to be maintained and the responsibilities / roles. It details both in-process checks such as internal testing as well out-of- process checks such as formal Quality Review Techniques. It details the maintenance of a Quality Register which is a formal record for quality checks. Scrum details the use of test automation (in-process) during each Sprint and Sprint Reviews which follow very similar formats to the Prince2 Quality Review Technique. Prince2 and Scrum are very similar in their commitment to quality. 6|Page

4. Plans Plans in Prince2 are made using product based planning techniques. This involves breaking a project down into products and then breaking these products down into tasks. This is usually done at the very beginning of the project i.e. project initiation, and involves work being done by the Project Manager and Senior Users. This forms the Project Plan. Prince2 also uses stage plans, team plans, and exception plans (when project tolerances are threatened or change requests are made to the baseline). Prince2 requires the use of a project schedule and most often Gantt charts are used to track project progress (although tools and techniques for scheduling and monitoring progress are not specified). Scrum involves the team deciding on how much work they want to take on from the Sprint Backlog. This work is carried out in a sprint before the next sprint plan is produced. Products are delivered in iterations (which makes agile techniques such as Scrum very effective). Product burn down charts are maintained by the team and Sprint burn down charts are maintained by the product owner which reveal how long the project should take to complete. Prince2 and Scrum are similar in that they both involve stage plans or sprint plans and they both use product based planning techniques. If there is a change to the baseline requirements the Project Manager (Product Owner) would still need to provide an exception report to the Project Executive (ultimate authority) and the Project Board. Similarly if projects are taking longer than anticipated to complete or any other tolerances are threated, the Project Manager would need to provide an exception report to the Project Board. The Project Board could either approve or disapprove the report and if they wish to, a new exception plan or new baseline plan would be produced by the Project Manager. This new plan could be used to update the Product Backlog. It is possible for the Project Manager to maintain a high-level schedule which details tasks external to the delivery in detail e.g. prepare the product descriptions, prepare the End Project Report, recommend follow-on actions and prepare the Lessons Report. It is also possible for the Project Manager to update his/her schedule based on the burn down charts such that he/she is able to maintain a schedule and Gantt chart for delivery.5. Risk The Prince2 Project Manager is required to develop a Risk Management Strategy as well as open up a Risk Register. This involves determining the identification, assessment, planning, implementing and communicating of risks as per normal Prince2 operations together with detailing risk actionees, the risk appetite, etc. The Risk Register would log 7|Page

risks and detail mitigation plans. The only difference in the Scrum environment is if a risk does materialise its mitigation plan would also be placed on the Product Backlog for the team to commit to on their next sprint. This would be prioritised accordingly by the Project Manager / Product Owner.6. Change Prince2 suggests that any change to the baseline must be approved by the Project Board. A change could be a bug or off spec, a change to the baseline requirement itself or a problem / concern. Scrum’s call to fame is that change is possible at any time during the project other than for when a sprint is in progress. The Project Manager in the capacity of the Product Owner or in conjunction with the Senior User must document a change in the form of an Exception Report and once approved by the board have the team implement it on their next sprint if this is a priority. The Project Manager should still be able to manage a Prince2 Issue Register and capture and deal with change in this manner. The Scrum Master could also maintain this document listing impediments on the project which could include problems / concerns or bugs / off-specs. The Project Manager and Scrum Master would be able to work together in removing impediments and dealing with these issues.7. Progress The team in scrum does not report to the Project Manager or the Product Owner or the Scrum Master. This eliminates the Checkpoint Report of Prince2. However the same information could be captured from product burn down charts and sprint burn down charts. The Project Manager could use this information to produce his/her Highlight Report to the Project Board. This would also enable the Project Manager to track progress. The Prince2 lessons report and logs are similar to the sprint Retrospective and capture the same information. Schedules could be handled as per the suggestions under the Plan section above. 8|Page

Prince 2 ProcessesHaving spoken of Scrum and the Prince2 Themes let us have a look at the Prince2 Processes and the implications of working with Scrum.1. Starting up a project This process remains largely unchanged from the Prince2 norms. The Project Brief is prepared which is the inception of the project. The Project Board is setup and the Project Manager appointed. It is wise to decide on the roles of the Scrum Product Owner and Scrum Master. Previous lessons from projects are reviewed and it is also prudent to refer the previous Scrum sprint retrospective documents. The initial Product Backlog should be created at a higher level. The outline Business Case is prepared. In this Process make note of the ‘Project Approach’ which must detail the use of Scrum in delivery and its impact on Themes and Processes. Special care must be taken to note that Scrum education is begun at the Project Board and within this Process, such that the Project Board is aware of the intricacies and differences when contrasting with traditional non-agile methodologies such as the Waterfall model.2. Directing a project This process is widely unchanged e.g. authorising initiation, authorising the project, ad-hoc direction, authorise closure, etc. except in the case of authorising stage plans. The Project Board could be presented with the Product Backlog and explained what items are being delivered in the next sprint. The project board must be made aware of the Scrum methodology particularly in the case of the Senior User who will be expected to meet up with the team on Sprint Planning meetings and either take on the role of the Product Owner or assist the Project Manager (taking on the Product Owner role) in prioritising products and defining 9|Page

acceptance criteria for the sprint reviews.3. Initiating a project In this process the project manager would be expected to create the below documents taking Scrum into consideration – a) The Risk Management Strategy – stating changes suggested in the Risk theme b) Configuration Management Strategy – stating changes suggested in the Change theme c) Quality Management Strategy – stating changes suggested in the Quality theme d) Communication Management Strategy – stating changes suggested in the Organisation theme. The project manager would be expected to decipher which stakeholders require what information. It must be stated that reports such as the Checkpoint report will no longer be used and alternate reports comprising of information gathered from the burn down charts will be presented. e) Setup Project Controls – This details information such as the format and frequency of communication, the number of stages / sprints, project tolerances, etc. f) Creation of the project plan – stating changes suggested in the Plan theme. I would suggest conducting the ‘scrum kick off’ in this process. These documents form the Project Initiation Document in some organisations known as the Project Charter.4. Controlling a stage This stage has often been known as the day-to-day activities of the Project Manager. There are no Prince2 Work Packages in this model. The work to be done is presented in the form of a Product Backlog which is handed over to the team and 10 | P a g e

discussed at Sprint Planning Meetings. Sprint planning meetings are broken down into 2 parts – 1) In part 1 the team asks questions about the product backlog so that it can be broken down into tasks. 2) In part 2 the team decides on how to go about delivering the project and how much they will commit to a sprint As mentioned previously, the Product Backlog (which includes user stories and acceptance criteria) is broken down into a Sprint Backlog by the team. The team then proceeds to decide on how much work they will commit to a sprint and will inform the Product Owner of this. At the end of a sprint the Sprint Review takes places where products that are potentially shippable are presented to the Product Owner. The monitoring of progress is judged by the product and sprint burn down charts. This information details the project’s progress and estimated time of completion. This information could be summated in the Project Manager’s Highlight report to the Project Board. The project manager would be expected to maintain his Risk registers, Issue Registers and other documents as is the norm in Prince2.5. Managing Product This process could be widely implemented using Scrum. There are no Prince2 Team Plans as they are replaced byDelivery the Sprint Backlog, Product Backlog and burn down charts. Sprints are conducted (cycles of development, inspecting and adapting).6. Managing a stage The Sprint Review and Retrospective takes place here. boundary The (re)prioritised Product Backlog is revisited to determine what work is to be done next. The next Sprint Planning meeting is conducted. The Business case should be revisited to ensure the Product Backlog (which has possibly been changed) is still on path to produce the desired outcomes (business justification). 11 | P a g e

The project manager should produce his/her Prince2 End Stage Report which could include details on the Sprint Retrospective and Sprint Review as well as details on the next sprint.7. Closing a project This Process follows Prince2 i.e. prepare the End Project Report, prepare the follow-on-recommendations and other documents. The sprint retrospective is documented (Prince2 lessons report).The above should provide you with an idea on how to implement Scrum within a Prince2 environment. The key concept to keep in mind is that Scrum andPrince2 need to be tailored to the project environment. 12 | P a g e

BibliographyManaging Successful Projects with Prince2 2009 Manual, Office of Government Commerce, The Stationery Office; 2009 edition (January 6, 2009)The Scrum Primer – Version 1.2, 2010, Pete Deemer, Gabrielle Benefield, Craig Larman, Bas VoddeAbout the AuthorJohann Tambayah is a certified Prince2 Practitioner and a certified Scrum Master.He is a Senior Project Manager holding an MBA (Leicester) and BSc (Hons, London) with over 10 years of project management experience. He has workedfor large scale World Bank directed projects, online / e-Commerce projects and large scale government sector projects in Australia, UK and South Asia.Email: Johann@MasterBusinessChronicles.comwww.MasterBusinessChronicles.com-End- 13 | P a g e

http://www.masterbusinesschronicles.com	337
http://www.ikdoeprojecten.nl	1
http://translate.googleusercontent.com	1

PRINCE2 and SCRUM

by johann-tambayah on Apr 02, 2011

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 339

Statistics

PRINCE2 and SCRUM — Presentation Transcript