Scaling agile in organisaties

9789401806213-480x600Ondertussen is de tweede geheel herziene druk van mijn boek Scaling agile in organisaties verschenen. Sprak ik in de eerste druk over ruim 30 agile frameworks of aanpakken, in deze druk passeren 70 agile frameworks of aanpakken de revue. Het boek beval de meest recente versie van mijn bird’s eye view on thew agile forest en neem ik de lezers mee wat het betekent voor organisaties als ze doorgroeien van een enkel permanent agile team naar vele agile teams. Daarbij ga ik ook in op de vraag wat dit betekent voor de rol van projectmanager, PMO en portfoliobureau. Uiteraard zijn de hoofdstukken die gewijd zijn aan SAFe (nu versie 5.0), LeSS, Nexus, Scrum @ Scale, spotify, AgilePM en PRINCE2 Agile gebleven. Er zijn echter nieuwe hoofdstukken bijgekomen met daarin uitgebreide beschrijvingen van Disciplined Agile (ondertussen overgenomen door PMI), AgileSHIFT en bimodal portfoliomanagement. Daarnaast van vele agile aanpakken korte beschrijvingen. Ten opzichte van de eerste druk komen er nu verschillende frameworks aan bod die helpen bij het creëren van een agile cultuur of mindset zoals AgileSHIFT, Open Space Agility en Agile Fluency. Ik wens jullie veel leesplezier en mocht de behoefte er zijn dan ben ik gaarne bereid om in een sessie van een uur of langer uitgebreid in te gaan op de inhoud van het boek en jullie een overzicht te geven wat er zoal speelt in het agile landschap.

Bestellen: Scaling agile in organisaties

Are incremental and iterative the same phenomenon or not? (part 2)

webinarIn the first part of this article (see previous post) I compared a waterfall and an agile approach when creating a payment app. In this second part of the article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map. At the end you will find the corresponding mini webinar.

As stated, I noticed that students often mix the words iterative and incremental together. In figure 4 you can find four quadrants as a result of a horizontal line presenting incremental or not and a crossing vertical line representing iterative or not[1].

In the left lower corner, we see the approach where there are no iterations and no increments. This is the waterfall approach. All activities (design, analysis, build, test and deploy) are performed once for the entire project. In this case we see a single delivery of the final product based on a fixed scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is to manage cost. See also the waterfall approach to develop the payment app in the first part of the article.

In the lower right quadrant, we see an incremental approach without iterations. This is a staged or incremental delivery of smaller parts the product. All activities for a given stage (design, analysis, build, test and deploy) are performed once. Within a given stage the scope is fixed, but the total product is based on a more dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is speed of delivery.

Dia8Figure 4: Iterative versus incremental

In the left upper quadrant, we see a spiral or iterative approach without increments. This is a single delivery where the final product is created by using several iterations. A good example of this approach is design thinking. In the graph you see a sequence of the activities framing, analysis, idea generation, realization and reflection. This sequence will be performed repeatedly or iteratively where in every iteration you get closer to the final, correct or required, product. In many cases this final product is a prototype or model. In this spiral approach we have a dynamic or flexible scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is the correctness of the solution.

In the upper right quadrant, we see the agile approach with increments and iterations. Scrum is a good example[2] of this approach. At the end of each increment, often called a sprint or timebox there is a delivery of an increment of the product. This increment is the result of many iterations to develop small but correct parts, often called user stories or backlog items, of the product. The final product will be delivered piece by piece. In this agile approach we have a dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is customer value via frequent deliveries and customer feedback. See also the agile approach to develop the payment app in the first part of the article.

MVP or MMP?

In figure 4 you can also find the acronyms MVP and MMP. MVP stands for minimum viable product (Eric Ries, Lean Startup) and is a version of a new product or service which

allows a team to collect the maximum amount of validated learning about customers with the least effort. The MVP for the Dropbox service was a simple movie. This means that the P in MVP could be a completely different product in comparison with the final product.

I often use the following example of a new financial product. An enthusiastic sales manager has a great idea regarding a new financial product. He thinks that they can sell at least 100.000 of these products. Together with some finance experts, they design the product in a couple of months. A development team is assigned, and it takes them 4 months to develop the product. In parallel commercial brochures are developed and the product is launched with a big event. Unfortunately, just a few people buy the product. If we follow Eric Ries’ approach we could make the assumption that 10% of their web users are interested in this product. To test this hypothesis, they develop a MVP. In this case a simple button on the homepage. If you click you get a screen with a message regarding this new product and the question to leave your mail address behind if you are interested. Less than 1% of the visitors pressed the button. The product will not be developed. They saved a lot of scarce resources.

If we take a closer look at figure 4, we see the potential usage of MVP’s in all quadrants. When using a waterfall approach, you could create a MVP in the first design phase to check if there is a business justification for the project. The same can be done in the first phase of the first increment when following a staged delivery. In some cases, the result of your spiral, or design thinking approach could be a MVP. At the beginning of an agile approach the MVP could be beneficial too.

Many people see the first product delivered at the end of your staged delivery as the MVP. This could be the case but, in most cases, this is not a MVP but a MMP. MMP or minimum marketable product is the smallest product that can bring value to your customer. See the staged delivery or agile approach where a MMP could be deployed.

How does an agile delivery looks like?

Now it is clear that incremental and iterative are not the same and we understand the usage of MVP and MMP, we can explore in more detail how an incremental and iterative delivery could look like. You probably have seen Jeff Patton’s famous example of the Mona Lisa where the painting is created piece by piece (staged delivery) or in the first increment only a rough sketch and every new iteration more details are added to the sketch and ultimately you have the final painting (incremental and iterative or agile delivery). In the first situation you must already have a detailed idea of the final product and in the second situation you just need a high-level outline and changes are much easier to make. If we look at figure 5, we see a story map for a new product called ABC.

Dia9Figure 5: Story map for product ABC

The product owner envisioned seven features for this product. The first four features are must haves. Feature 5 and 6 are should haves and the last feature is a could have. Many would call this MoSCoW prioritization (Must haves, Should haves, Could haves and Won’t haves). Every feature in itself can be sliced down in smaller parts. In the figure you see features with must, should and could have user stories. A feature can be a must have but that doesn’t mean that all the underlying user stories are must haves too. Or a feature can be a should have but if you implement that feature some user stories are must haves and others are should or could haves.

To implement this ABC product, you see five increments or releases. The first one is the minimum marketable product. This MMP consists of the first two must have user stories of feature 1, and the first must have user stories of feature 2 and 3. Release 2 contains the next two must have user stories of feature 1, 2 and 3 (iterative development). Product development continues by implementing the next releases. With every release the customer value increases. After release 5 the product owner stops implementing user stories. Feedback from the customer showed him that the ABC product is ‘fit for purpose’ and he takes the Agile manifesto’s principle Simplicity – the art of maximizing the amount of work notdone – is essential, into account and stops further development.

Mini webinar Incremental versus iterative

[1] See YouTube for a very simple version of this figure: https://www.youtube.com/watch?v=20SdEYJEbrE&t=31s

[2] See my article with more than 70 agile frameworks or approaches: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November.

 

White paper: Exploring the delta in AgileSHIFT

Schermafdruk 2020-03-18 10.29.34Happy to see that my white paper Exploring the delta in AgileSHIFT is now live on the AXELOS content hub.

Enterprise agility is key. It is not just about implementing an agile way of working in your IT department but a transformation for your whole organization. You have to understand where the market is going, where your competitors are moving, where your customers want to be, and, as a result, where your organization needs to be. One technique to understand this is the concept of the delta. The difference between where the organization wants to be, expressed as ‘what great looks like’, and where it currently is.

This paper explores the concept of the delta, explaining how this is addressed in AgileSHIFT®, and providing practical recommendations and examples on the subject. It is aimed at senior managers, portfolio officers and transition directors who are overseeing fast-moving environments and are running the risk of competitors or disruptors taking over their organization’s market share.

AgileSHIFT helps prepare individuals and organizations for transformational shift by creating a culture of enterprise agility. This cultural change is not driven by simply adopting an agile framework, method or tool, but by understanding and distilling the ethos behind agile ways of working and leveraging them across the entire organization.

A key theme within AgileSHIFT is the delta and the importance to narrow your company’s delta. The delta is the difference between where an organization wants to be and where it currently is. This could be measured in terms of capability, performance, or value delivered. The larger the delta, the greater the vulnerability of the organization to competitors and disruptors. Unfortunately, the delta is not static, so it will grow again. Narrowing the delta will be an ongoing process and you must keep changing to manage the delta, otherwise competitors will be ahead of you and take it all.

In the article I explore what it means where you want to be. This is what you could call ‘great’ and this could relate to your products, services, technology, processes et cetera. I explain that this could be related to the technology. Can you expect a (digital) tech-shift in your company’s work (tech-supported, tech-enabled or tech-centric)? If the delta is large your company is at risk and vulnerable to other competitors who could destroy your own business. What would be the impact of disruptors or exponential organizations on your own business? Will you survive?

I make use of some scenario’s like a dentist practice and a Cyclecity bike shop to explain the concept of the delta and how you could narrow the delta by closing the existing gap. For the Cyclecity bike shop I use a business model canvas to explain the as-is and the to-be situations. I use the GDS/IPS’s 7 lenses of transformation (vision, design, plan, transformational leadership, collaboration, accountability and people) to give a first, but incomplete, impression of how the transformation programme to bridge the gap between the as-is and the to-be could be outlined.

I hope this white paper will be useful and feel free to give me your comments.

To download: AgileSHIFT_wp_Exploring-the-delta-in-AgileSHIFT

Are incremental and iterative the same phenomenon or not? (Part I)

webinarDuring training classes I often notice that students mix these words together. After reading this article I hope you understand the relationship between incremental and iterative development. I will start with a comparison of a waterfall and an agile approach by delivering a payment app. At the end you will find the corresponding mini webinar. In the second part of this article, I position waterfall and agile in an incremental versus iterative cross or matrix and shows what happens in the other two quadrants too (will be part of a next blog post).

The development of a payment app

Waterfall approach

If this app is developed according to a traditional waterfall approach, the following steps could be observed (see figure 1).

It all started with a project sponsor from the marketing department who was able to free up the necessary funds for this app. It was his assumption that the app will improve the retention figures and the inflow of new clients will grow. He visualized three high level function groups.

At a certain moment this project gets the approval to commence. A project manager is assigned, and a project team built. After many discussions and requirement gathering workshops there was an agreement to deliver a payment app with 250 features. All these features are recorded in an extensive and very detailed requirements document and signed by the project sponsor and customer representative (and some others).

In the next step the project team translates the requirements into a design for the app. The architect checks the design towards the design principles. He checks if all needed data attributes are available in the backend system too.

Dia3Figure 1: waterfall delivery of an app

We are now two months underway and the customer hasn’t seen anything working yet, only some progress reports. Probably some sort of ‘melon’ reporting[1] so they have no clue if the project is on track or not. It takes six months to develop the app and when that’s done the customer representative is asked to deliver some people who can help with a user acceptance test. During the test it becomes clear that several features are not working. The project team doesn’t understand why. It’s exactly what was described in the requirements document. Lots of discussions, rework, delays and customers who aren’t happy with the results. If we look at the final result, we can also notice that many of the developed requirements are not or rarely used[2] by the customer. It could even be worse. Suppose the development of the app took 1.5 year and another bank delivers a payment app when you are halfway. What would you do at that moment? Would you still have a viable business case to continue and finish your own app?

If you look at figure 1 it becomes clear that in case of a waterfall approach the scope and underlying quality criteria are fixed with a single delivery. All steps are performed once for the entire project and management control is focusing on cost and time. Value delivery to the customer only takes place after the deployment of the complete app.

Agile approach

If we develop the app in an agile way, we see the following pattern. The development team stated that they are able to deliver the first two features prioritized by the product owner (balance information and submit feedback) in the first iteration. The project team delivers every three weeks (sprint, iteration or timebox) an increment of the product. After the first deliveries or increments we see a customer who has confidence that the project will deliver. He/she already has a working app. He understands that not all features are there yet but what he has is working. Looking at the latest release and the provided features, he mentions a completely new feature. One that nobody had on his mind at the start of the project but a feature that can make his life as a customer much more productive. After every increment the customer feedback results in new features (not on the list) or adjustments of potential features and the product becomes more and more mature. Every time when the customer receives a new version you can see a happier customer.

Dia4Figure 2: Agile delivery of an app

If we look at figure 2, we see a steady flow of delivery within a fixed duration and using permanent agile teams (fixed costs). The scope and underlying quality criteria are flexible (dynamic) with frequent small deliveries (increments). All steps are performed repeatedly (iterative) to deliver a feature or user story until the required quality is reached. Management control is focusing on customer value delivery. Value delivery to the customer takes place after every deployment of an increment of the app.

Waterfall versus agile delivery results

If we take a closer look at the two products from both the waterfall as well as the agile approach, we see a product with 250 features and a not so happy customer and one with only 150 features and a very happy customer (see figure 3).

Dia5Figure 3: Waterfall versus agile delivery results

And if we even look in more details to the product delivered by the agile approach, we only see 100 features from the original list and 50 are new or adjusted features. This is in line with some important principles of the agile manifesto[3]:Simplicity – the art of maximizing the amount of work not done – is essential (only 150 features instead of 250 features) and Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage (50 new or adjusted features were delivered). And as a result, a very happy customer (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software)!

Mini webinar Waterfall versus agile delivery

[1] ‘Melon’ or better ‘watermelon’ reporting is a progress report with green indicator(s). In reality the green indicator is red inside.

[2] Standish Group research shows that 60% of the developed requirements are not or rarely used (https://www.standishgroup.com).

[3] https://agilemanifesto.org

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: 

Recensie Agile transformeren

9789024427604-480x600Bas van Lieshout, Hendrik-Jan van der Waal, Astrid Karsten en Rini van Solingen hebben met het boek Agile transformeren – een praktische aanpak voor het structureel versnellen en wendbaar maken van organisaties een reisgids geschreven die je kan gebruiken bij jouw eigen agile transformatiereis. En zoals ook bij een gewone reisgids, je pakt eruit wat voor jou bruikbaar is. In het boek vele leerervaringen onderbouwd met een veelheid aan geanonimiseerde cases waarvan ik er verschillende denk te herkennen.

Het boek is onderverdeeld in een drietal delen. Waarom agile transformeren, hoe voer je een agile transformatie uit en wat te veranderen en borgen in een agile transformatie.

QRC (Agile transformeren, 200312) v1.0Downloaden: QRC (Agile transformeren, 200312) v1.0

In het eerste korte deel waarom agile transformeren wordt ingegaan op de fundamentele versnelling door digitalisering die nu plaatsvindt in de wereld. Met als gevolg dat bedrijfsmodellen, mensen en het leiderschap moeten veranderen en empirisch werken als enige oplossing wordt aangedragen. Iedere organisatie zal getransformeerd moeten worden als gevolg van digitalisering, versnelling en sterk veranderende klantbehoeften. De transformatie zal organisatiebreed doorgevoerd worden om een agile mindset te bewerkstelligen. Een agile cultuur is gebaseerd op zingeving, vertrouwen, transparantie, experimenteren, zelforganisatie, eigenaarschap en continu verbeteren.

In deel B nemen de auteurs je mee hoe je een agile transformatie uit zou kunnen voeren, waarbij benadrukt wordt dat je vooral je gezonde verstand moet blijven gebruiken. Het letterlijk volgen van de stappen zal naar aller waarschijnlijkheid niet tot het gewenste resultaat leiden. Iedere organisatie en dus ook de transformatie is anders. Ter ondersteuning wordt een acht stappen model (vergelijk Kotter) toegelicht. De eerste drie stappen helpen de transformatievisie neer te zetten en uit te dragen en de stappen 4 tot en met 8  beschrijven de uitvoering van de transformatie.

  1. Scope: een heldere scope voor de transformatie is een randvoorwaarde voor executie van een transformatie
  2. Onderzoek: Stel vast wat het doel van het onderzoek is: 1) Eenduidig gedragen beeld opbouwen bij betrokkenen; 2) Meetpunt hebben om voortgang bij te houden en te rapporteren; 3) Eerste echte interventie om duidelijk te maken dat het serieus is; 4) Concrete actie en alignment krijgen
  3. Urgentie: Bij het helder maken van de urgentie moeten in ieder geval de volgende vragen beantwoord worden: Waarom wordt de verandering ingezet; welk probleem wordt opgelost; welke richting gaat het op en wat is de dringende noodzaak hiervan?
  4. Bouwschets: De bouwschets helpt bij het richting geven, inspireren, doorbreken van bestaande patronen en het creëren van draagvlak om te starten. Nb. In dit hoofdstuk een interessante paragraaf met redenen waarom je wel/niet gebruik gaat maken van componentteams (niet onafhankelijk)
  5. Veranderstrategie: Houd bij het bepalen van de veranderstrategie rekening met de bestaande cultuur, de externe urgentie en hoe diep je wilt veranderen. Maak daarbij een keuze voor een big bang, stapsgewijs of evolutionaire aanpak. Ook het werken met waves is een mogelijkheid en het betrekken van de ondernemingsraad wordt aanbevolen als bij de transformatie medewerkers geraakt worden
  6. Roadmap: Een transformatieroadmap is enerzijds een communicatiemiddel, biedt focus en activeert de organisatie en anderzijds dient het als startbewijs en maakt de voortgang inzichtelijk
  7. Korte iteraties: Iteratief werken creëert de gewoonte om regelmatig bij te sturen, draagt bij aan het vertrouwen en zorgt dat je een voorbeeld stelt.
  8. Meten: Maak een keuze voor de meest relevante keuze. Worden externe resultaten meetbaar en transparant of wordt de interne voortgang en impact van de transformatie meetbaat en transparant gemaakt. Hierbij wordt aanbevolen om te zorgen voor een balans tussen leading en lagging indicatoren en het creëren van aandacht.

In deel C wordt, in lijn met Kotter’s laatste stap, ingegaan op de borging van de agile transformatie. Deze borging wordt handen en voeten gegeven door zeven borgingsthema’s te beschrijven:

  1. Talentontwikkeling: Zorg voor agilty bij personeelszaken en zet de medewerker centraal. Betrek daarnaast personeelszaken bij het transformatieteam en die medewerkers die de gewenste mindset hebben. Stimuleer daarnaast de ontwikkeling van medewerkers, ga flexibel om met rollen en heb aandacht voor het welzijn van medewerkers maar durf ook afscheid te nemen van medewerkers
  2. Leiderschap: Leiderschap moet aansluiten op de bouwschets en maak het mogelijk dat teams autonoom kunnen optreden
  3. Strategische besturing: Denk hierbij aan de volgende praktijkmaatregelen: kwantificeer strategische doelstellingen, richt strategievalidatie in en accepteer dat onbekend is wat strategisch verstandig is. Betrek hierbij productowners en richt een kort cyclisch ritme in voor sturing en reorganiseer de bestaande governance
  4. Meten en afstemming: hierbij kunnen de volgende maatregelen gehanteerd worden: Kijk gezamenlijk terug en vooruit. Maak één productowner verantwoordelijk voor een gehele waardeketen. Maak zaken helemaal af zodat ze door een klant gebruikt kunnen worden. Richt een obeya-ruimte in en maak gebruik van OKR’s voor transparantie van doelen
  5. Financiën: Betrek financiële professionals actief bij agile teams. Help in de overgang van project- naar productfinanciering. Laat een verbeterteam de financiële processen verbeteren
  6. Compliance: Maak kwaliteit een teamverantwoordelijkheid en werk samen met compliance en vertaal afspraken naar compliance by design en de definition of done (DoD)
  7. Technologie: Stimuleer continu integreren en opleveren waarbij de kwaliteit gegarandeerd wordt door geautomatiseerd testen. Stimuleer daarnaast een wendbare architectuur en een date-gedreven werkwijze.

Conclusie: Een vlot leesbaar boek dat precies past in een heen en terug vliegreis naar Vilnius, Litouwen waar ik voor de IPMA Project Excellence assessor sessie moest zijn. Persoonlijk vind ik het eerste deel wat mager. Het is niet meer dan een kort inleidend hoofdstuk. Ik had meer onderwerpen verwacht zoals bijvoorbeeld het effect van disruptieve of exponentiele organisaties als redenen om te moeten transformeren. Neemt niet weg dat dit boek voor iedereen die nadenkt over of ondertussen bezig is met een agile transformatie veel nuttige voorbeelden en valkuilen uit praktijksituaties omvat. Het acht stappenplan biedt mooie handvatten en concrete te nemen acties. Als daarnaast ook gehoor gegeven wordt aan de borging in de structuur en cultuur van de organisatie wordt de kans op een succesvolle transformatie vergroot.

Bestellen:  Agile transformeren

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