It was the marriage they said could never happen but AXELOS has managed it. What were thought to be two polar opposites, PRINCE2 – symbolizing control, accountability, order – and agile – symbolizing self-organization and equality, have been reconciled in the new PRINCE2 Agile™ guidance.
What is perhaps most surprising about this is how relatively few feathers have been ruffled on either side of the fence. A PRINCE2 vs agile conversation can escalate quickly in certain circles, as testified by the many heated discussions you will find across project management-themed internet forums. Yet beyond the outlying apprehension, there has not been an almighty wave of backlash greeting PRINCE2 Agile. This has been in no small part down to the amount of thought and consideration Keith Richards and his team have put into this. By thoroughly examining and honouring the ethos of both schools of thought they have shown how they can be thought of as natural bedfellows. What’s even more surprising and, indeed impressive, is that no principles on either side have been compromised; no square pegs have been forced into any round holes. Remarkably, nothing in PRINCE2 has had to be surgically removed in order for it to work in an agile context. All the principles, themes and even processes remain. For this feat alone, the authors deserve applause.
Interview with an Agile Coach: Mario Lucero
Date: July 2015, By Frank Turley
How did you start to become an Agile Coach?
I started working as Kanban facilitator for a Chilean startup that wanted to improve the workflow of requirements. That startup hired an Agile Coach to provide a great Kanban training and as I showed a great interest on Kanban I became as Kanban facilitator. Then I worked as Scrum Master for several years in medium and large companies dealing with remote team members (and Product Owners as well) and with all of this experience became an Agile Coach. Part of my duties is to help Scrum and Kanban teams to improve their performance and knowledge about Agile practices.
What are the most popular issues that companies are having?
One of the most popular issues is finding a good Product Owners because many companies prefer to assign a Business Analyst or Manager as Product Owner but most of the time they don’t have business knowledge. I have also suggested adding more Product Owners to some projects as the existing Product Owners working on to many different projects, so they missed many times Sprint Planning and Daily meeting.
What kind of projects are you involved with?
I used to work with startups where adopting Agile it is much easier than in big companies but now I am working with multinational companies from different areas such as financial and airlines where I have to deal with traditional mindset and professionals that don’t like to be self-organized.
What Agile techniques do you suggest people to start with?
Many companies are adopting Scrum only because Scrum is popular. I strongly recommend using Lean in order to remove the waste of your process and then start using Kanban. Why Kanban? Because Kanban is less disruptive than Scrum and last but not least, Kanban is simpler to understand and you don’t need to hire an Scrum Master and do many ceremonies (Sprint Planning, Sprint Review or Demo, Release Planning and so on).
What advise can you give a project manager who would like to introduce Agile into their company?
The best advice is to obtain the support of their Directors (or committee) because without it, Agile will fail. In addition, training (and the change as well) has to be done at top levels and then moving to the bottom. Next it is possible to convince the organization that Agile is for all of the areas of the company and not just the IT department.
– For example in the IT Department: you can improve the quality of your code by using:
– Pair Programming (I recommend this after a couple of months),
– Peer Review (it is very helpful for developers),
– Continuous Integration,
Automate test cases as soon as possible in order to improve the testing (if your tester can develop any piece of code you should mix developers and testers at the beginning)
What are the most popular questions that who are new to Agile ask?
Well, there are many but I chose the following:
1) What is a User Story?
The term “User Story” was first used Kent Beck in 1996, and became popular through its inclusion in the first Extreme Programming Project. There are two points that I would like to mention:
2) What is the best approach to deal with unfinished user stories?
Well, there are two approaches: One is to carry over the unfinished user stories to next Sprint and the other is to move all of the unfinished user stories to the Product Backlog so the Product Owner has to decide to include in the Sprint Backlog or not.
If you choose the second approach you have to live with this past and as soon as you want to finish those user stories nobody remembers what was done so you have to invest more time and effort to finish them.
On the other hand, if you choose the first approach you have to keep your eyes on these unfinished user stories in order to finish during the Sprint. If for any reason the owner (developers in charge of working on the user story) are not moving forward on the user story the Scrum Master should talk with the Product Owner in order to decide what other team members are available to finish it.
Furthermore, if you have many unfinished user stories at the end of each Sprint, the Scrum team has to analyze in the Retrospective what was wrong that every Sprint got many unfinished user stories. There are many reasons for this behavior such as the user story was bigger than planned, lack of expertise to develop the user story, incomplete user story or even worse unclear user story.
3) Do you re-estimate your story points during the sprint?
I agree hands down that we do not change story points but I would like to cite a scenario from a company that billed on story points. This company maintained team estimated story points (SPs) and what they could mutually agree to billing. Hence if a story was estimated at 5 SPs but turned out to be 13 SPs, the billing would be for 13 SPs while the team would still see 5 on the dashboard. This also worked visa-versa.
After they had a lot of conflicts they started billing on percentage of the product. It means they calculate what percent of the product was involved in each Sprint and then charge this amount of money (twenty percent of the development cost some dollars and so on).
4) What is the best length for a Sprint?
According many surveys and my own experience dealing with many Scrum teams with different kind of projects, the best length for a Sprint (or iteration as you can find in more Agile Software) is two weeks.
Why? Well, if you choose one week there is no enough time to deliver value to the Product Owner. On the other hand, if you choose four weeks, the Product Owner has to wait too long to receive anything and team members have to wait for a month to get important feedback, so the best time is two weeks.
Do you have a blog and how can people contact you?
Yes, my blog is www.mariolucero.cl with more than two hundreds articles (including book reviews) related to Agile, Lean, Kanban and Scrum. Furthermore, you can read any of my books on www.leanpub.com
The follow list shows the different books:
https://leanpub.com/theroleofproductowner this book is related to the important role of the Product Owner who acts in behalf of each stakeholders of the Product.
https://leanpub.com/theagileanti-manager on this book I renamed the role of Scrum Master as Agile Anti-Manager because he has to help team members in order they improve their performance.
https://leanpub.com/dealingwithtechnicaldebt this book attacks a controversial topic: The Technical Debt that IT Managers do not like to mention until they start getting complains from their clients daily.
https://leanpub.com/agilevirtualcoaching this book focus on a new tendency: working in a remote way as Agile Coach. Over and over companies want to cut their budget with cheaper options in order to hire the best professionals but with the lowest budget.
https://leanpub.com/firstkanban this book explains why every company that moves from Waterfall to Agile needs to start using Kanban instead of Scrum.
https://leanpub.com/theproductownertoolkit this book comprises many useful techniques for Product Owners who need to communicate the Product Vision to every stakeholders who most of the time are not co-located with him.
https://leanpub.com/fakeagileroles this book touch a controversial topic that is on the headlines today. What are the original and unique Agile roles? Well, this short book shows the original and the fake roles that you will run into in many organizations.
Appendix C of the PRINCE2 Agile Guide contains a checklist that can be used at any time during a project to assess how well the project is going from an agile perspective.
In fact I recommend that you read these pages to get a better understanding of PRINCE2 before starting to read the rest of the manual and it provides an excellent summary of what is important to get right when implementing and running PRINCE2 Agile.
Note: This is not a replace for the PRINCE2 Checklist
You can just use a simple Yes or No when answering the questions and then will then provide you with a general overview of the health of the project in Agile Terms.
C.1 IS THE FOLLOWING HAPPENING?
1. Collaboration, trust and a no-blame culture exist.
2. Self-organization is predominant and is supported by the project management team. There is a culture of inspect and adapt and continual improvement.
3. Transparency prevails.
4. Teams are regularly talking about the delivery of value and benefits.
5. There is an attitude of keeping things simple.
6. All stakeholders impacted by the project are being kept up to date.
7. The product board is frequently interacting with the people involved on the project. Planning and work assignment are being carried out collaboratively.
8. The Pastor of Fun is well-organized.
1. People are happy and work is enjoyable.
2. The team is stable, ring-fenced and working well together.
3. The project is responsive to change and is change friendly.
4. The customer is involved and engaged at all levels.
5. A blended view prevails that takes into account the diverse views of the customer on a project.
6. The desired outcome, as well as the desired output, is clear to everyone.
7. There is a thirst for feedback and a collective desire to find out what the customer really wants.
8. Agile learning’s are being moved around the organization (e.g. by project support).
9. Communication is very good and fast-moving.
10. Control has a light touch and people are empowered.
11. Musts really are musts.
12. The project management team and the delivery teams are ‘understanding agile’ and not just ‘doing agile’.
13. The overriding mind-set of the people on the project is an agile one.
14. Frequent releases are happening that are ideally put into operational use (or a staging area if the live environment is not ready).
15. The five targets of what to fix and what to flex are understood by all.
16. Significant events become routine because they happen frequently (e.g. stage boundaries or release reviews).
17. All roles are clearly defined and understood (and this is taking into account that the mapping of the agile roles to PRINCE2 is not necessarily straightforward).
18. PRINCE2 is seen as agile.
1. Management by exception is working fully.
2. The level of control is appropriate to the level of uncertainty.
3. The work package interface is happening well. It is smooth, has clarity and is not a source of communication problems.
4. Requirements and user stories are explored and not just followed blindly.
5. The way of working is typically iterative and incremental, and benefits are being delivered at several points throughout the project.
6. There are clear definitions of ‘done’ and ‘ready’, and working agreements are transparent.
7. Planning and work are feature-focused and timeboxed.
8. The MVP is clear to everyone, and it is understood that its role on the project is to help with learning.
9. Quality checking and testing includes independent quality checking and testing.
10. Quality checking is happening as you go and sometimes even drives the building of the products.
11. Planning is happening well in relation to all planning horizons (i.e. short term, medium term and long term) and with respect to the appropriate level of uncertainty.
12. A lot of planning is being done empirically.
13. Early requirements are based at a level that avoids unnecessary detail. Project assurance is adding value from an agile perspective.
1. Prioritization is happening continually, and timeboxes are not being extended or having people added to them. Information is very visible (e.g. on the walls) and is kept up to date.
2. When prioritizing, teams are looking at both scope and quality criteria.
3. Acceptance criteria always exist and are well written.
4. Estimation is a team-based activity.
5. Documentation is Lean, and the right channels are being used for each type of message.
6. Demos take place frequently.
7. Some risks are being mitigated by the use of spikes, prototypes and experiments.
8. Burn charts are being widely used and progress is clear to see.
9. User stories are being used to stimulate conversation and communication.
10. When Kanban is used, a holistic approach is adopted – not just a Kanban board.
11. Workshops are a regular occurrence and are being used appropriately.
12. Stand-ups are happening daily and are taking place quickly (i.e. lasting 15 minutes or less, perhaps 10). People are clear on terms like ‘requirement’, ‘user story’, ‘feature’ and ‘epic’.
13. Product descriptions have been written at the appropriate level and with flexibility as to quality criteria.
Why this blog post on the Cynefin framework?
The Cynefin framework is included in the PRINCE2 Agile Guide
What does the word ”Cynefin” mean?
The word “Cynefin”, pronounced ki-neh-vin, is a Welsh word meaning something like ‘habitat’ or ‘place’. The term was chosen by the Dave Snowdon to describe a perspective on the evolutionary nature of complex systems, including their inherent uncertainty
Origins of Cynefin
Cynefin was first developed by Dave Snowden in 1999 in the context of knowledge management and organisational strategy.
What is Cynefin?
Cynefin is a decision framework that recognises the causal differences that exist between different types of systems, proposing new approaches to decision making in complex social environments. Cynefin is also a sense-making model, not a categorisation model.
In a categorisation model, the framework precedes the data. This is good for exploitation but not exploration. In a sense-making model the data precedes the framework, making it good for exploration
The Cynefin framework has five domains. The first four domains are:
1) Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense – Categorise – Respond and we can apply best practice.
2) Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense – Analyze – Respond and we can apply good practice.
3) Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe – Sense – Respond and we can sense emergent
4) Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act – Sense – Respond and we can discover novel practice.
The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.
Chapter 25 of the new PRINCE2 Agile Guide is focused on Requirements and this includes the MoSCoW which is used for prioritisation (Prioritise Requirements – MoSCoW)
This chapter describes how to define and prioritize requirements in terms that are compatible with agile ways of working.
Here is a 20 minute video explains one of the best prioritization techniques which is MoSCoW and is use to prioritise requirements. Understanding and using this technique is really helpful for IT projects, as long as other kinds of projects.
Besides the use of MoSCoW prioritization for management of scope, as it’s done in some Agile methods, it can also be used for prioritization of acceptance criteria, as recommended in PRINCE2.
So, hope you would enjoy this video and find it helpful:
This use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting and he subsequently donated the intellectual property rights to the Dynamic Systems Development Method (DSDM) Consortium.
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements. MoSCoW is also seen as a core aspect of rapid application development (RAD) software development processes and agile software development techniques.
MoSCoW is a technique used in management, business analysis, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. This is also known as MoSCoW prioritization or MoSCoW analysis.
See the PRINCE2 Agile Group on LinkedIn for more information
Page: Prioritise Requirements – MoSCoW
Some good news, Axelos have given us a preview of the new PRINCE2 Agile guide. This preview also includes a simple high level overview of each chapter
So you can read the first three chapters of the PRINCE2 Agile guide and remember the publication date is 14 June 2015
Blending Agile with PRINCE2 processes and themes will likely be a challenge for both PRINCE2 and Agile practitioners alike to fully embrace. Many may see it as adding a set of heavy processes to Agile. However, as they come to understand what PRINCE2 Agile offers both communities, we believe that they will overcome any initial scepticism and recognize the value PRINCE2 Agile brings to both. No-one thought you could blend ITIL and Agile but DevOps is proof that old practices can indeed find new friends.
As already stated, this is just the beginning of a broader push to integrate different methodologies and practices that will enable practitioners to get the most out of their existing knowledge and experience while they continue to identify areas for emerging practice – but with a very definite emphasis on incorporating Agile thinking throughout.
Looking at the new PRINCE2 Agile qualification I have two initial observations: the first is that it was long overdue. Many of us have long known that Agile and PRINCE2 could and should be blended. The second is now that we have done the blending, we know Agile and PRINCE2 are, in fact, quite complementary, just as PRINCE2 and the PMBOK are. A good balance has been struck between the two; the blend is far better than simply the sum of two parts.
By Larry Cooper – Senior Partner, BSSNexus Global Inc.
Authors: Larry Cooper and Jen Stone
The title of this book, Agile Value Delivery: Beyond the Numbers, recognizes that linear extrapolations from past successes—which may have been a successful formula in recent times—is no longer a practical guide for managers or workers in a post digital world. Simply stated, the digital revolution has thrust us suddenly and rapidly into in a new world with new rules. This book is a practical behavioral guide to those who want to master these new rules. (from our Forward by Rod Collins)
About the book
We decided to write this book to illustrate how Agile Practices, and more importantly Agile thinking, can be combined with those from Outcomes, Portfolio, Programme and Project Management to successfully and consistently deliver Value into Business Operations.
If you are a Portfolio, Programme or Project Manager and want to know which Agile practices would apply to your space then this book is for you. If you are on an Agile team and want to know how Portfolio, Programme or Project management need to change to support you then we’ve got you covered.
If you are in HR or Finance and are wondering how all this Agile stuff really affects you then you really need to read Chapters 2, 3 and 9. It’s not just a technical thing – it’s a cultural and a money thing.
If you still believe in waterfall and think best practices are awesome, check out Chapter 3 and be stunned. They’re far from awesome.
The website that will accompany the book. www.NextGenAgile.com, will provide additional collateral such as practice descriptions and how-to’s, tools, templates, articles, etc.
This is Release 1 of the book. We hope to do two additional releases in the next year.
See link for more information: https://leanpub.com/agilevaluedelivery-beyondthenumbers
This is an interview with Keith Richards by Frank Turley on May 2015 about PRINCE2 Agile. Keith is its lead author.
Update: The release date has been updated to June 24th.
And here you are, the complete interview:
And if you wish, here’s the transcript:
Frank: Welcome to this podcast interview, and we’re going to talk to the lead author of PRINCE2 Agile, Keith Richards. Keith is founder and director of Agile KRC, which is a well known company in the agile and lean world. He is both a PRINCE2 trainer and DSDM agile trainer, and actually has written the first book on PRINCE2 and agile in 2007 with DSDM in turn. He was also very involved in the development of agile PM in 2010 and in 2011 he received the award for the Most Valuable Agile Player for all his efforts in everything agile. And this is why he was selected by AXELOS to be the lead author for PRINCE2 Agile.
Okay Keith, nice to talk to you. I’ve been wanting to do this interview for a while since I heard of PRINCE2 Agile and thanks for joining us.
Keith: No problem at all.
Frank: Great. So I got some questions for you. First of all Keith, how do you define agile?
Keith: That’s an excellent question, and a lot of the work that went into PRINCE2 Agile was actually about defining agile. The way it’s defined in PRINCE2 Agile is you’re like a family of frameworks, behaviors, concepts, and techniques. And the reason why we’ve done that in PRINCE2 Agile is because there’s no clear, single definition of what agile is and a lot of people see it differently. A lot of people point to the agile manifesto, but if you read the agile manifesto carefully, and I don’t mean pedantically, it’s very much about software and it’s actually about time-boxing and two weeks work packages. And really that excludes quite a lot of the agile family. That’s how PRINCE2 Agile has defined agile but it’s quite a complicated area.
Frank: Okay good, thanks for that. Now the big question is when is the release date for PRINCE2 Agile? That’s the date of the manual and certification date.
Keith: To my knowledge, and I have no reason to believe this is going to change at this late stage but it’s June 12th.
Frank: June 12th, okay so that’s when the manual will be available for download. Is that what you mean?
Keith: I don’t know if it’s downloadable, but it’s certainly being published, printed. You can buy it. Now, from a point of view of a training course, theoretically you could then train on that same day but the delegates wouldn’t have seen the manual if your training organization wants to have the manual given out for pre-readings. So maybe within a week or so you can actually start training in it.
Frank: Okay, good. Alright, thanks. What are the main benefits of PRINCE2 Agile to Prince?
Keith: A very important caveat you’ve put on the end there is actually to Prince. The whole concept of PRINCE2 Agile is to create an extension to PRINCE2, so it’s configuring, tailoring, adjusting PRINCE2 to run in an agile setting. The benefit is if you’re a PRINCE2 organization and you want to be more agile in the way you work, then this is the product for you. If you are encountering agile and you know PRINCE2 and you’re not quite sure how to combine with it and blend with it and react to it, then again that is what the product is aimed at. So it’s aimed at the PRINCE2 community and it’s how to run your projects in a more agile way and how to operate your projects in an agile context.
Frank: Okay, maybe just jump on then to the next related question on that. Can you use PRINCE2 Agile on its own or do you always need PRINCE2? How does it fit? Can you give me a picture of that?
Keith: Yeah. I think the best way is to say, and I don’t want to refrain. It’s almost the question doesn’t make sense, as in if you’re doing Prince, you’re doing Prince. And what PRINCE2 Agile is a way to adjust and configure PRINCE2 to operate in an agile context. Your question is valid and it’s often asked. It’s not a question of “do I put PRINCE2 on the side now and I run this different thing called PRINCE2 Agile?” That is not what you’re doing. You are still running Prince. One of the biggest findings and slightly surprising findings was that there is nothing that you need to remove from PRINCE2 to operate in an agile environment. It was quite an interesting moment when the team started to realize that PRINCE2 is already agile-enabled. It’s just a question of adding adjustments to it and tailoring so that it works in an agile context. There’s a very important point here, and that is that there was a rewrite of PRINCE2 in 2009 and what the team did, lead by Andy Murray and I think there was at least 100 people involved in that. What they did was make sure that PRINCE2 was agile-enabled. So they removed some of the blockers and problem areas with PRINCE2, such as there was no prioritization technique in there and such as it was very much focused on time and costs in terms of the tolerances. Now they did other things as well, but they smoothed out what are known as the aspects, so when you talk about things like time-cost-quality benefit, risk and scope, that they leveled those out to make them all equal, whereas if you go back to what was the red book in terms of PRINCE2, it was very much written in a time and cost focused way. I’m sure you’re aware when you’re working in agile, you fix time – over 2 weeks and 3 months or what have you – and you fix resources. PRINCE2 2009 was agile-enabled. So all we needed to do with this product was to play to the existing PRINCE2 and tailor it, configure it to run in an agile setting.
Frank: Okay. So it’s like as if you’ve documented PRINCE2 from an agile point of view or tailored PRINCE2 to run in agile project and documented that.
Keith: Yes it’s the latter. The questions you’re asking are quite complex because we struggled at the beginning of this project, because are we trying to make PRINCE2 more agile or are we trying to apply agile to PRINCE2? Literally, is this agile PRINCE2 or is this PRINCE2 agile? And actually what it was, was PRINCE2 is PRINCE2. We then need to add information to how you would run this in an agile context.
Frank: Alright, thanks for that. But I think lots of people will have the same kinds of questions.
Keith: Your questions are very good. The earlier questions was a little bit an unusual question but trust me, I was asking the same questions a year ago, and that’s why the project itself and the product was quite complicated to build and define because of the sort of questions you’re asking.
Frank: Yeah. Okay, well that brings me to the next question. What were the biggest challenges in trying to…well the question is to combine PRINCE2 and agile but actually to tailor PRINCE2 to run agile projects.
Keith: Yeah. The biggest problem was actually trying to define what we are trying to do because fundamentally there is nothing wrong with PRINCE2. You don’t remove anything from PRINCE2 to run it in agile. What a lot of people get wrong with PRINCE2 is what I call the stereotyping. People see PRINCE2 as waterfall or traditional or command and control, and it’s actually completely false and untrue. I think you could’ve said that about the previous version, what’s called the red manual. You could’ve said some of that. Bur PRINCE2 is completely neutral on your style, of how you manage. You can run it waterfall. You can run it agile. You can do whatever you want. When we got over those hurdles, which were quite problematic, the next thing we hit was canvassing views and collaborators. We dealt with at least about 40 people. And the next biggest problem was getting 40 people to agree on certain fundamental things, for example your earlier question like “what is agile?” And when you got 40 people from all agile spectrum, project manager spectrum, and I always use the example of a Venn diagram. If you drew a Venn diagram and plotted everyone’s views, you would have nothing in the middle because everyone had such diverse opinions. And the biggest problem was trying to rationalize and consolidate that stuff, which was a – great fun, but b – very difficult. That was the biggest single problem. What is agile? What’s good agile? But alternately also quite a lot of fun.
Frank: Good, okay. Now from the process model point of view, what does PRINCE2 Agile look like in the initiation stage?
Keith: That’s a good question because part of the difficulty with writing the product was you had to write it from a view of what do you find when you’re using PRINCE2. So if you’re in a very basic agile environment, you might have very little that’s going on in the initiation stage, and therefore PRINCE2 brings a lot of control and formality and some rigor to starting your projects of well. It might be that you’re dealing with an organization that’s got some sort of agile maturity and they’re using things, concepts like discovery, visioning, sprint zero. And again this is where you have to then map and tailor PRINCE2 accordingly. So what we did with processes was make sure that there’s a section on what you may find and then we explain in PRINCE2 how you adjust it. But importantly, you don’t remove the PID. What you do is you say “what does the PID look like in an agile context?” The tailoring was how you would actually create a PID, for example. It might be a lot more informal. You might be making use of things like information radiators. You would not be going into detailed requirements at this stage. This is the sort of tailoring guidance that will be going into SU and IP, those early processes.
Frank: Okay, already. So you get across the idea that they don’t need to define everything upfront in order to get starters.
Keith: Yeah. A – that’s common sense. B – PRINCE2 doesn’t actually say anything other than don’t do too much work early on because it might be wrong. But you really have to spell it out in an agile context, and this gives you maybe an indication of what the tailoring involves, is that we do not want detailed requirements upfront because we want the things to evolve and emerge as we go through the project and react. This is the sort of guidance we will be going, so that’s correct, yeah.
Frank: And what about the controlling stage? What does PRINCE2 Agile look like in the controlling stage area?
Keith: Again, we’re giving advice to project managers what it might look like. So for example if you’re used to project managing from a Gantt chart and you’re into time and cost, we’re saying agile will be working it differently. The delivery teams are going to be working to work packages when they’re reporting to you through checkpoint reports. These might be in a form of burned down charts or information radiators. Again, a lot of the work with the processes is what you might find and how to respond to it, but also to say as a project manager you can work in a more agile way. When you’re managing a stage, why not manage it with a burn down chart. Again, you have to be careful. You don’t want to be showing a burn down chart to a board if they just don’t understand what they are. Again, that depends on how agile the project board are or how agile and how mature in an agile way the organization you’re dealing with, so that is.
Frank: Alright, and I presume that’s the same goals for the stage boundary process as well.
Keith: One of the very complicated areas is actually around this concept of stages; the teamwork on it quite a lot. The conclusion was that there isn’t really anything in agile that is absolutely identical to the PRINCE2 concept of a stage. A stage is very much about project viability, and the nearest thing in agile would be something like maybe a release or the idea of stopping delivering because the value is tailing off, but the who mechanism of the stage boundary is not really something that there is an identical manifestation of out in agile. This actually, I think, is quite powerful from a PRINCE2 point of view because it really does give some more rigor and control in an agile environment. But again, we played around with that in the book. There’s nothing wrong with value. There’s nothing wrong with saying “hang on; I think I’ll stop now. We’ve delivered enough value.” But in a project context, that’s a little bit more tricky because projects are finite and we need to define how far we’re going to let the project manager run the project in terms of managing both section.
Frank: I see. That’s good to know. Actually a stage then it will not be linked to a sprint. There can be multiple sprints within one stage and I think that’s good what you said when you said the stage might be seen as a release from an agile point of view.
Keith: Yeah. Again, I’m hoping I’m giving you a favor, Frank, with some of the problems we have because you got to remember that one, if I go to an organization and they’re talking about a release, what are they talking about? Because they not release every three months, in which case you can link it to a stage, perhaps quite comfortably. But you might go to another organization and they’re releasing every week or they’re releasing every day. We got to be very careful with the terminology but the big learning point is that the management stage boundary, you start with that and you fit your releases and your time box or time boxes or sprints into that structure.
Frank: Okay thank you. The next point is the project management role. How has that changed?
Keith: Well that’s the most fascinating part of some of the work we did in the organization theme, is that some agile people do not believe in the role project manager anymore. PRINCE2 obviously does, or it will get into a bit of a problem. But we spent quite a bit of time working on the mapping, and the classic is where does the Scrum master fit? Is the Scrum master, in effect, now going to be the project manager? The simple answer is no because the Scrum master needs to be down in the delivery teams. The problem you have is on a small project or what we call a one-team project, then you have a PM/TM, if you understand me. Where does the Scrum master fit there? The mapping is actually quite difficult because a lot of agile belief systems are about self organization and equal teams and coaching, and some are very much against this idea of being managed. So we have to spend quite a bit of time playing. We haven’t seen manager role maps to the agile roles because as I’m sure you’re aware, the product owner in agile has quite a lot of control. You could say they do some of the planning. You could say they’re in fact in charge of direction at times. This is one of the hardest areas. To cut a very long, complicated discussion short, it is not a simple mapping. The product owner and Scrum master are, in effect, you have to sort of combine the managers and apply them to the situation accordingly. But as I’m sure you’re aware also there is no project manager role in Scrum or Kanban.
Frank: Alright, thank you. Management products, how have they changed? Are they simplified a bit or are they left up to how you want to tailor them?
Keith: It’s the latter. Again, to sort of repeat, we’re looking at the management products. You don’t remove any of them. You still need all of them. Mainly the guidance is about the formality and what they might look like. You may need to add a little bit to some of them. Agile is very much about the early delivery of benefits and benefits realization. So sometimes you need to add maybe another bullet point to some of these management products, and again that advice is given in the manual. You could have situations. If I give you one example, if you’re trying to give a highlight report to the project board, they might be able to come into the project room and pull information from an information radiator, for example. We got to be careful here because a – can they do that? B – do they know what they’re looking for? C – is all the information they need on the information radiator? Maybe it is, maybe it isn’t. We spent quite a bit of time explaining that there are many ways to represent the management products, and again this isn’t a PRINCE2 Agile point. It’s a PRINCE2 point, that actually these management products are information sets. They don’t have to be documents anyway; the stereotyping of PRINCE2 that it’s a lot of documentation. It’s up to you how you want to represent that information.
Frank: Okay. One of the things I like about PRINCE2 2009 is their benefits management and the benefits review plan. One of the things I like about Scrum and agile is the whole idea of creating value and showing this. Are these very much aligned, these documents?
Keith: Yes they are, and you’re picking a good example there of where Agile is very much about benefits, and therefore when we talk about business case and early [19:36] benefits and the benefits review plan, we got to make sure that this sort of constant flow of value is represented. Another thing that came out was if you look at PRINCE2, it’s talking about benefits, benefits, benefits. And if you go after agile, they’re talking value, value, value. Although they’re not completely identical, they’re more or less the same thing. And therefore if you’re a PRINCE2 organization and you want to become more agile or you’re encountering agile teams that are saying agile things at you, what the manual is trying to give you is guidance on what you’re going to hear and what it means. If your delivery team is talking about value and you want to talk about benefits, just make sure the wording is okay and we’re all on the same page because as I say, they are not identical but they are so similar that we’re really talking about the same thing.
Frank: Okay. Is PRINCE2 Agile mainly prepared for companies who already using PRINCE2 and want to become agile or do you prescribe it to a company that has not used it before?
Keith: The short answer to that question, because that’s quite a big question actually, is the reason PRINCE2 Agile exists is because people were saying “look, we’re using PRINCE2 and we want to know how to use it in an agile setting.” So it is aimed at PRINCE2 organizations, it’s aimed at PRINCE2 practitioners. And that is where we are at the moment. So that is if you like the customer-driven need is to create this product. Now where that goes, say this time next year, I don’t actually know to be honest, because it is aimed at the PRINCE2 community. You’re using PRINCE2. You want to use it in an agile setting. If you’re an organization that hasn’t got PRINCE2 in it and you haven’t really got any project management disciplines, one route would be to go and get PRINCE2 trained and then get PRINCE2 Agile trained. So that would be a completely valid route.
Frank: That’s why I was surprised to see that in order to get the PRINCE2 Agile certification, you have to be a PRINCE2 practitioner, which I think is limiting the audience of PRINCE2 Agile. Can you respond to that?
Keith: Yes, I totally agree. As I say, I’m working for AXELOS. AXELOS asked me to do certain things and lead the team and I deliver to what they are asking and what they’re seeing in the marketplace. But I think you’re making a very valid point. It is restricting and they’re deliberately restricting it at the moment because they want value added to training companies and PRINCE2 community. And that’s why I’m saying where we are next year, and I honestly can’t guess at the moment, really. Maybe because I’m quite tired after having spent a year on it, but it could be that things do change but it will change on the basis that the community or the customers are saying a bit like you’ve just asked. There’s a gap here. I want to get to this and I don’t want to go via the PRINCE2 route. So what can I do? This will be driven by feedback on PRINCE2 Agile, feedback from the marketplace, and AXELOS will just respond to that. I agree with the sentiment of your question there, and I don’t know how this will play out.
Frank: Alright, okay thanks for that. The very last question then is how similar is PRINCE2 Agile to Agile PM?
Keith: it’s very similar. I would say very, very similar. And this is going back to your previous question. It might be that if you’re not a PRINCE2 organization and you’re looking to go agile with your projects, you can go down the Agile PM route. You could go down the PRINCE2 and PRINCE2 Agile route. One thing I would say is if you’re a PRINCE2 organization or a PRINCE2 practitioner and you wanted to go down an agile route, I can’t see any other route than going down PRINCE2 Agile. That makes the most sense. The reason they’re very similar is they’re both agile in a project context. They’ve got very similar structures. I don’t know if you are aware Frank, I was the lead author for DSDM and Agile PM back in 2007, so I know both methods in complete detail. They’re doing the same thing. They do it in a same way. They’re in exactly the same space. An organization isn’t going to want Agile PM and PRINCE2 Agile. That wouldn’t make any sense. But then some organizations are going to want to go down on Agile PM route. Some organizations might want to go down on PRINCE2 Agile route. They are, I would say mutually exclusive because they’re basically doing the same job.
Frank: Alright, great. Good! That’s it. Keith, I think you have a webinar coming up as well soon.
Keith: That’s correct. We got a webinar on the 28th of May. I don’t know if you listen to any of our webinars, Frank, but they do…
Frank: Yes I do. I find them brilliant. And they’re on YouTube and you’re very, very good. I’m a big fan.
Keith: You’re very kind to me. I have to say we absolutely love doing the webinars. We really enjoy them. They don’t always quite go to plan and that amuses a lot of the people who listen sometime, but we have hundreds and hundreds of people that sign up for them, and we really enjoy them. They’re free. We give quite a lot of information away. And we even had one customer saying that they are so good they don’t need to get any consultants in, which is a little bit frustrating from a business perspective. But we don’t mind. We enjoy doing them. Thanks for mentioning it.
Frank: I’ll put the URL for the webinar on the posting as well. Keith, thank you very, very much for this interview. Thank you as well for being the lead author for PRINCE2 Agile and we look forward to…the date again was, for the release?
Keith: June 12th is the release.
Frank: June 12th, okay good. Alright, thank you Keith.
Keith: And thank you very much to you, Frank. And I see some of the stuff you write and present as well, in the early days of looking at this I did come across some of your stuff as well, so it’s really good stuff that you’re doing too and it’s been great to link up on this chat. Thanks very much.
Frank: You’re welcome. Bye.
If you like this article then thanks for leaving a comment or sharing.