Tag Archives: review

Review Leading the transformation

81UHq59ZetLThe book Leading the transformation – Applying agile and DevOps principles at scale written by Gary Gruver and Tommy Mouser gives a refreshing look how to start your agility transformation.

While most Agile implementations start with a focus on applying Agile principles at the team level, the approach presented in this book focuses on applying the basic principles of Agile and DevOps across the organization. How teams come together to deliver value in large organizations is the first-order effect, while how individual teams work is a second-order effect. Therefore, this book primarily focusses on how to transform the way the teams come together to provide value to the business by integrating all their changes early and often in an operation-like environment.

Transforming development and delivery processes in a large, traditional organization requires a lot of technical changes that will require some work, but by far the biggest challenges are with changing the culture and how people work on a day-to-day basis.

The approach to rolling out an enterprise-level Agile transition should focus on the business breakthroughs the Agile principles are intended to achieve while taking into consideration the capacity of an organization to change.

In several chapters we follow the steps you have to take when transforming the organization.

  • Business objectives and crucial first steps. Once you have a clear set of business objectives in place, the next step is determining where to start the transformation. You can’t do everything at once and this is going to be a multiyear effort, so it is important to start where you will get the biggest benefits.
  • A culture of continuous improvement at the enterprise level is important for any large successful transformation (mini-milestone objectives, cascading objectives to track progress, conversations, learnings and agile adjustments).
  • Agile enterprise planning. Organizations need to decide whether their primary objective is to deliver long-term accurate plans to its executives or if it is to deliver business value to its customers. Break the planning process down into different planning horizons, don’t eliminate flexibility, don’t lock in all of your capacity to long-range commitments, just-in-time creation of requirements details.
  • Business objectives specific to scaling DevOps. Applying DevOps and Agile principles at scale in the enterprise requires developing processes that will enable the organization to economically release smaller batches of code on a more frequent basis. There are five main objectives: improve the quality and speed of feedback for developers, reduce the time and resources required to go from functionality complete or release branching to production, improve the repeatability of the build, deploy, and test process, develop an automated deployment process that will enable you to quickly and efficiently find any deployment or environment issues, and remove the duplication of work that comes from supporting multiple branches of similar code.
  • Creating a culture of trunk development. One of the most important cultural changes for aligning the work across the organization is having all the teams continually integrating and testing their code in a production-like environment. From a technical perspective the team will have to learn development practices like versioning services, rearchitecture through abstraction, feature flags, and evolutionary database design techniques.
  • ensuring a solid foundation. The first fundamental is clean architectures that enable smaller teams to work independently in an enterprise and make it possible to find defects with fast running unit or subsystem tests. The second is build and the ability to manage different artifacts as independent components. The third is test automation.
  • Continuous Delivery is a fundamentally different approach to development and operations that automates as much of the configuration, deployment, and testing processes as possible and puts it all under a revision control. The core pieces of Continuous Delivery you need to know are continuous integration, scripted environments, scripted deployments, evolutionary database design, test automation, deployment pipeline, and orchestrator.
  • Designing the deployment pipeline. You need to design a deployment pipeline that moves as close to that ideal state as possible but accommodates the current realities of your traditional business. Building up a stable enterprise system is a key component of the DevOps or Agile principle of enabling more frequent and smaller releases. Even if your business does not require or support more frequent releases, it helps with developer productivity and takes uncertainty out of the endgame.
  • Improving stability over time by using build acceptance tests and the deployment pipeline.
  • getting started. The key is starting the process of continually improving. The first step is making sure you have a clear set of business objectives that you can use to prioritize your improvements and show progress along the journey. Next is forming the team that will lead the continuous improvement process. The team should include the right leaders across Development, QA, Operations, and the business that will need to help support the priorities and lead the transformation.

Conclusion. After reading this book it becomes clear that moving towards business agility has nothing to do with the implementation of an agile way of working at team level. It’s the organization’s culture that has to change and this book is a great start to understand what that cultural change means from a developers’ perspective and which steps you need to take.

To order: Leading the transformation


Review 97 Things Every Scrum Practitioner Should Know

9781492073840-480x600The book 97 Things Every Scrum Practitioner Should Know edited by Gunther Verheyen contains the wisdom of 69 practitioners around the world and helps you to improve your understanding of Scrum (nb. Who are we missing on the cover of the book?).

Gunther organized these 97 essays around ten themes. These themes cover all aspects of Scrum and beyond. The events, the different roles, their behavior, the skills, collaboration and the artifacts. The book ends with a simple Scrum glossary. To summarize, some topics that are discussed in the ten themes:

  • Start, adopt, repeat. This first theme gives you insights what it means when you start using Scrum. Use it, as it is or adapt? Why using Scrum? Are multiple Scrum teams the same as Multi-team Scrum? And many more.
  • Products deliver value. What are your products? How is this reflected in your backlog? What do we mean by value? Who’s value? And what does this mean for the product owner?
  • Collaboration is key. Collaboration, communication and interaction between whom? With the customer, within the team? Are you just following your job description or not? Are tools considered harmful?
  • Development is multifaceted work. What are you developing? What’s on your product and sprint backlog? How to size your PBI’s? What do we mean with backlog items, user stories, abuser stories, bugs?
  • Events, not meetings. Here we get several ideas how to make the events work and effective. The impact of sprint goals, who plays which role during the events and what are these events not.
  • Mastery does matter. Here we get the spotlights on the Scrum master. The Scrum master as servant leader, court jester, (technical) coach, or is he just an impediment hunter?
  • People, all too human. Teams are more than collections of technical skills. Are people impediments? Can Scrum masters replace team members?
  • Values drive behavior. Scrum is more about behavior than it is about process. What is self-organization? How to be a more humane Scrum master and an essay on the sixth Scrum value.
  • Organizational design. It’s all about agile leadership, culture, improving the organization, the importance of networks, respect and a save environment.
  • Scrum off script. Probably you think you know the origins of Scrum, but it might not be what you think they are. Here we also get some examples of Scrum outside software development, e.g. at the police, in the classroom, in education.

Conclusion. This book is definitely food for thought for Scrum practitioners. Sometimes you get different views or opinions e.g. on backlog items and user stories but that’s also the beauty. It’s not carved in stone. When using Scrum, you have to think, rethink, discover and adapt. And don’t forget it’s all about people! A must read!

Throughout the book you get many references to articles, et cetera on the web. It would help the reader if small QR codes were added to the text (I often make mistakes by reading/typing a I, i, L or l).

In the book there is a reference to the Flow framework. In a next blog I will dive into this framework to see where it fits in my Bird’s eye view on the agile forest.

To order (managementboek.nl) : 97 Things Every Scrum Practitioner Should Know

To order (Amazon.com): 97 Things Every Scrum Practitioner Should Know

To order (Bol.com): 97 Things Every Scrum Practitioner Should Know

Youtube: Gunther Verheyen answers questions about “97 Things Every Scrum Practitioner Should Know”

Review Rethinking agile

51nTAg-en9LRethinking agile – Why agile teams have nothing to do with business agility written by Klaus Leopold is great book to cope with agile transformations and what you have to do to increase the chance of success. It definitely busted the myth that having agile teams makes you agile.

The book is divided into four parts: the problem, the causes, the first solution, and the result.

The book starts with a case study of an organization that wants to optimize their time-to-market. They want to reorganize their teams. All teams should be cross-functional and organized according to the premise: One team, one product. Teams could choose the agile method they wanted to use, and the following requirements needed to be fulfilled: work should be visually managed, hold daily stand-ups, retrospectives, throughput and cycle time must be measured. All 600 IT employees followed a one-day agile mindset basis training. Management realigned the teams according the product structure and the reorganization took place through self-organization (marketplace). External support in the form of 16 coaches helped the teams to run system design workshops and create Kanban systems to visualize and manage their workflows. As a result, all teams were fully transformed and fulfilled the stipulated agile framework conditions. But the ability of the teams to deliver had not changed much! Projects are not being completed more quickly!

The author describes four causes why their projects were not completed more quickly.

Cause #1: The pitfall of simplistic inference in the change process

    • Implementing agile is a means – not a purpose – for achieving business agility
    • The change process as a project (pull versus push principle)
    • Change is a new organigram – mixing up cause and effect.

Cause#2: Dealing with dependencies between teams and products. They forget to consider:

    • One product, many teams
    • Dependencies between products
    • Peculiarities in knowledge work.

Cause #3: An incomplete value stream

    • What is happening downstream? Integration? testing? release? …?
    • What is happening upstream? Idea pool? Triage? Business case, decision making. …?
    • End-to-end management of the value stream was missing.

Cause#4: WIP limits at the wrong place

    • Reducing WIP: Park the work in front of the system (option pool)
    • Limit the initiatives, the number of projects in the system (strategic portfolio management).

As a solution the author discusses the added value of the flight level model as a communication instrument to identify the effect of specific improvements at operational level (team), coordination (value stream) and at strategic portfolio management (company) and to discover where within the organization it makes sense and/or is possible to leverage improvements (visualizing the work, setting WIP limits, establishing feedbackand determining and implementing improvements). On top of that he sees three areas of improvement: make dependencies visible (product boards), integrating the upstream (be aware of traps: too much, too exact, too unnecessary) and strategic portfolio management (strategy board).

The book ends with a summary to make your business agile:

  • Start at the top (the first agile team)
  • Agility begins with the change process
  • Focus on the goal not on the method
  • Agility is not a team affair
  • Identify the flight levels (operational level, coordination and at strategic portfolio management)
  • Manage and eliminate dependencies
  • Incorporate the drivers for lean business agility at every flight level (visualize, manage WIP, feedback loops, improve).

Conclusion. Great book and nice illustrations (by Matthias Seifert). A must read for those who are starting or in the middle of a business agility transformation to learn what others did wrong and what you can do to increase your chance of success. A next print could benefit when a contents paragraph and chapter and paragraph numbers are added.

To order (Amazon): Rethinking agile

To order (bol.com): Rethinking agile

Review: DevOps for the modern enterprise

devopsDevOps for the modern enterprise – winning practices to transform legacy IT organizations is a practical book based on the experience of the author Mirco Hering.

The book is divided into three parts. The first part explains how to create the right ecosystem for success. The second part puts the people and organizational dimension in the spotlights and the last part emphasizes on technology and architecture aspects. Every part contains four chapters and at the end of each chapter you get some steps to exercise to make it more practical.

The first part – creating the right ecosystem – starts with the usage of value stream maps to visualize your IT delivery process and a jump-start of the transformation with an initial roadmap and governance approach. As a next step you have to analyze your application portfolio (criticality of application, level of investment in application, preferred frequency of change, technology stack). Based on this analysis you should focus on a minimum valuable cluster (MVC) to speed up the complete cluster by uplifting the MVC. The following chapter discusses the added value of guidelines for selecting new applications and the strengthening of your architecture by creating and empowering ecosystem. The following aspects can be used to start the assessment of architecture maturity: auto scaling, self-healing, monitoring and capability for change. When looking at your packages, in case you can’t or don’t want to replace, the following approaches are explained: leverage your system integrator, leverage user groups, strangle the application and/or incentivize the vendor to improve their product. In line with the types of applications (differentiator applications, workhorses and true legacy) you have to find the right partner that fits your ambition and culture.

As stated, the second part put the people central. How can you provide your people with the right context for their decisions, what team structure you should choose to enable autonomy and purpose, how to shift from legacy thinking that has caused many test automations projects to fail, and how to manage your people better? Based on the “burger organizational chart” the author discusses delivery governance (with an agile governance function, DevOps governance function and quality assurance),  the test automation center of excellence, agile teams (maybe clustered in an agile release train, team by location, team by function and team by technology) and the platform team (test automation, automated app release and environment provisioning). A separate chapter is dedicated to testers and the importance of quality. The last part gives more generic people-oriented techniques and ways of working like one-on-ones, feedback, delegation, creating a blameless culture and measuring your organizational culture.

The last part looks at the right way to choose DevOps tooling, what makes a good DevOps architecture, how to evolve your application architecture, how to leverage the relationship between DevOps and cloud computing, what each delivery model looks like, and how these models impact your organization.

The delivery models are:

  • Continuous delivery model deploys applications automatically into persistent environments (either cloud or on premises)
  • Cloud-enabled delivery model deploys applications automatically after provisioning a new environment from the cloud or data center. Main difference compared to continuous delivery model is the maturing of the infrastructure practices – infrastructure as a code.
  • Container-enabled delivery model deploys applications as a set of containers into one or more hosts that are dynamically created. Main difference compared to cloud-enabled delivery model is the maturity of the container practices and the more modular application architecture.
  • Serverless delivery model (potential future model) where you don’t run services as such but rather write a function to perform some business logic. When the function is called, an instance is created just for the duration of the function call (e.g. Amazon Lambda).

To evolve your architecture over time you can use the strategies decoupling (two speed delivery model), going on a diet (paying down the technical debt and making the core more agile), let’s try it on the side (green field setting) and erode the core with microservices (a service that serves one purpose; it is self-contained and independent; it has a clearly defined interface and isolated persistence). The book ends with different aspects of levering cloud-based services. Benefits of the cloud are cost benefits, ease of setting up redundancy for resilience, the scalability of resources, and the strong ecosystem of related services that you would otherwise have to build yourself. on the risk side we see the dependency on a third-party provider, the challenges with data sovereignty, and the risk of being attacked because you are on a popular platform.

Conclusion. Reading this book and execute one or more of the exercises gives you one of the reasons why so many agile transitions fail. It’s not only about creating, sometimes only renaming teams into agile teams but you have to look at the complete ecosystem, your application landscape, the application architecture and your delivery models. A must read for those who are transforming their IT organization towards a more agile organization.

To order: DevOps for the modern enterprise


Review: The art of business value

38907639._SY475_Mark Schwartz is the author of The art of business value. You could see this book as his quest to the concept of business value.

Is business value the same as customer value? The question of business value is the question of purpose, motivation, mission, and direction. It is a question of value and values.

In the first two chapters the author examines many different ways how known (agile) experts use or describe ROI, NPV, MVA, Profitability Index, IRR and payback period. All these measures are really just proxies for what the company ultimately values, like shareholder value, and they are unlikely to be useful to a product owner making feature trade-off decisions.

The author abandoned the idea that business value is a simple formula, known ahead of time and simply applied to user stories, and accept that business value requires interpretation and asks himself whether the model of a product owner (or business representative) doing all the interpretation continues to make sense. Many Scrum teams struggle with getting the product owner to prioritize non-functional requirements, such as security stories, work that reduces technical debt, alongside functional user- facing requirements. Following Eric Ries’ lean start-up approach, the product owner is no longer the interpreter of business value. Instead, value is discovered by the team that does validated learning experiments and hypothesis testing.

In a next chapter bureaucracy is put in the spotlights. Bureaucracy is all about rules and proving that they have been followed. Bureaucracy often leads to compliance requirements. But what if those requirements actually are adding business value?

Management, just as culture and bureaucracy are often viewed as impediments. Is the CIO responsible for executing projects, or responsible for delivering business value from IT investments? The CIO’s challenge is to show that IT is adding concrete business value to the organization. The IT organization must become an interpreter of business value as well as a provider of technical skills, and its interpretation must influence not only the behavior of project teams but also the enterprise’s business strategies.

The author finally gives his definition of business value: “Business value is a hypothesis held by the organization’s leadership as to what will best be accomplish the organization’s ultimate goals or desired outcomes”. He states that the agile team will be responsible as a whole for delivering business value.

The last chapter describes thought experiments to see if they influence the way you think about business value. E.g. adopting a DevOps culture and a Continuous Delivery pipeline or six ways to think about the CIO’s role.

Conclusion: The book The art of business value is not easy to read but after you have read it and executed one or more of the experiments, you have a much better idea how to cope with business value. And it gives valuable insights in the role of the product owner and the agile team too.

To order (Amazon): The art of business value

Review Project Excellence Baseline

A few weeks ago, I was for a three-day assessment training regarding the IPMA Project Excellence Model in Vilnius, Lithonia. For 3 days, by using action learning we familiarized ourselves with the Project Excellence Model. This model will be used to judge which large and mega-sized projects will receive the project excellence award.

IPMA_PEB_2019__cover_previewThe Project Excellence Model (PEM) is described in the book Project Excellence Baseline for Achieving Excellence in Projects and Programmes. This Project Excellence Model is a great tool for continuous improvement of project or program management in your organization? It’s not a maturity model. The main purpose of the Project Excellence Baseline (PEB) is to describe the concept of excellence in managing projects and programs. It complements the IPMA Individual Competence Baseline (IPMA ICB) and the IPMA Organisational Competence Baseline (IPMA OCB).

The book describes a project in its organization’s internal and external context. The concept of project excellence is based on continuous improvement (plan-do-check-act), the role of sustainability and the role of leadership.

The PEM model structure enables easy reporting of the outcomes on all management levels via three levels:

  • Areas: The main components of the model: People & Purpose and Processes & Resources and Project Results
  • Criteria: to enable detailed feedback about the levels of excellence on a particular project
  • Examples: actual practices typically found in excellent projects.

QRC (PEM, 200324)All three areas of the model strongly interact with each other. See the arrows in the figure. This means that none of the areas should be developed in isolation and each of the areas should be actively used to develop excellence in the remaining two. Due to interaction between areas the following business value can be secured: performance, effectiveness and efficiency, reliability, flexibility, continuous improvement, scalability and sustainability.

The People & Purpose area is divided into three criteria: A.1. Leadership & Values; A.2. Objectives & Strategy; A.3. Project Team, Partners & Suppliers.

The Processes & Resources area is divided into two criteria: B.1. Project Management Processes & Resources; B.2. Management of Other Key Processes & Resources.

The Project Results area is divided into four criteria: C.1. Customer Satisfaction; C.2. Project Team Satisfaction; C.3. Other Stakeholder Satisfaction; C.4. Project Results and Impact on Environment.

In a separate chapter the assessment of project excellence, the assessment process itself, the role and competences of project excellence assessors, the scoring approach and the project profile are described in detail. The project profile consists of three general scores, respectively for People & Purpose, Processes & Resources and Project Results. Examples of conclusions after assessing could be leadership driven projects with low process maturity, process driven project with low leadership and/or sense of purpose and, balanced projects combining great leadership and a strong sense of purpose with a strong process culture.

In the annexes you get a very detailed description of the Project Excellence Model and the scoring tables for the model areas and criteria. The last annex explains the IPMA Global Project Excellence Award assessment and its benefits for stakeholders, applicants and for finalists and winners.

Conclusion: Not only a book for assessors or applicants of the IPMA Project Excellence award but for project sponsors, project or program managers or PMO/Centre of Excellence staff too who can use it as a great tool for continuous improvement of project or program management.

To download: Project Excellence Baseline

Introduction to the Project Excellence Baseline

AGILE NXT 3rd edition

AgileNXT_Magazine_3In this third edition of AGILE NXT — a magazine designed by Xebia’s thought leaders and experts to inspire and inform you, offers 15 new insights:

  • The Ultimate Model for Managing Performance in Agile Environments (Daniel Burm). The Agile performance management model consists of five main building blocks: purpose, strategy and goals, whole system alignment, performance models and metrics, coordinated performance management routines and high-performance culture and behavior.
  • Schiphol’s Customer Value Takes Flight With A New Mindset (Esmé Valk and Ellen Barree). The program is all about changing mindsets and behaviors bottom up, without having a structural blueprint thought out in advance.
  • Stop Focusing on Agile & Start Adding Real Value (Kevin Bakker). In many organizations, Agile and Scrum have become container concepts—their true definition and purpose forgotten. So, it makes sense to regularly reflect with your whole team on the what and ways of working Agile. As an organization, keep asking, “what problem do we want to solve?” Does your approach add the most value, or are there other options?
  • Need Business Agility? Boost Your IT Capabilities (Bart Bouwers). 5 capabilities are explored: Build the Right Product, Continuous Delivery & Release on Demand, Detect & Recover Fast, Easy Infra & Containers, and Always Compliant & Always Secure.
  • Change the Way You Change – A result-Driven Growth Hack (Ron Meyer and Paul Immerzeel). Based on an agile transformation that is not yet showing results, the sponsor asks himself the following questions: What do I sense?, What do I feel?, What do I think?, What do I want?, and, What can I do about it?
  • Agile Doesn’t Create Future-Proof Organizations (Riët Broekhuizen and Ellen Barree). The 4th revolution requires radical innovation, where organizations experiment with new revenue models and structures, automate all repetitive actions, eliminate bureaucratic processes and employ the latest technologies in an open and transparent environment.
  • Digital Business: Make it Happen, and Make it Stick! Digital Success Requires a Healthy Dose of Common Sense (Edwin Oldenbeuving). There are seven skills for life and work in the 21st century: cooperation, communication, problem solving, self-reliance, creativity, critical thinking and social and cultural skills.
  • Portfolio Management – Through Different Glasses (Jarl Meijer). Five Tips to Reduce Portfolio Management Complexity are discussed: Nurture a culture of trust and transparency; Scale down to independent units of max. 125 people; Provide clear company-wide goals and priorities; Focus portfolio management sessions on strategic choices and solutions for impediments; Drive performance growth and predictability.
  • Cloud Migration Will Disrupt Ops as You Know It (Mark van Holsteijn). Three strategies for cloud migration and their effect on IT Operations are explained: rehost, redesign and re-platform.
  • Artificial Intelligence for Leadership decision-making (Rik de Groot). AI supports decision-making by: Analyzing the situation based on data, trends, historical information, and information from outside the organization; Giving leaders insights and options; Providing fact-based information; Looking at the big picture instead of local optimization.
  • You Can’t Escape Team Behavior (Anne Davidse and Marianne Pot). The escape room creates a bubble within which you can better understand team behavior. By analyzing how individuals’ function in a high-pressure team challenge, you can identify opportunities for improvement, spot natural leaders, and build trust.
  • Deep Democracy: Listening to the Wisdom of the Minority (Kenny Baas-Schwegler). Checking in, spreading perceptions (listen to all options, share other options and different viewpoints, and raise hands for recognition), deep democratic voting (majority vote is needed, sincere apology to those members who aren’t part of the majority, collect their arguments and vote again and repeat cycle if there is no full consensus), go fishing (make explicit agreements with each other, everyone says what they have to say), equality in differences (vote again).
  • Scoring an “A” for Agile in Architecture (Winfried Scheulderman). An overview of characteristics of a modern IT architecture process and six considerations to take into account if you want to introduce modern architecture.
  • The Agility Gap: What’s Really Behind It? (Daria Nozhkina). When an organization primarily focuses on its financial priorities, it directly impacts its approach to Agile transformation, which, in turn, influences the transformation’s success.
  • Common Sense Scaling: The 10 Do’s and Don’ts for Delivering Value with Multiple Teams (Evelien Acun-Roos). Start small, involve, change habits and behavior, measure and seek knowledge and experience.

Conclusion: a mix of articles. Some articles are too short to make a difference. Other articles definitely offer new insights. In total it’s definitely worthwhile to download and read the magazine.

To download: www.agilenxt.com


Review Formula X

9781950367221-480x600Jurriaan Kamer and Rini van Solingen are the authors of Formula X – How to reach extreme acceleration in your organization? It’s a business fable that shows which steps you should take to drastically accelerate the time-to-market in your own organization.

In this novel, we follow Ronald Verhulst, the director of a major kitchen manufacturer who is confronted with an advertisement, placed by the major shareholder promising that kitchens can be operational within two weeks from order. If it takes longer, you get the kitchen for free. This sounds disruptive if you know that the current time-to-market is twelve or more weeks. Based on a number of advices from a Formula I team, Ronald shows how to translate these lessons learned into his own organization and to implement them step by step. Do you have any idea how often a Formula I team evaluates the way they operate and how many improvements are being made between two races?

But before Ronald actually gets to work on this advice, he started to work with the Full Control Consulting Group. They helped Ronald to implement Total Efficiency Management with which measurable processes can be accelerated. Completely in line with his own adage “Trust is good, but control is better!” This approach didn’t work, but it took some time to gain that insight. He sends the Consulting Group away and started with the lessons learned from the Formula I team.

QRC (Formula X, 200313) v1.0To Download: QRC (Formula X, 200313) v1.0

From the conversation with the driver and the team boss of the Formula I team, Ronald manages to distil six lessons (the authors call this the FASTER model consisting of six parts, the initial letters together form the word “FASTER”):

  • Focus and clarity – a clear and inspiring goal that works as a compass
  • Accelerate decisions – reversible decisions and distributed authority
  • Simplify – the art of omission and simplification
  • Team Engagement – intrinsic motivation, autonomy and ownership
  • Elementary physics – the age-old basic laws for speed and acceleration
  • Rhythmic learning– learn through a cadence of recurring interaction moments

In the book we get the translation of all these lessons to the kitchen manufacturer and we see the effect but also the struggle to win the organization for taking these steps. In the beginning we see a silo organization in which every department in itself works efficiently, but ultimately it is all about the result of all steps together. By learning on the basis of the aforementioned lessons and making changes based on them, the lead time is improved step by step. In the end, a final drastic step is taken. The ‘walls’ between the departments such as sales, planning, purchasing, production, installment and customer contact are broken down. Multidisciplinary teams are created that are responsible from the first customer contact to the final delivery of a kitchen. It may be clear where it ultimately leads. There are now teams that are able to install kitchens very quickly in a fixed cadence, with a lot of satisfied customers and a happy large shareholder as a result.

Conclusion: The chosen approach in which we learn from a Formula I team and apply it to a kitchen manufacturer shows that you can do a lot in a non-IT company too to improve your organization’s agility and what this means for you in your role as manager ( e.g. letting go and decentralized decision making). Pouring it into a business fable makes it fun and easy to read. Personally, I find the description of the current situation and “improving” through control steps too long. This covers more than half of the book and by shortening that part, the book could have gained in strength. Nevertheless, the book is definitely worth reading and offers plenty food for thought and potential experiences!

While writing this review they came to replace my boiler. A team of 2 mechanics arrived at 8 AM. They were ready around noon. Small problem: the digital thermostat had an error message. No connection with the boiler and therefore no heating! They failed to solve it. A connector between central heating and thermostat turned out to be broken. This happened them quite often when replacing a central heating boiler. However, this energy supplier had a separate team for this. After a 30-minute call, they told me that I would be called back within half an hour. That indeed happened and the team was due to arrive that afternoon between 1 and 5 PM. Around 4 PM another mechanic came with a new connector. Solved in five minutes. Suppose this energy supplier had read this book, they would probably have integrated this thermostat team with the heating installers after evaluating these types of problems. Many phone calls, an extra ride, and the turnaround time at my place would have accelerated by 50% and as a result a cost reduction for the supplier!

A week later I receive a letter for the yearly maintenance of my boiler. This letter still involved maintenance of my old boiler. After a few phone calls, it became clear that the back office had not yet made the changes. Another example of different teams / silos. In the meantime, I have received three more letters about scheduling regular maintenance, so I have to give them a next call and bring this book to the attention.

To order (managementboek): Formula X

To order (Amazon.com): Formula X

How to accelerate decisions: 

Review DARE

9789493056183-480x600-2DARE – The mindset for successful innovators in the digital age written by Eric de Groot and Matthijs Rosman is a recipe to innovate and grow your business.

DARE stands for defiance, adventure, realism, endurance. It helps those who want to innovate in the ‘digital age’ but are hesitating to take the first steps.

The book is built around ten key more or less connected, frequently asked questions of innovation and growth in the digital age, clustered in three parts (following the three stages of growth initiate, create and scale):

  1. Do I know what I don’t know? Understand trends in technology and culture.
  2. Am I still in business in 5 years’ time? Which value is your company adding in 5 years’ time? To whom?
  3. Can I kick it? What is the best approach to reinvent your business?
  4. Who are my growth BFFs (best friends forever) and BEFs (best enemies forever)? What is the profile of ideal innovation partners?
  5. Am I willing to experiment or die? Embed a framework to get organized for exponential growth.
  6. What are the rules of the game? Create a growth culture that helps sustain new ideas.
  7. Do I have the basics in order? Learn how to make room for innovation.
  8. Do I go by facts or fiction? Discover that data is the key element to nurture growth.
  9. How do I turn on the growth engine? Learn best practices on how to successfully scale.
  10. How to achieve full maturity? How to lever for change.

At the end of the chapters a comparison is made with Leonardo da Vinci’s actions, way of working or thinking. The authors see Leonardo as the quintessential DARE practitioner.

And if these ten questions are not enough, every part starts with some rarely asked questions to get you started and keep you going.

QRC (DARE, 200303) v1.0To download: QRC (DARE, 200303) v1.0

Initiate captures the first four questions. It is about understanding what is happing around us. It is about situational awareness; trying to figure out how your organization is impacted and what your response should be. The (digital) transformation is not new but a fact of life. Some relevant megatrends which are discussed: changing demographics, globalization & shifting economic power, rise of the global middle class, accelerating urbanization, climate change and resource scarcity, privacy 2.0, unbanked, deep fake, quantum computing and technology. All these megatrends have a profound impact on industries and businesses. Think about customer centricity, shift from ownership to usage, servitization, platform business, connectivity and data, dark commerce and production on demand.

Create covers the next four questions. It deals with the process that puts the customer first in your transformation process. It explores the need for experimenting in ‘controlled’ spaces with a blended approach of design thinking, lean startup and an agile way of working. Managers and employees need to make five fundamental shifts: from control to enable, self-organizing, from individual to team, from long sequential steps to short iterative cycles, from management lead to customer lead and from first time right to celebrate failures (and learn from them). Marketeers should learn the new 5 P’s in marketing: Positioning, Partitioning, Probing, Prioritizing and Participating.

Scale is the last part and answers the last two questions. Scale refers to the making of a true commitment to innovative growth and daring to make decisions with drastic consequences. Scaling is making the next step in new markets – beyond the early adopters – in new customer groups and geographic. As you move from ideation to execution, there are five key areas that you need to focus on in scaling up your new venture: market, product, process, organization and finance. Sustainable growth is about mastering all the stages, deploying the various tactics within with extreme velocity and persistence (awareness, acquisition, activation, retention, revenue and referral).

The book ends with the innovation readiness benchmark. Eight groups with, in total 60 detailed questions: innovation strategy, customer centricity, organizational agility, innovation portfolio management, organization of innovation, innovation skills and competences, innovation performance and disruption of risk.

Conclusion: Definitely not a theoretical book but inspirational and practical with many real-life examples! It helps you to diagnose and innovate your own business. A must read for those who want to survive in this disruptive era.

To order (managementboek): DARE

to order (Amazon): DARE

Video Dare Mindset

The International PMO standard from AIPMO

aipmo-logo-1AIPMO is developing the first ‘leading’ international PMO standard based on a combination of research findings and expert knowledge. Developing an international standard is big responsibility because it can create or destroy value depending on the content, how it is written and how the content is interpreted. For example, if an industry is in a mess and you standardize a mess, you keep it in a mess. A leading standard is very different to a lagging standard because the content of leading standard is taken from evidence-based research of the most successful organizations in the world, put this into a framework and tests it for 3 years. Over this period, it is improved and optimized and then and only then is it written into an official standard. Lagging standards are based on what the author team knows and it is written into a standard and published without testing.

Ultimately it can lead to a Master and full MSc and DBA from SBS Swiss Business School.
There are three core certifications (IPMO-F, IPMO-P and IPMO-E) that provide in total 15 days of training, workshops, real case studies, focus groups, coaching and exams. Other PMO certifications such as Axelos’ P3O or Value Ring’s PMO-CP do not compare to AIPMO’s core PMO certifications especially in terms of approach, content, structure and outcome. AIPMO’s core PMO certifications covers much more!

To support the certifications and running or assessing a PMO there will be 7 core publications (still work in progress). In the coming period, I will review these publications and use my blog to inform you about those publications.

IPMO Certifications

IPMO-FIPMO-F (Foundation, 5 days): Focus on the PMO team member and project team member:

  • Understand how PMOs fit into the world of projects, programs, and portfolios
  • Understand the benefits of viewing PMOs in terms of services
  • Know what are PMO capabilities, how they are constructed in terms of competencies, tools, and techniques
  • Understand the PMO lifecycle framework and which phases and processes are most relevant for a PMO team member
  • Learn the key PMO tools and techniques including templates you can take back to your organization
  • Understand what are the key documents PMO use to run, monitor and control PMOs
  • How to be confident in knowing what to do in the majority of PMO configurations.

IPMO-PIPMO-P (Practitioner, 5 days): Focus on the PMO manager, project manager and functional manager – for one PMO:

  • Extend your understanding of project, project and portfolio management disciplines in context of PMOs
  • Understand how to setup and run a successful PMO using AIPMO’s strategic lifecycle framework. The PMO could be a single project based PMO, to enterprise-wide PMO based
  • Develop your own PMO’s Vision, Mission, Strategy and Services (1-day workshop)
  • Describe the different roles of PMOs in a single and networked context and across different levels of the organization
  • Discuss group experiences to share knowledge
  • Understand PMO success factors and progress you journal to become a competent PMO director/PMO manager/team member/consultant.

IPMO-EIPMO-E (Expert, 5 days): Focus on the PMO Director, PM Director and consultants:

  • Extend your understanding of project, project and portfolio management disciplines in context of PMOs
  • Understand how to setup and run successful PMOs ranging from a single project based PMO to enterprise-wide PMOs based on AIPMO’s Strategic PMO Lifecycle Framework
  • Design organizational PMO topologies and PMO Service topologies
  • Discuss group experiences to share knowledge
  • Understand PMO success factors and progress in your journey to become a competent PMO director/PMO manager/team member/consultant
  • Become confident and motivated to mentor others in getting the most out of PMOs.


  • PMO Services and Capabilities
  • PMO Principles
  • Project, Program, Portfolio Principles
  • Latest Research on Single to Enterprise-Wide PMOs
  • From Single to Enterprise-Wide PMOs
  • PMO Standard (AIPMO’s Body of Knowledge)
  • PMO tools & Techniques

AIPMO book coversNot all books are published yet. AIPMO produced the world’s first PMO Principles Booklet in 2017. The first book I reviewed in 2020 will be published in the coming months.

Review PMO Services and Capabilities

The book PMO Services and Capabilities is written by Stuart Dixon and Dr Robert Joslin. This book is unique as it addresses in a systematic and structured way to explain for each PMO service including the associated attributes how to implement service. There are over 200 PMO services described in this book. The book is based on a three-level categorization system that allowed services to be grouped (service groups) with a service domain. A service domain is related to an area of experience. There are 22 service domains explained.


Domain Design Operate Monitor
Administration Administration Events

PPM Admin

Benefits management Benefits framework Benefits identification Benefits realization
Capacity and capability management Capability design Capability operations

Capacity operations

Capability monitoring

Capacity monitoring

Change control Change control planning Change control operations Change control monitoring
Change management Change management design
Configuration management Configuration management design Configuration management operations Configuration management monitoring
Consultancy Consultancy service

Consultancy wisdom

Financial management Financial design Financial monitoring Financial operations
Governance Governance Design Governance Operation
Integration Integration
Issue Management Issue planning Issue resolution Issue monitoring
Knowledge and Innovation Innovation Operations
Knowledge management Knowledge management design Knowledge management capture

Knowledge management dissemination

Knowledge management innovation

Knowledge management monitoring
Methodologies Method design Method operations
PMO development Career development

PMO design

People development

PMO leadership

PMO management

PMO monitoring
Portfolio management Portfolio design Portfolio operations Portfolio monitoring
PPM Tool support PPM tool design PPM tool operations
Quality management Quality design Quality operations Quality monitoring
Risk management Risk planning Risk assessment

Risk identification

Risk response

Risk monitoring
Schedule management Scheduling Design Scheduling Operations Scheduling Monitoring
Stakeholder management Communications design

Stakeholder design

Communications operations

Stakeholder operations

Communications monitoring
Supplier management Supplier management design Supplier management operations Supplier management monitoring

As stated, each domain is divided up into one or more service groups (approximately 70). A service group is related to one of the 3 main activity types that the PMO is expected to do:

  • Design – a PMO can provide the standards, tools, templates, processes, procedures, help, guidance, framework that defines how work will operate within that particular service domain
  • Operate – a PMO can operate (or perform) some of the work on behalf of other people within the project (program or portfolio) team. If the PMO does not perform this service then, if this is performed at all, then this will be done by another member of the team
  • Monitor – a PMO can review the work done by others (or even other parts of the PMO) and provide and independent quality assessment and check. They can provide reporting across the service domain and highlight items that require escalation.

Not all of the PMO activities fall neatly into the 3 groupings. For some of the services the operate activity is split up into different groups. Where this has been done it has been for ease of comprehension as it fits more naturally into how the service domain operates.

Within each service group there are one or more services. A service is the lowest level of offering that a PMO can provide. Each service has 2 audiences, although only one of those may read the book:

  • Each service is described for the PMO who will be delivering the service. It describes what the service is, how it can be delivered, who is involved in delivering it along with some detailed hints and tips. The PMO capabilities needed to fulfill this service section lists the competences and techniques and generic tools. The related services section describes other services that the PMO may want to consider when putting together their service catalog.
  • The service is described from the perspective of the recipient of the service. What can they expect to get from this service and why would they want the PMO to be able deliver this for them.

Conclusion: I have never seen such a complete overview of PMO services. It is structured as a reference work and will bring a lot of value for those involved in PMO’s. Reading the title, I was expecting explanations of the related PMO capabilities too but I understand this will be addressed in the next version of the book. What you get are lists of competencies and techniques and generic tools. Just the names and nothing more. For the tools I can understand this because there is a separate PMO Tools & Techniques book. I don’t see a separate competences book, so this maybe something to include in the second print or as a separate book (I am aware that the PMO Flash mob in the UK is working on a PMO competences book, maybe this book can be used). This book is already more than 700 pages! And that brings me to another point. Some of the services are too small and detailed. I think it makes sense to analyze if each service can be delivered autonomously by a PMO. If it can’t, integrate it with the related service and remove it as a separate service.

As mentioned, the book uses a division around the 3 main activity types (design, operate, monitor). If I look how I structured PMO’s in Europe and Asia you could also think about a division between services offered by a permanent PMO (offering portfolio management services, Center of Excellence services and setting up, sourcing and closing temporary PMO’s to support a project or program) and the specific services offered by those temporary PMO’s. In the construction industry they group services in a different way too. Probably you have to create your own groupings when building your own PMO and setting up your own service catalog.

Services to create the permanent PMO (e.g. designing portfolio manager job descriptions) are in my opinion not real services but part of the process to build your permanent PMO. At this moment I am not aware if this journey will be covered by one of the other books. If not, it makes sense to include it one of the books or create an additional book covering this.

I am looking forward to the next AIPMO books. If these other books offer the same kind of views, ideas, details, tips, tricks and case studies then I think this initiative will be very important and of huge value for the PMO community.

At this moment there are no plans to publish this PMO Services and Capabilities
book outside of being in the AIPMO membership section and on-line.

In a next post I will review the PMO Principles book (available on Amazon) and look at some other more specialist AIPMO certifications and I will include a short survey to understand if there is demand for these AIPMO training classes and certifications in the Netherlands.