1. According to Scrum a project doesn’t need a Project Manager
Scrum is described as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value‘. Scrum is single team oriented, and has a limited role set: developer (determines how to deliver the products), Scrum Master (to facilitate the Scrum process), and Product Owner (determines what products to deliver in what order according to highest added value). The Scrum Guide doesn’t speak of other roles or contexts, but that doesn’t prove or forbid anything. Just like Scrum doesn’t tell you to wake up in the morning and drive carefully to your work (both important to reach your fellow team members), the Scrum framework is simply not a project management method. Several characteristics distinguish project work from business as usual:
- change: projects are the means by which we introduce change;
- temporary: projects should have a defined start and end;
- cross-functional: projects involve a team of people with different skills working together tro introduce a change that will impact others outside the team;
- unique: every project is unique;
- uncertainty: projects are risky. Threats and opportunities will be encountered over and above those we typically encounter in a business as usual context.
Project management is the planning, delegating, monitoring and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality, scope, benefits and risks. The one in charge of project management is….the Project Manager.
2. PRINCE2 belongs to the traditional project management methods
If you think PRINCE2 of a traditional project management approach in the stereotypical sense of being predominantly ‘waterfall’,’big design upfront’, ‘bureaucratic’ and using a ‘command and control’ culture, you’re wrong. PRINCE2 doesn’t suggest that a project should be run in this way. Much of its guidance is to the contrary. Tailoring PRINCE2 to suit the project environment is one of its core principles. If PRINCE2 is not tailored, it is unlikely that the project management effort and approach are appropriate for the need of the project. Tailoring requires the Project Manager and the Project Board to think upfront, and decide on how the method will be applied, for which guidance is provided. When tailoring PRINCE2, it is important to remember that it requires information (not necessarily documents) and decisions (not necessarily meetings).
3. PRINCE2 is not agile itself
PRINCE2, especially since Managing Successful Projects with PRINCE2 2009 Edition, is based on a set of 7 principles which should sound familiar for readers that not only know the Agile Manifesto (and apply it according to the phrases preceding and following the 4 statements), but also the 12 Principles of Agile Software.
- A PRINCE2 project has continued business justification.
- PRINCE2 project teams learn from previous experiences (lessons are sought, recorded and acted upon throughout the life of the project).
- A PRINCE2 project has defined and agreed roles and responsibilities within an organization structure that engages the business, user and supplier stakeholder interests.
- A PRINCE2 project is planned, monitored, and controlled on a stage-by-stage basis (management by stages).
- A PRINCE2 project has defined tolerances for each project objective (scope, quality, time, costs, benefits, risks) to establish limits of delegated authority (management by exception).
- A PRINCE2 project focuses on the definition and delivery of products, in particular their scope and quality requirements.
- PRINCE2 is tailored to suit the project’s environment, size, complexity, importance, capability and risk.
The PRINCE2 manual is filled with good and best practices like planning on a detail that makes sense, quality inspection, adapting the course of action, keeping track of targeted benefits and only delivering products that meet the customer’s expectation, both management and specialist products. Note that PRINCE2 can be applied to any kind of project, not just IT or software development. Though agile frameworks like Scrum are used outside software development nowadays, the frameworks and Agile Manifesto plus Principles still are have very strong connections with software development.
4. PRINCE2 can be combined with agile frameworks like Scrum or Kanban
It’s the way I thought it could be done for years. Keep PRINCE2 for managing the project, and support the use of Scrum or Kanban in the Managing Product Delivery process. Delegate the ‘how’ to the Team Manager, and avoid attempts to come up with detailed plans for the next 18 months. PRINCE2 Agile (2015) is the first extension module to the PRINCE2 method. It values both PRINCE2 and agile. The strength of PRINCE2 lies in areas of project direction and project management. However it provides little focus on the field of product delivery. Conversely, agile has a very strong focus on product delivery but relatively little on project direction and project management. Instead of distinguishing methods or frameworks working in parallel, PRINCE2 Agile, sees the combination as a blend and a mixture. Those directing and managing a project in a agile context need to adopt agile disciplines and behaviours. Equally, those using agile to deliver need to integrate seamlessly with the PRINCE2 ethos of staying in control by empowering people and ensuring that the project remains viable.
5. Applying agile techniques means you’re agile
Attaching wings to your arms and flapping them fast while jumping from the rooftop certainly isn’t enough to be a bird. PRINCE2 Agile considers agile as a family of agile behaviours, concepts, frameworks, and techniques.
- behaviours: examples are collaboration, self-organization, customer-focus, empowerment, trust instead of blame. Sometimes these behaviours are called principles, values or mind sets.
- concepts: examples are prioritize what is delivered, iterative and incremental work, limit work in progress, kaizen, transparency, inspect and adapt. Sometimes thse concepts are called fundamentals or pillars.
- frameworks: examples are eXtreme Programming (XP), Scrum, Kanban, Lean, Scaled Agile Framework (SAFe), and DevOps.
- techniques: examples are burn chart, daily stand-up, timeboxing, user stories, workshops, and retrospective. Sometimes these techniques are called practices or tools.