Tag Archives: Scrum

Scrum or Kanban

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I showed a picture with different agile methods and frameworks. On the team level I mentioned Scrum, Kanban and DevOps. I came across a blog post from Roman Pichler titled ‘Is Scrum right for your product?’. A nice article explaining when to use Scrum and when to use Kanban, by following a product life cycle from launch via product market fit till the end of life. I added DevOps to his approach in the same product life cycle and will use this to expand my own article. See the animated PowerPoint too.

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

See: Is Scrum right for your product?

Review: Scrum Magic. Ultimate training guide to the agile framework.

51xkemdtrllDoug Purcell wrote the book ‘Scrum Magic. Ultimate training guide to the agile framework‘ that will help you to pass one of the basic Scrum Master exams.

I would say that with this book you will get a lot of flesh on the scrum bones (as offered by the official Scrum Guide).

To set the scenery the author begins with the explanation of waterfall, agile and kanban and discusses the pros and cons and compares waterfall and kanban with scrum. 

After getting an eagle eye view of scrum including the roles product owner, scrum master, development team and stakeholders we follow the sprint lifecycle planning phase, execution phase, and closing phase.

  • Planning phase: sprint planning and estimation strategies including story points and the comparison with man-hours, planning poker, fist of five and user story best practices
  • Execution phase: daily scrum meeting with dos and don’ts and monitoring progress
  • Closing phase: sprint review with dos and don’ts and group roles, sprint retrospective best practices.

The author starts every time with a bullet list coming from the Scrum Guide and elaborates on the different topics using more detailed theory and own best practices, dos and don’ts and FAQs. You also get for each chapter the used sources (books, websites), and a quiz to help you study the material (in total you get 130 sample questions and a rationale for the answers.

In the appendices you find an overview of different agile certifications as well as project management certifications (the last is unnecessary). The explanation and reference of several agile related websites/blogs is valuable and will trigger you to have a look.


If you want to go for a scrum master certification this book is definitely worth to read and practice the questions and using the rationale to really understand and prepare yourself for the examination. If there is no need for certification this book will still be useful to get a practical understanding of using Scrum.

To order: Scrum Magic

Book review: Agile Project Management and Scrum v2

front-cover-webIn two of my previous posts I wrote about DSDM and UX Design and Agile Project Management and Scrum v2. This is another little book in the same style. And this booklet too can be read as an addendum to DSDM’s Agile Project Management Framework.

Andrew Craddock is the author of the book ‘Agile Project Management and Scrum v2‘.

The booklet starts with a comprehensive overview of Scrum based on the Scrum guide 2013 and an explanation of the Agile manifesto.

Next we get an overview the combined AgilePM / Scrum process framework. The project delivery context is based on AgilePM and the evolutionary development context is pure Scrum.

In this combined framework we see the following changes / additions in comparison with the original AgilePM framework:


AgilePM AgilePM/Scrum
Process Evolutionary Development Scrum Development
Product Prioritized Requirements List Product Product Backlog


Timebox Plan and Timebox Review Record Sprint Goal, Sprint Backlog and Sprint Review Record
Roles adding the PO, SM roles

An enhanced Scrum two-week Sprint contains some minor embellishments to the standard Sprint:

  • In comparison with a standard Sprint we now see a split in two parts: Refinement (7 days) and Consolidation (2 days).
  • Within the Consolidation part we see a Consolidation Scrum to confirm progress to date and to explain what will be ‘Done’ by the end of the Sprint.

A new event, the Project Planning Event, is added. This event takes place at the boundary of timeboxes and can be used, by project stakeholders, to influence the the work of the Scrum Team without compromising the way Scrum is used.


All roles are explained within this combined framework with special attention for the Product Owner role including relationships and interactions with the Technical Coordinator, PM, Business Visionary, Technical and Business Advisors and the Development Team.

Final paragraphs explain the usage of multiple Scrum Teams, Regulatory, and financial governance, the usage of Barry Boehm’s Cone of Uncertainty and some optional techniques (MoSCoW prioritisation, Facilitated Workshops and Modelling).

Conclusion: For those who are using AgilePM in combination with Scrum this is a must read. It gives a nice overview of the changes and a good explanation of the PO role including all relationships and interactions.

To order: Agile Project Management and Scrum v2

This is the last post in a series of three. DSDM and UX design was the first and Agile risk management and DSDM the second.

Scrum Guide Refresh (version July’2016)

This evening I followed a webinar by Jeff Sutherland and Ken Schwaber, the founding fathers of the Scrum Guide. They announced that they added, based on feedback, the following five Scrum values to the guide: commitment, focus, openness, respect and courage. During the webinar each value was explained and it ended with an overview of the official changes in de Scrum Guide.

Schermafdruk 2016-07-06 17.07.47

The official changes:

Scrum Values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.”

I would say it is a great idea that they added these Scrum values to the official guide but I still miss pictures, drawings, etc. to explain. For me these pictures are much more valuable to understand than only words and it can make the guide shorter and much more easier to read.

To download the latest (July’2016) version of the Scrum Guide: Scrum Guide

To make suggestions for the Scrum Guide: User voice

Boekrecensie: Scrum wegwijzer

gunther-verheyen-scrum-wegwijzerGunther Verheyen, partner bij Scrum.org, is de auteur van het boekje Scrum wegwijzer. Een kompas voor de bewuste reiziger. Het boekje geeft je een compleet overzicht van Scrum, het raamwerk voor software/product ontwikkeling.

Het boek is onderverdeeld in vier hoofdstukken: het agile paradigma, Scrum, technieken versus regels en de toekomst van Scrum. Waarbij het tweede hoofdstuk Scrum de kern van het boek vormt.

In het eerste hoofdstuk neemt de auteur je mee in Het Agile paradigma. Hij geeft Agile de volgende sleutelkenmerken mee: mensgericht, dienend leiderschap, iteratief-incrementeel, succes en verandering. De overgang van het industriële naar het agile paradigma is echter geen geleidelijk proces. Met kleine stapjes ga je er niet komen.

Wil je als organisatie een hogere business agility bereiken dan houdt dan rekening met de volgende ervaringen: agility kan niet worden gepland of opgelegd worden en agilty kent geen eindtoestand. Agility gaat meer over het gedrag dan over processen en leidt tot een verandering van de cultuur.

Hoofdstuk twee Scrum rekent af met rigide, niet-praktische procedures, vergaderingen en andere zaken en biedt daarvoor in de plaats het huis van Scrum waarin het doel, het increment als dak van het Scrum huis gevisualiseerd wordt. Gebaseerd op een fundament van transparantie en gedragen door de zuilen inspectie en aanpassing. Binnen dit huis vindt aan de hand van principes, rollen en regels, creatie van het increment plaats door gebruikmaking van de inzet, passie en de energie van alle betrokken spelers. Deze spelers kunnen gebruik maken van het speelbord van Scrum (zie figuur). Scrum is nadrukkelijk geen methodologie maar een beperkt raamwerk waarbinnen aan de hand van beperkte voorschriften en regels, empirisch en zelfsturend te werk moet worden gegaan.

Het speelveld van ScrumIn het boek komen alle facetten van dit speelbord aan bod waarbij nadrukkelijk niet alleen stil gestaan wordt bij de definitie maar ook wordt ingegaan op het daadwerkelijke gebruik en het waarom achter het gebruik en het doel van de bijbehorende regels. Een voorbeeld. “Ieder item op de product backlog moet juist genoeg informatie omvatten om duidelijk te maken wat de intentie van het item is. Doelbewust onvolledig.” Waarom? “Perfecte precisie is namelijk onmogelijk voor een requirement, terwijl elke poging ertoe de indruk kan wekken dat het wel mogelijk is.“ En vervolgens. “Een product backlog item is een uitnodiging tot een gesprek” tussen product owner en ontwikkelteam om het item te verfijnen.

Het derde hoofdstuk beschrijft de te ondersteunende technieken waarbij nadrukkelijk aangegeven wordt dat Scrum een dienend en geen voorschrijvend proces is. De volgende technieken worden beschreven:

  • Visualisatie van voortgang
  • De vragen van de Daily Scrum (zie het als een kans)
  • Product Backlog refinement
  • User Stories
  • Planning Poker
  • Sprint-lengte
  • Scrum op grotere schaal

Het laatste, kortere hoofdstuk gaat in op de toekomst van Scrum. In de toekomst zal Scrum niet langer ‘Scrum’ genoemd worden. Wat we nu Scrum noemen zal de norm geworden zijn. Het boekje eindigt met een korte begrippenlijst en een literatuuroverzicht.


Goed geschreven, compact en prima bruikbaar als naslagwerk en ter voorbereiding op een scrum-examen. Maar nog veel belangrijker het biedt antwoord op de vragen achter het gebruik en het doel van de events, rollen en artefacten, namelijk waarom, waarom, waarom en dat maakt het boekje tot het Scrum boek als je je wilt verdiepen in Scrum!

Het boekje verscheen in November 2013 als Engelstalige uitgave getiteld Scrum – A Pocket Guide (A Smart Travel Companion). Het is daarom jammer dat de auteur bij deze uitgave niet de kans gegrepen heeft om het stuk over het op grotere schaal toepassen van Scrum te herschrijven en ontwikkelingen zoals Nexus daarin mee te nemen.

Bestellen: Scrum wegwijzer

PRINCE2 Agile webinar recordings

Friday February 12th, I gave, on request of Fortes Solutions, the PRINCE2 Agile lecture twice (NL, EN). In total approximately 600 persons registered for these webinars. Due to the webinar system limitations we had to disappoint 150 people. I am sorry for that. The good news is that both sessions are recorded. In these 45 minute lectures I gave a brief overview of the new PRINCE2 Agile framework. The attached picture shows in a glance the overview of this new framework and showing the topics I discussed: PRINCE2 2009 version, Scrum, Lean startup and kanban, the behavior aspects, the usage of the Agilometer and the Cynefin framework as well as fixing and flexing of the six project control parameters.


The first recording is my lecture in English and the second one is in Dutch.

If you want to know more about PRINCE2 Agile feel free to enroll for one of our PRINCE2 Agile training classes. The next one will start in April in Hilversum, Netherlands. See: Hedeman Consulting.

Review: Nexus Guide; Scaled Scrum development

The basics

NexusGuide_Mockup_nfv3-400This guide contains the basics of Nexus. Nexus is a framework to develop scaled product and software development initiatives by using 3 to 9 Scrum teams. This guide is Ken Schwaber’s answer for the ‘Scrum of Scrums’.

You can position this framework at the same level as the Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe).


The Nexus Guide is written in the same style as the Scrum Guide from Jeff Sutherland and Ken Schwaber. It’s a brief document of 10 pages giving an overview of Nexus and the corresponding roles, events, and artefacts.

It starts, see figure 1, with one Product Owner managing the Product Backlog. The Product Owner sets up the Nexus Integration Team. In this team we see Integration Team members as well as a Scrum Master.

Dia1To download: Nexus (QRC, 151223) v1.0

The first official event will be the Nexus Sprint Planning. The Nexus Integration Team together with representatives of the Scrum teams develop the Nexus Sprint Backlog. This backlog will contain all User Stories for the to be delivered Integrated Increment. During this Nexus Sprint Planning the work will be allocated to the different Scrum Teams. Each Scrum Team will have it’s own expertise area and have it’s own Development Team members and a Scrum Master.

Based on the assigned work each Scrum team will have it’s own Sprint Planning to build their own Sprint Backlog.

Every day the Nexus Integration Team and representatives from the Scrum Teams will have their Nexus Daily Scrum to discuss integration issues, dependencies and sharing information across the teams. Joined to this Nexus Daily Scrum the individual Scrum Teams will have their own Daily Scrums. The Scrum Teams will develop their parts and integrate and test their work with that of the other teams.

At the end of the sprint we have the Nexus Sprint Review demontrating, showing the Integrated Increment. This is a joined review with all team and replaces the individual Scrum Team Reviews.

An overall Nexus Sprint Retrospective focusses on inspection and addaption and consists of three parts:The first part is identification of issues impacting more than one Scrum Team. Part two are the individual Scrum Team Retrospectives and the last part focusses on actions to be taken.

Target audience

For those who wants to know how to scale up Scrum based development.

For everybody involved in developing products or software and the work to be done can’t be handled by one Scrum team only.


This Nexus framework shows that to develop products or software you need more than only the will and behaviour to work together as Scrum Teams. The role and responsibilities of the Nexus Integration Team brings a form of governance / facilitation to make sure every Scrum team is doing the right things, integration and dependencies are being managed and the Nexus delivers what the Product Owner wants. Still I want to challenge Ken and his team to expand this framework to include the embedding (Change Management, transition) of the Integrated Increment within the organization.

Recommended reading

Nexus Guide. The definitive guide to Nexus: The exoskeleton of scaled Scrum development. By Ken Schwaber, August 2015. To download: The Nexus Guide.

PRINCE2 Agile, a first overview

During the last Gartner PPM Summit, 8 and 9 June 2015, in London, it was confirmed again. “One size does not fit all” is true in the world of projects too. Are reliability and cost the most important or are we going for brand awareness, sales and customer experience? Do we have to deal with long-term or short-term contracts? Is the focus on IT only or enterprise-wide? Are we talking about frequent or a limited number of deliveries within short or long lead times? Many debates we see in the media, PRINCE2 versus Agile, Scrum only but what about governance or the business case? The answer from Axelos is PRINCE2 Agile that combines the best from both worlds to carry out a project properly.


PRINCE2 Agile includes both the existing PRINCE2 as the agile way of thinking. The agile way of thinking must be seen as agile behaviour, concepts, frameworks, focus areas and techniques. The existing PRINCE2 principles, processes and themes remain, but should be tailored using the agile way of working and the project itself. PRINCE2 Agile searches for the best of both worlds where the emphasis lies in the use of PRINCE2 within project direction and project management and the agile approach in the product delivery. Depending on the project situation you can apply more or less of the PRINCE2 or agile way of thinking. See Figure 1.

Dia05Figure 1. Mixing of PRINCE2 and Agile

six project control parameters: PRINCE2 uses six project control parameters: time, cost, scope, quality, risks and benefits. All six have their own tolerances. PRINCE2 Agile recognizes the same six project control parameters except that within an agile approach time and cost are fixed (no tolerance), quality and scope can be partially flexible (no tolerances for the essential criteria and products) and the risks and benefits can be fixed or flexible (tolerances in consultation between the project manager and the project board).

The reasons for flexing are explained by the five targets:

  1. Be on time and hit deadlines
  2. Ensure the required quality
  3. Embrace change
  4. Keep the team stable
  5. Accept that the user doesn’t need everything

In the following paragraphs I explain how the principles, themes and processes can be customized to incorporate the agile way of thinking.


The seven PRINCE2 principles remain. However PRINCE2 Agile adds five behavioural components to it:

  • Transparency – regarding the progress of the project.
  • Collaboration – between the project team members and stakeholders.
  • Rich Communication – consultation over email, visualization over text.
  • Self-organization – empower and facilitate the project team.
  • Exploration – curiosity over obeying the rules.

The processes

Starting up and initiating the project: Make during starting up a project, an initial estimate how far you can go with embedding the agile way of working in the project. To perform this agile risk assessment, PRINCE2 Agile developed the Agilometer. This evaluation must be repeated during the initiation stage and the various stage transitions.

Agilometer: The Agilometer consists of six key areas to be used in the assessment of the application of agile within the project. The six key areas are:

  • Acceptance of agile;
  • Advantageous environmental conditions;
  • Ability to work iteratively and deliver incrementally;
  • Ease of communication;
  • Level of collaboration;
  • Flexibility on what is delivered.

The project manager performs this analysis and looks for each key area for possible or necessary improvements and gives insight how agile the project can be established. So, it’s not a matter of yes or no. It also makes no sense to calculate an average of the six sliders. This Agliometer is comparable with the agile project questionnaire from DSDM.

During Start up and Initiating the project it’s key to find the right balance between the risks associated with the project and the level of detail the issues should be sorted out beforehand. The aim should be to maximize the freedom to steer the project during the implementation of the project. Sometimes within agile they call Starting up and Initiating the Project stages, sprint zero or the discovery phase. The Project Product Description is then referred to as the project backlog.

Cynefin model: PRINCE2 Agile uses the Cynefin model from Snowden to determine the level of uncertainty and thereby what the most logical approach and management of the project. The Cynefin model identifies five domains:

  • Obvious: clear cause-effect relationship
  • Complicated: cause-effect relationship is not clear
  • Complex: cause-effect relationship can only be explained in retrospect
  • Chaotic: cause-effect relationship can’t be indicated
  • Disorder; unclear to which domain the change belongs.

With clear cause-effect relationships there is usually a simple project or ‘business as usual’. Projects we find especially in the complicated and complex domains. The more complex in its environment the more an agile way of working is desirable. If the cause-effect relationship can’t be indicated, then a process approach is the most appropriate approach.

Directing the project: With ‘business as usual’ the product owner directs the agile process. In a project environment, we see the PRINCE2 roles of executive (sponsor), senior user and senior supplier. For simple projects, some of these roles can be merged, e.g. the executive and senior user role.

In all cases it is important that collaboration is based on trust, and that therefore there is no blame culture. Management by exception is than characterized by empowerment and rich communication.

Controlling a stage / Managing product delivery: Within PRINCE2 Agile it is possible that there are no stages but only time boxes, whether inside releases or increments. Releases or increments can also be defined as stages, if at the end of which an explicit go / no-go decision is planned. It is important to plan around the functions (sub-products) and use flexible work packages that emphasize that teams are as much as possible self-organizing, communicating rich and make management by exceptions possible. Focus is on the result to be delivered, so the scope and quality criteria and the control of the agile related risks. The Controlling a Stage is characterized by transparency, collaboration and rich communication, self-organization and flexibility.

To have frequent releases makes it possible to harvest benefits as early as possible, obtain fast user feedback and reduce risk. It provides confidence that the project will deliver and it will help to obtain and retain the stakeholders’ interests. Small releases are often easier to take into production. Of course, the releases needs to be planned so that it is clear when which of the functions (sub-products) are delivered.

Manage a stage boundary: During managing a stage boundary (increments or releases), it is important to assess how much is produced, which what quality and what benefits have been or may be harvest. In addition, an assessment of the agile way of working, and determine if the method used must be adjusted. This corresponds to the retrospective in Scrum. Of course, this step should take place with as little as possible ceremony.

Closing the project: Within agile there is not much described on the formal closure of a project. Usually there are already several interim products delivered. PRINCE2 Agile emphasizes on the following activities that may or may not be conducted in workshop form. Rate the final outcome with respect to the original plan. Agree on the formal user acceptance. Evaluate the process as well as the usage of agile in the project. Finalize the required documentation. Transfer the result formally to the customer.


All themes within PRINCE2 can be found in PRINCE2 Agile. Some topics are within the agile way of working more important than others.

Business justification: The business case for the entire project is drawn up during Starting up / Initiating the project and updated at the end of each stage. It must also clearly define the minimum usable product, based on the prioritized list of requirements (must-haves). The added value of the individual functions will be prioritized in the different timeboxes. A requested function or feature that adds no value to the organization will not be realized.

Organization: The known roles of executive (sponsor), senior user and senior supplier still exist in an agile project but from a user perspective often expanded with the role of Business Ambassador (DSDM) or Product Owner (Scrum). The Project Manager has a more facilitating role than a managerial role (servant leader). Depending on the self-organizing ability of the development team and the Agile method used, the role of Team Manager can be filled formally, or by a Scrum Master (Scrum), or be fulfilled by the team as a whole. For the Project Manager, it is important that he has at least a point of contact in the team and that in the team someone from the user side is involved (business ambassador or product owner).

If the project consists of only one agile team, then a simple agile approach with one product owner and scrum master suffice. Consists the project of more teams than the different product owners and scrum masters must tune their work and progress (scrum of scrums).

Plan: A project is finite. For each project there must be a planned end date. Therefore you need an overall project plan. This also distinguishes the agile project approach to agile maintenance approach as part of business as usual. The project plan to support the agile approach, however, should be limited to the main topics/functions. It has to be just sufficient to be able to determine the total duration and the total budget, assuming sufficient (flexible) tolerances within the to be requested functionalities. Per increment or timebox the project plan will be more detailed. Within an agile approach the time and cost tolerances are set to zero and the flexibility will be found in the tolerance of the functionalities.

PRINCE2 Agile prescribes no mandatory planning technique and no planning approach. From the agile way of working it is appropriate to establish the project plan empirically in consultation with the project team and set the various timebox plans by the delivery team themselves. These delivery teams can make use of a simple scoring system such as planning poker, or T-shirt planning.

Progress monitoring: As with the PRINCE2, PRINCE2 Agile focuses on the product to be delivered. However, PRINCE2 Agile is less about whether it will succeed to deliver the product as defined within the given time horizon, but how much functionality can be completed within the given time horizon. For progress reporting at project level you can make use of stand-up meetings, information radiators, team boards and visual burn-down or burn-up charts that are used at the team level. In addition agile teams frequently make use of the concept of velocity. This is a measure of the production of the development team in a certain period of time (timebox), with which one can also determine the extent to which a team learns, and hence can realize more in the course of time.

Risk Management: Risk management gets less attention Within PRINCE2 Agile because many project risks are already minimized by the agile approach. But due to a possible discrepancy between the agile approach and more conditioned environment new project risks can be introduced too. In order to identify these risks, the Agilometer is introduced. As a result the project approach can be tailored to accommodate the given situation as showed in the Agilometer. PRINCE2 Agile uses the five behavioural components to control possible project risks too.

Quality: Within PRINCE2 Agile is important to develop a less formal quality management strategy, but you still need to capture it: what and how is tested within the development teams and what, how, and by whom will be tested at the end of the time boxes. Within the Project Product Description we find the description of the needed necessary changes in the organization based on the result to be delivered. Further, the acceptance criteria and the “Definition of Done” are central to the quality theme. Quality criteria of the requested products can be found in the product descriptions on the project level and in the user stories at the team level.

Change management: PRINCE2 Agile embraces change. The more changes, the better the product is likely to be connected to the company strategy and the greater the user involvement, and thus the probability of acceptance of the product. It is important to make a distinction between the changes in the officially fixed configuration (project product description), which should be monitored formally at project level and the further elaboration of that configuration within the development team and user representatives (informal). Adding new parts means that those new parts needs to be exchanged for other less important parts (trading), because there are no time and cost tolerances within agile projects.

Lean start-up: Within the philosophy of embracing change, PRINCE2 Agile also introduces the principle of lean start-up. Lean start-up focuses on learning and act accordingly. Try as fast as possible (fail fast). But take as soon as possible (parts of) products in use, and learn from them. The product that processed most of the learning experiences, usually delivers the most value.

Agile and supplier contracts

Agile in combination with strict supplier contracts remains a challenge for many. Within PRINCE2 Agile this problem is worked out in a clear manner and therefore also provided various guidelines. Useful recommendations are:

  • Focus is on the end result (outcome) and not on the final product (output);
  • Define the level of user participation during the project;
  • Describe, in terms of time, important delivery milestones (sprints and / or releases);
  • Include a clause that the project board may decide to stop prematurely;
  • Take a bonus / penalty clause on the basis of the quantity of delivered end result;
  • Define global requirements and prioritize them. Detailed requirements will ask for too many adjustments during the project;
  • Keep the contract as simple as possible (depends on mutual trust).

Agile Frameworks

PRINCE2 Agile discusses the use of the Scrum and Kanban frameworks and related techniques such as user stories, MoSCoW prioritizing, frequent releases, planning poker and T-shirt estimation extensively.

A Dutch version of this article will be published in due course (IPMA Projectie).

PRINCE2 Agile in one picture

In one of my previous posts I already gave some preliminary facts regarding the new PRINCE2 Agile framework. See: preliminary facts 

In this post you get a simple overview regarding PRINCE2 Agile. This framework is based on blending PRINCE2 and agile together. PRINCE2 is strong in the areas of project directing and project management and agile is strong in the area of product delivery. It’s not a matter to chose between PRINCE2 or agile but to decide how far you can go using specific agile ways of working by tailoring the PRINCE2 approach. The new framework offers the Agilometer to understand how far you can go using agile. Together with the usage of the Cynefin framework created by David Snowden you must have a good view how to blend PRINCE2 and agile.


For the PRINCE2 part this new framework is based on the existing PRINCE2 2009 version. For the agile part they use The definitive guide to scrum by Ken Swaber and Jeff Sutherland (integral copy included in the manual) and material based on The lean startup by Eric Ries and Kanban – Successful evolutionary change for your technology business by David Anderson (see book review).

Besides these frameworks you can also find explanation of behaviour in the areas of collaboration, self-organisation, transparency, rich communication and exploration.

In a next post I will give a summary of PRINCE2 Agile based on the official PRINCE2 Agile manual.

Book review: Scrum, the art of doing twice the work in half the time

9200000022987449scrum nlJust finished Scrum, The art of doing twice the work in half the time from Jeff Sutherland, co creator of Scrum.

If you are looking for a book to get an in-depth explanation ‘how’ to use Scrum, this is not the right book. If you are looking for a book to get an explanation of the ‘why’ behind Scrum this is a great book to read.

Sutherland gives you many anecdotes of his personal experiences as a fighter pilot in Vietnam or as biometrics expert, innovator of ATM technology, problem solver, trainer, investigator or coach and what he has done with that in relation to Scrum or the development of Scrum.

The book is divided in nine different chapters and each chapter ends with takeaways.

Chapter one: The way the world works is broken gives the success story of applying scrum within the FBI to bring a big project back on track, a project that was using a traditional project life cycle. Takeaways: Planning is useful. Blindly following plans is stupid, inspect and adapt, change or die, and fail fast so you can fix early.

Chapter two: The origins of Scrum give some insight in the work of two Japanese business professors, Hirotaka Takeuchi and Ikujiro Nonaka. They wrote an article in the HBR titled “The new product development game”. In this article the described companies using overlapping development, cross-functional teams with autonomy, empowered to make decisions with a transcendent purpose and management didn’t dictate. These professors compared the teams’ work to that of a rugby team and said that the best teams acted as though they were in a scrum. Takeaways: Hesitation is death, look outward for answers, great teams are, don’t guess and Shu Ha Ri (first, learn the rules and the forms, second: make innovations, finally discard the forms).

The next six chapters highlight a specific aspect of Scrum.

Chapter three: Teams explains the impact of the size of the team, the role of the scrum master, and what does it mean or what do you need to be an excellent team. See also the mythical man-month from Brooks and his law “adding man-power to a late software project makes it later”. Takeaways: Pull the right lever, transcendence, autonomy, cross-functional, small wins and blame is stupid.

Have a look at a video from all black rugby team Haka to motivate your team (and let the opponent shiver):

Chapter four: Time is about the sprint and daily stand-up and his experience at Wikispeed. Takeaways: Time is finite. Treat it that way, demo or die, throw away your business cards, everybody knows everything and one meeting a day.

Chapter five: Waste is a crime looks amongst other things at the ideas of Toyota’s Taichi Ohno, multitasking and prioritization between projects. Taichi Ohno talked about three different types of waste. Muri, waste through unreasonableness; Mura, waste through inconsistency and Muda, waste through outcomes. Takeaways: multitasking makes you stupid, half-done is not done, do it right the first tie, working too hard only makes more work, don’t be unreasonable, no heroics, enough with the stupid policies.

Chapter six: plan reality, not fantasy goes into the problems of Medco with their project, looks into planning poker and the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …), stories, velocity and sprint planning. Takeaways: the map is not the terrain, only plan what you need to do, what kind of dog it is? ask the oracle, plan with poker, work is a story, know your velocity, velocity x time = delivery and set audacious goals.

Chapter seven: Happiness. Happiness is success, quantify it, make it visible, and use a scrum board, deliver happiness. Takeaways: it’s a journey, not the destination, happy is the new black, quantify happiness, get better every day and measure it, secrecy is a poison, make work visible, happiness is autonomy, mastery and purpose and popp the happy bubble.

Chapter eight: priorities, is about the product owner. What can you implement, what can you sell, what can you be passionate about. You have to focus on all three to be successful. Use a backlog to know what to do when. Takeaways: make a list, check it twice, the product owner, a leader isn’t a boss, Observe – Orient – Decide – Act (OODA), fear – uncertainty and doubt, and get your money for nothing and your change for free.

Chapter nine, the last one: change the world gives several examples where Scrum is used outside software development. A nice example is the usage of Scrum for education at a Dutch school (EDUSCRUM) or by NGO’s. Takeaways: scrum accelerates all human endeavours, scrum for schools, scrum for poverty and rip up your business cards.

Conclusion. The book gives a lot of background information and will help you to get a much better understanding of the philosophy behind Scrum. As stated it is not a learning book about Scrum, but on the other hand to learn Scrum you have to bring it into practice and practice and practice… So from that perspective this book is a good starting point.

All given examples are success stories, a pity Sutherland didn’t go into some failures of implementing Scrum. You could learn a lot from them too. E.g. he describes the usage of early adaptors who have to pay for alpha-versions. If I am correct Google developers gave this as their main root course for the failure of Google glass (at least at this moment). Or he mentioned a story where he successfully implemented Scrum at PatientKeeper. When he left, new management decided to stop with Scrum. Could be interesting to know why?

I was also looking for some answers for my own questions regarding Scrum but I didn’t found them in this book. I always hear the success stories of organizations building a (software)product but if you build the product for yourself, e.g. an administration system and want to implement it in your own operational department how to cope with the real implementation, the embedding in the organization, the cultural change. Do we have success stories where Scrum is used for those kinds of transformations? What about organizations that have to build or update many applications with have interfaces with each other. They could have many scrum teams, but how are they working together. A Scrum of Scrums I don’t see working. I see e.g. Spotify using Tribes, Squads, Chapters and Guilds but this is again about developing a product for the end customer and not about embedding the output in an organization.

To order: Scrum, The art of doing twice the work in half the time

Bestellen van de Nederlandse vertaling: Scrum, Tweemaal zoveel doen in de helft van de tijd