Tag: prince2 agile

The marriage between PRINCE2® and agile – An ATO’s view

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.

See rest of the article 

 

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:

  • User Stories represent requirements in agile
  • A story is an artifact that aims to:
    • Describe briefly, a user scenario or user operation, often in one to two sentences
    • Stimulate dialog between the customer and the development team.
    • Outline strict success criteria

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.

PRINCE2 Agile Health Check

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.

PRINCE2Agile.pm

C.1 IS THE FOLLOWING HAPPENING?

C.1.1 Behaviors
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.

C.1.2 Environment
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.


C.1.3 Process
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.

C.1.4 Techniques
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

PRINCE2 Agile Cynefin

PRINCE2 Agile Cynefin

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.

Prioritise Requirements – MoSCoW

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.

MoSCoW stands for the following priority groups:

  • M (must have) – Features you must have in the final solution and it would be useless otherwise.  (Prioritise Requirements – MoSCoW)
  • S (should have) – Features you should have in the final solution and you would get into problem otherwise. However, you can find a workaround for the problem (do it manually, use another solution in parallel, etc).
  • C (Could have) – Nice features. You won’t have any problems if you don’t have them in your final solution.
  • W (Won’t have this time) – Features that you’re not planning to deliver this time.

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

PRINCE2 Agile Guide

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

Download from the AXELOS website

 

 

 

PRINCE2 Agile – the Structure

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.

See full article:  

By Larry Cooper – Senior Partner, BSSNexus Global Inc.

AXELOS will be launching ‘PRINCE2 Agile’ within a matter of weeks. But what’s in the new product? What will it look like? A large team has been working on this for over a year, and if you would like to be one of the first to get answers to those questions then why not attend this webinar and find out?

This webinar will be presented by Keith Richards, Lead Author and Chief Examiner for PRINCE2 Agile. This is an opportunity to learn about what is in the course and how you can benefit from PRINCE2 Agile.

This session will look at:
• Why combine PRINCE2 with agile?
• What are their respective strengths?
• Where are the two approaches complimentary?
• What are the challenges when combining the two?
• How do you address the common misconceptions of agile and PRINCE2?
• Why PRINCE2 is NOT a ‘traditional’ approach to project management?
• How do you create a culture where they can operate together?
• How do you incorporate Scrum and Kanban?
• Where does the Scrum Master and Product Owner fit in?
• What are the benefits? How will it help your organisation?
• What does the new training course and examination look like?

Currently, there are many concepts that are trying to address the need to manage agile in wider context, but is this reinventing the wheel? PRINCE2 is a proven project management approach and is an industry standard that supports the principles and processes that can take agile to greater heights.

Why not attend and see if PRINCE2 Agile addresses your needs when working in agile environments? You may be surprised by the outcome!

Register now!
https://attendee.gotowebinar.com/register/5819220631918570497
After registering, you will receive a confirmation email containing information about joining the webinar.