The SCRUM Fieldbook

9780525573210-480x600J.J. Sutherland wrote The SCRUM Fieldbook – A master Class on Accelerating Performance, Getting Results, and Defining the Future. I would say a virtual master class build around a backlog of approximately 40 items and clustered in 10 groups. Every chapter is dedicated to one group.

The first clusters of backlog items are related to the Agile Manifesto and the usage of Scrum itself. Important but the information can be found in other books too. The other clusters will move you into the master class. Have a look at some examples from the book related to specific backlog items:

  • Decision latency as a result of a study from The Standish Group. How much time is wasted waiting for a decision to be made? Measure your meetings. More than 40% of decisions made in meetings are overturned. Think about the last time you or your organization faced a crisis. Could you have acted more quickly? How could you change your decision-making process next time?
  • Too much structure, too much processes will have a negative impact on agility. If you have just enough structure to ride the edge of chaos, that’s where interesting things happen. Creativity blossoms and can be channeled. Ideas are generated and applied. There is freedom of expression but also some controls in place to focus.
  • A structural reorganization emerged as the goal shifted from output (making sure everybody was busy) to outcome (getting to done).
  • Know the power of no. Choices have to be made.
  • Find your ba. It’s a shared space between individuals that is the foundation for knowledge creation. When you are in a partnership or participating on a team or teams aligned on a single goal, you create something larger than the sum of the parts.
  • Your structure is your culture. And your culture is your limits. A rigid structure begets a rigid cultural and product architecture.
  • You need to create an environment that ensures the Scrum values are present. This is when you strike out at the bureaucracy that slows things down and frustrates everyone. But what structure should you have? Where do you begin? For the most part you do need some hierarchy, because you don’t want chaos, but you want just enough hierarchy – the minimal viable bureaucracy.
  • Once you reshape your structure, a new culture emerges. Organizations, families, people are all complex adaptive systems.
  • Focus maximum team effort on one item in the product backlog and get it done as soon as possible (swarming).
  • Watch out for anti-patterns. The problem with à la carte Scrum. Use data for decisions, not opinions. Don’t outsource competence. If you outsource how to do it, you don’t internalize the knowledge. Remove them one by one.

Conclusion. A book about the world behind Scrum. It will help to expand your knowledge how to use Scrum to accelerate performance and getting things done. You got a lot of examples using Scrum in and outside IT. Definitely worth reading.

To buy: The SCRUM Fieldbook


Review CHAOS Report 2018

Schermafdruk 2020-01-03 11.19.55Every two years the Standish Group publish a new CHAOS Report. These reports include classic CHAOS data in different forms with many charts. Most of the charts come from the CHAOS database of over 50,000 in-depth project profiles of the previous 5 years. You have probably seen some of those yellow-red-green charts showing e.g. challenged, failed and successful project percentages.

Every report contains an in-depth study regarding project performance. This CHAOS Report 2018: Decision Latency Theory: It’s All About the Interval presents the root cause of software project performance. A highlight of this report is their analysis and thought leadership what makes a project succeed with the winning hand and what makes a losing hand.

In the CHAOS Report 2018 are five main sections:

  • Decision Latency Theory
  • Winning Hand
  • Classic CHAOS
  • Factors of Success
  • Skills of the Factors of Success

Decision Latency Theory

Decision latency theory states: “The value of the interval is greater than the quality of the decision.” Or with other words, if you want to improve project success, you have to speed-up your decision-making. The Standish Group studied this decision latency for over a decade and stated that a project will create one decision for every $1,000 in project labor cost. If it takes many hours to make a decision, there is probably a lot of overhead involved (e.g. escalating to higher management layers) and you will have difficulty to stay within time and budget. You have to find ways to reduce this interval by decentralize the decision making, by eliminating steps that take time but have no value, by killing many of those crowded useless meetings, et cetera. Simply reducing decision latency can improve your project performance by 25%. In the report several graphs are shows as well as tables with the cost of decision latency and the resolution (skill level) by decision latency.

Winning Hand

In the previous CHAOS Report 2016 the five cards of a winning hand for project success were introduced:

  • First card: The project needs to be small
  • Second card: The product Owner or sponsor must be highly skilled
  • Third card: The process must be agile
  • Fourth card: the agile team must be highly skilled in both the agile process and the technology
  • Fifth card: The organization must be highly skilled at emotional maturity

As long as I have seen output from CHAOS reports, the project size and a committed project sponsor were always in the top 3 of their factors of success. For each card you get a graph showing the effect on challenged, failed and successful projects (effect of project size, effect of good sponsor, effect of the agile process with skilled teams, effect of using skilled teams and the effect of emotionally mature teams). And, as you can imagine, a combination of cards will increase the chance of project success, definitely when you are highly skilled at decision latency.

Classic CHAOS

The CHAOS database includes six individual attributes of success: on budget, on time, on target, value, on goal and satisfaction. The Standish Group started with a traditional metrics of success by looking at: “on time, on budget, and on target”. This means in this CHAOS Report 2018 for the year 2017: successful: 36%, challenged: 45%, failed: 19%. If they use their “modern” definition of success: “on time, on budget, with a satisfactory result.” You get almost the same results (33%, 48%, 19%).

In this report we get a new definition of success that they call “pure success.” Pure success is the combination of high customer satisfaction with high return on value to the organization. Related figures for the year 2017 are: successful: 14%, challenged: 67%, failed 19%.

Another table with figures that is presented shows the resolution of strategic goal (precise, close, loose, vague, distant and failed) versus value management (very high value, high value, average value, low value and very low value).

For each of the five cards we get a table with percentages for successful, challenged and failed. Tables for resolution by project size, resolution by project sponsor skills, and resolution by method. If you are using agile or non-agile and the project size is small the outcomes are more or less the same. When increasing project size an agile method becomes more successful. Looking at team technical skills you get two tables. One showing a four-point range and the other a five-point range of skills.

This part is finalized by looking at project resolution by industry where banking shows the highest and telecon the lowest percentage of successful projects and by project type (developed from scratch … purchased application of the shelf).

Factors of success

Every year since 1995 the Standish Group creates a list of 10 attributes and their relative weight that they call the factors of success. The top three for 2018 are decision latency, minimum scope and project sponsors. For each of the ten factors you get an explanation and a table showing percentages of successful, challenged and failed related to resolution of the specific factor (e.g. skill level).

Skills of the Factors of Success

Schermafdruk 2020-01-03 17.10.36For each of the factors of success you get a set of five skills that help to improve that factor. E.g. if you look at decision latency you can use the following skills to reduce decision latency: reducing decision latency reduces the interval between decisions, make quick decisions, distribute decisions, rapid consensus, and decision pipeline. Or if you look at minimum scope one of the skills to promote minimum scope is a simple vision. Of the features available to most mission-critical applications, 20% are used “often,” 30% “infrequently,” and a full 50% are used “almost never.” In total you get 50 skills that not only improve latency but can also be implemented at very little cost.

Conclusion. CHAOS stands for the Comprehensive Human Appraisal for Originating Software. It’s all about the human factor. If you are looking for areas of improvement of your organizational project management skills, this guide gives a great overview where you could get the highest benefits from your investments. It gives excellent insights in root causes for project failure or success.

To buy this report:

FLEX, Flow for Enterprise Transformation

FLEX_Essentials-768x412The first post in 2020 is again a post about an agile framework. The forest is still growing and this will not be the last one. The next one is already under review too.

FLEX, Flow for Enterprise Transformation, developed by Al Shalloway, is designed to be used as a guide for organizations to achieve business agility. It is a platform which lays out the steps required for improving the way a company adds value to its customers, both external and internal. It can be used with Other agile frameworks like SAFe, Nexus, LeSS, Disciplined et cetera. FLEX is designed to work at the organization level, regardless of the size of the organization involved or if only part of the organization is involved. It is designed around flow-thinking, Lean-thinking, the theory of constraints, and organizational development integrated with how people learn and change habits.

FLEX incorporates four shifts in thinking. These are systems-thinking, shifting from frameworks to the work itself, focusing on flow, and attending to organizational development with Lean.

FLEX contains the following components: objectives, practices, agreements and principles, transformation philosophy and natural laws. People make agreements that are organized around working together, not merely follow an approach. The following basis agreements are translated into guardrails (a guardrail includes a variety of questions to check if you are keeping the agreement): drive from business value, collaborate across boundaries, make all work visible, increase predictability, keep WIP within capacity and improve continuously.

FLEXVS_0Basic-3-1200x720There are 4 new roles required when going to scale: business architect, application development manager, technology delivery manager (TDM), and value stream network architect.

As a starting point the following five-step approach to a roadmap can be used:

  1. See where you are
  2. Understand the challenges you are having
  3. Lear a few key principles and practices that will help you overcome these challenges
  4. Define to begin using FLEX’s starting template and tailoring it for your organization
  5. Begin and continuously improve

For more information visit:

In September 2019 PMI acquired FLEX from Net Objectives. Will PMI create a new agile framework incorporating FLEX, Disciplined Agile and Brightline Transformation Compass? If so, it will generate some open space in my agile forest with the risk that new agile frameworks originate.

Due to the fact that they positioned FLEX as a guide to achieve business agility and to be used together with other frameworks I position FLEX in the culture-targeted box in my Bird’s eye view on the agile forest.birds eye

For the complete Bird’s eye view on the agile forest article see: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.

Brightline Transformation Compass

compass-with-icons.418x0-is-hidpiI just finished the draft version for the second print of my book Scaling agile in organizaties (in Dutch) and I counted 65 frameworks and approaches (25 more than the first print). I thought I covered all, but I found a few new ones.

One of them is the Brightline Transformation Compass, a comprehensive system for transformation developed by Behnam Tabrizi, PMI.

This approach helps to create the right mindset within your organization needed for a successful agile transformation. It gives you a compass that is built around 5 critical, mutually reinforcing building blocks for effective transformation and a three-step approach for transformation.

The five compass building blocks:

  1. North Star: A crisp, inspiring articulation of the vision and strategic objectives for the transformation to give your employees a clear direction.
  2. Customer Insights & Megatrends: Embedding a deep understanding of the customer in every change you make, and in every employee – the customer you may have today, and the customer you want tomorrow, as well as the “megatrends” affecting them. Core principles are involving the real customer, find leading customers and conduct the research yourself.
  3. The Transformation Operating System: A flat, adaptable and cross-functional organizational structure that enables sustainable change. It consists of five components: Flat, cross-functional Rapid Response Teams, a lightweight governance & strong program management, a collaborative and appropriate risk appetite, well-defined KPIs and venture-style investment rounds.
  4. Your Volunteer Champions: A mechanism to harness many thought leaders from across your organization to drive transformation (identify, recruit, motivate and empower).
  5. Inside-Out Employee Transformation: A set of tools to make the transformation personal for your employees – to connect their aspiration to the North Star and to your customers based on the SEE-model. The aim of the SEE-model is to find the intersection between your strengths, the elements of the transformation that evoke personal meaning and actions that make you feel elated.

The three-stage methodology for transformation (inspire, mobilize and shift):

  • Inspiring your organization for change: build your transformation organization with Rapid Response Teams initiated and ready to start.
  • In mobilizing key elements to drive the change: define the blueprint for your transformed organization and build a plan to get there.
  • In shifting the organization to effect transformation: execute on the transformation to meaningfully alter performance and instill the mindset and culture within the organization to continue transforming on an ongoing basis.

This approach is independent of the framework or methodology you are using. It can be used on top of SAFe, LeSS, Disciplined Agile, Nexus and many more to create the right mindset and will improve the chance of a successful agile transformation (more than 70% fail).

For more information on the Brightline Transformation Compass:

This is definitely an approach that fits in the culture-targeted box in my Bird’s eye view on the agile forest.

birds eye

For the complete Bird’s eye view on the agile forest article see: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.

Quick Reference Cards in 2019

As a result of my book reviews in 2019, I created several Quick Reference Cards to summarize what I have read.

QRCs 2019

Overview of my year 2019 book reviews

2019 was again a fruitful book review year. I wrote around 40 book reviews including corresponding quick reference cards and several personal insights, and views on specific topics in the field of project, program and portfolio management.




Project/Program/Portfolio management

Recensie: Agile zoals het bedoeld is

9789461263575-480x600Christine Karman laat met haar boek Agile zoals het bedoeld is – slagvaardig werken (zonder de bureaucratische rompslomp) zien dat het klakkeloos volgen van de Scrum guide zoals dat door puristen gepropageerd wordt kan ontaarden in bureaucratisch geneuzel. Aan de hand van haar eigen praktijkvoorbeelden krijgen we een beeld hoe zij agile werken ziet en toepast.

Het boek is onderverdeeld in elf korte hoofdstukjes en een zestal intermezzo’s waarin haar eigen ervaringen met agile werken zijn opgetekend. Verschillende aspecten van agile werken zoals het doel van agile werken, agile werken in de praktijk, haar vier principes van slagvaardig werken (stoppen met vergaderen, werk met een multidisciplinaire team, kies voor continuous delivery en maak het team de baas) en de fasering van een project komen aan bod. Ook de, m.i. belangrijkste, zachte kant van agile werken, lees agile werken is mensenwerk, de samenwerking in een team, communicatie en de taak van de manager passeren de revue.

Interessant is haar blik op niet-functionele eisen. Jammer alleen dat ze dit niet verder uitwerkt hoe je daar als agile team mee om kan gaan. Leg je deze niet-functionele eisen vast als acceptatiecriteria bij de user story, in de definition of done of maak je daar eigen stories van? Ook had ik graag gelezen wat haar ervaringen zijn met het voldoen compliance richtlijnen.

Het boekje leest vlot weg en de beschreven anti-patronen en eigen werkwijzen zoals de project startup hackathon bieden handvatten om het agile werken ook eens anders te proberen. Op een aantal momenten blijft het echter te oppervlakkig of wordt het probleem m.i. wat te makkelijk bij de Scrum werkwijze zelf neergelegd. Het is m.i. niet het Scrum ritueel zelf maar de wijze waarop het scrum ritueel binnen de organisatie door de medewerkers zelf wordt ingevuld waarom het geen toegevoegde waarde heeft. Dat ze een aversie tegen vergaderen heeft begrijp ik volkomen maar om alle vergaderingen uit te bannen en daarvoor de gesprekjes bij de koffieautomaat te gebruiken werkt lang niet altijd.

Haar beeld dat een team na iedere iteratie een minimum viable product (MVP) oplevert vind ik onjuist. Een MVP is een met de kleinst mogelijke inspanning te leveren oplossing om een hypothese te testen, om op basis daarvan te besluiten om wel/niet door te gaan. Wat ze beschrijft is een minimum marketable product (MMP).

Neemt niet weg dat het lezen van dit boekje je toch weer met je voeten op de grond zet en je laat nadenken wat je nu eigenlijk wilt bereiken met agile werken. Een volgens het boekje geïmplementeerde werkwijze of een meer wendbaar team of organisatie?

Bestellen: Agile zoals het bedoeld is