Tag Archives: Agile

Recensie Het wiel van de product owner – out of the box

Het wiel van de product owner – out of the box – 40 practische en inspirerende kaarten is geschreven/gemaakt door Bas van Amersfoort en Henny van Silfhout. Met de woorden van de auteurs “Scrum-boeken en trainingen zijn meestal gericht op scrum masters, soms op ontwikkelaars, maar bijna nooit op product owners. Het wiel van de product owner moet dat hiaat invullen.” 

Meestal recenseer ik boeken maar deze keer zijn het kaarten. Ik ben benieuwd of de auteurs het genoemde ‘hiaat’ hiermee kunnen invullen. Het wiel van de product owner geeft een overzicht in vijf stappen waar je rol om draait en wat je wanneer doet:

  1. Inspireren met een visie
  2. Plannen met een roadmap
  3. Ordenen met een product backlog
  4. Garanderen met een definition of done
  5. Leren in een review.

40 mooi geplastificeerde kaarten voor de beginnende product owner. Kijkend naar de inhoud kunnen we er direct 6 apart leggen. Dat zijn lege kaarten waar je zelf aantekeningen op kan maken. Blijven er 34 over waarvan er 19 over Agile, Scrum en de rol van de product owner gaan. De laatste 15 gaan in op onderwerpen van het wiel van de product owner (visie, roadmap, product, definition, review). Naast de kaarten krijg je een folder met daarin een toelichting en een hele summiere beschrijving van de kaarten. 

Zitten we hierop te wachten? Een aantal kaarten zijn wel heel simpel. Ik mis kaarten over story mapping, het schrijven van stories, kleiner maken van stories, het beschrijven van acceptatiecriteria, et cetera. Voor een prijs van €37,50 had ik veel meer verwacht. Om te beginnen had ik de achterkant van de kaarten gebruikt om een toelichting bij de voorkant te zetten. Om de kaarten te kunnen gebruiken zal je eerst een boek of training over de product owner gelezen of gevolgd moeten hebben. Nu heb je slechts een aantal geplastificeerde powerpointslides waarbij het verhaal ontbreekt. In de lovende recensies in de folder kan ik mij dan ook niet in vinden.

Bestellen: Het wiel van de product owner: managementboek.nl

Mocht je toch meer willen weten over de rol van product owner zie dan:

Recensie Natuurlijk Agile

Met het boek Natuurlijk Agile – De verborgen wortels van wendbaarheid heeft Paul Takken een inspirerend boek geschreven dat ons aan het denken zet hoe wij omgaan met agile. En is een antwoord op de vraag waarom er zoveel agile transformaties mislukken. Agile heeft zich te veel aangepast aan zijn koude zakelijke omgeving en is als het ware bevroren. In zijn huidige vorm is agile vrij passief.

Agile heeft in zijn huidige vorm een groot gebrek aan empathisch vermogen. Agile is in de optiek van de schrijver nooit een doel op zichzelf. Het moet passen binnen de natuurlijke behoefte en de beleveniswereld van een organisatie. De vijf basiselementen, de Godai, in de Japanse boeddhistische filosofie zal je ook in je dagelijkse agile praktijk moeten herkennen en gebruiken zodat er meer balans en energie binnen je organisatie ontstaat:

  • aarde (chi): de basis van agile werken. Een goede en gedisciplineerde uitvoering van de oorspronkelijke agile practices, principes en waarden (stabiliteit)
  • water (sui): natuurlijk meebewegen met de organisatie (wendbaarheid)
  • vuur (ka): natuurlijk leiderschap (energie)
  • wind (fu): een andere wind laten waaien (veerkracht)
  • leegte (ku): leegte ervaren – slow down to speed up (intuïtie)

Voor het mislukken van agile transformaties worden de volgende redenen aangedragen:

  1. Agile organisaties staan zowel fysiek als mentaal steeds minder in verbinding met hun klanten en medewerkers
  2. Bij verdere doorontwikkeling van Agile zijn er verwarrende interpretatieverschillen ontstaan (wendbaarheid versus verhoogde waarde creatie)
  3. De methodische kant van Agile is dominant geworden ten koste van de achterliggende filosofie die zich richt op harmonie, verbinding en flow
  4. Niet alles is maakbaar. Wij plaatsen ons boven het ecosysteem, in plaats van er integraal deel van uit te willen maken.

In het boek worden zeven hardnekkige valkuilen besproken die verhinderen dat organisaties zich verder kunnen ontwikkelen met methodische Agile transformaties. Vervolgens komen de principes van natuurlijk Agile aan bod (de wortels van Agile): evolutie, ritme, diversiteit en sensitiviteit.

Conclusie: Natuurlijk Agile is een beknopt, vlot lezend en inspirerend boek. Natuurlijk agile gebaseerd op principes evolutie, ritme, diversiteit en sensitiviteit als antwoord op vele mislukte agile transformaties. Wat mij betreft vertalen we dit boek in een vijfde waarde binnen het Agile Manifesto: Maatschappelijk en ecologisch belang boven het belang van de organisatie. Een absolute aanrader.

Bestellen Natuurlijk Agile: managementboek.nlbol.com

Article The evolution of agile frameworks

Nice to see that the Finnish magazine PROJEKTI Maailma 2 2022 posted my article The evolution of agile frameworks. The article reflects the keynote speech during 3PMO-tapahtuma 8.6.2022

Review The Professional Agile Leader

The professional agile leader – The leader’s journey toward growing mature agile teams and organizations by Ron Eringa, Kurt Bittner and Laurens Bonnema provides a detailed understanding of the leader’s role in an agile transformation.

When talking about reasons why so many agile transformations fail, I often show a picture of two rhinos colliding, and saying that this is the reason why. Next, I add two text boxes over the rhinos with company culture and agile culture. I can now refer to this book if you want an in-depth explanation of this clash.

The book is divided in eight chapters. the first chapter zooms in on the situation where you see yourself as an organization being overtaken by competitors. You may be very efficient but too unwieldy to respond quickly to the many changes that come your way. One solution is to take over another company that is already much more agile. This is also the case in the book where Reliable Energy takes over Energy Bridge and we follow the CEO who wants to make her organization more agile.

The second chapter shows what it means to form empowering cross-functional teams who discovered their purpose and the role of the leader. Key is that the teams must form themselves and that this takes time.

In the third chapter the emphasis is on the impact. Forget output but focus on the impact by framing goals in terms of customer outcomes instead of things that are produces. From plan-driven goals to goal-driven planning (tactical – intermediate – strategic goals).

Chapter four shows how teams and their leaders are changing by becoming more feedback driven. This is all about decision latency, levels of delegation, decentralized decision-making, and intrinsic motivation.

In chapter five we see the issues leaders are facing when they are halfway their agile transformation. This refers back to the clash between the rhinos at the start of this review. The original way of working with checks and balances versus the agile mind mindset and what that means to the people involved. Self-managing teams require leaders with a catalytic leadership style (collective focus: sharing, enabling, diversity, acceptance and supportive).

Chapter six shows that in an agile organization less and less hierarchical leaders are needed but all the more agile leaders. Where leadership should be seen as an activity and not a role. How to grow new leaders, how to grow mature teams and to escape the silos by breaking them down.

In chapter seven the authors explain that Kotter’s dual operating system cannot be used for ever. At a certain point you must decide to fully go for the agile way otherwise you will fall back to the old ways of working. I am not sure if this is what Kotter has in mind with his dual operating system.

The final chapter puts the agile culture in the spotlights. The social behavior and norms that people in the organization exhibit, including their beliefs and habits. Without this agile culture your agile transformation will fail and be aware this transformation will never end.

Conclusion

a compact and easy to read book that explains the role of a leader in an agile transformation in a clear, straightforward, and practical way. the case used of a merger of two companies as a common thread makes very clear the issues and friction a leader faces in an agile transformation.

I missed the agile leader’s role in sharing knowledge and lessons learnt by setting up communities of practice (CoPs), chapters, guilds et cetera. The issues and what to do about them when multiple teams are necessary to work on a single product are presented very simplistically but this is probably beyond the scope of this book.

In my opinion an absolute must read if you are in the middle of or want to start an agile transformation.

To order: The Professional Agile Leader: managementboek.nlbol.com

Recensie Projectmanagement en agile in de praktijk

Ed Schouten heeft met het boek  Projectmanagement en agile in de praktijk – Het beste van twee werelden, het zoveelste boek over projectmanagement en agile geschreven. Te weinig vernieuwend wat mij betreft.

Het boek bestaat uit vier, eigenlijk vijf delen. Eerst wordt de wereld van projecten verkend en worden de tien meest bekende faalfactoren van projecten besproken. Daarna komen de vier delen aan bod. 

Het eerste deel beschrijft het scannen, focussen en vormen om te komen tot een effectieve aanpak waarmee je het project opzet, uitvoert en afrondt. 

Deel II beschrijft de meer traditionele projectmanagementaanpak waarbij vooral gebruik gemaakt wordt van PRINCE2 en de fasering van het projectmodel van de ICB4 (projectvoorbereidingsfase, projectdefinitiefase, projectuitvoering en projectafsluiting).

Het derde deel beschrijft de agile aanpak in zijn algemeenheid en meer in bijzonder een aantal agile raamwerken zoals Scrum, LeSS, Nexus, spotify-model, SAFe, AgilePM en PRINCE2 Agile (Nb. Dank voor de verwijzing naar mijn eigen boek Scaling Agile in organisaties waarin ik onder andere deze methoden uitgebreid beschrijf).

In dit deel ook een paar pagina’s over de best of both worlds. Gegeven de ondertitel van het boek had ik hier een volledig deel over verwacht en dat had het boek onderscheidend kunnen maken.

Het laatste deel gaat over sociale vaardigheden voor projecten zoals communiceren, presenteren, overleggen en beslissen, leidinggeven en motiveren, samenwerken in een topteam, omgaan met tegengestelde belangen en het effectief omgaan met je tijd. Superbelangrijk als je een goed resultaat wilt neerzetten maar ook hierover is al zoveel geschreven.

Kortom te weinig vernieuwend, een gemiste kans om het beste van twee werelden handen en voeten te geven. Daarnaast heb ik een aantal keren mijn wenkbrauwen gefronst. Klopt het wel wat er staat. Een paar voorbeelden. Er worden een aantal faseringsmodellen gegeven waarbij de kwaliteit van de plaatjes ontoereikend is. Het figuur parallelle fasering is het verkeerde plaatje (kopie van lineaire fasering). Het plaatje versiefasering en de tekst sluiten niet op elkaar aan en het timeboxing plaatje suggereert dat je in een timebox eerst alles ontwerpt, vervolgens realiseert en uiteindelijk test. In de praktijk lever je op deze manier niets op. Het iteratieve van kleine stukjes ontwerpen, realiseren en testen ontbreekt in dit plaatje. Ook staat een aantal keer in het boek dat iedere sprint een Minimum Viable Product (MVP) oplevert. Dit is onjuist! 

Bestellen Projectmanagement en agile in de praktijk:  Managementboek.nlbol.com

Review Agile Portfolio Management

There are not that many books on agile portfolio management, so I am curious what the book Agile Portfolio Management – A guide to the methodology and its successful implementation “knowledge that sets you apart” written by Klaus Nielsen, offers.

The book is divided into nine chapters, starting with project portfolio management, and ending with case studies on agile portfolio management. In between chapters explaining agility at scale, agile portfolio management, differences between project portfolio management and agile portfolio management, hybrid portfolio management and implementing and tailoring agile portfolio management.

Every chapter starts with the same overview figure. It shows 6 circles representing 6 topics where one or two circles are highlighted. I have no clue what the author wants to express. The first two topics/circles are the first two chapters. The third chapter is the fifth circle. The fourth chapter is the fifth topic/circle. Chapter 6 refers to the third topic/circle, chapter 8 Tailoring agile portfolio management refers to topic/circle 4 Tailoring portfolio management and topic/circle 5 Agile Portfolio management. 

The first chapter Project Portfolio Management explains in detail the financial approach within traditional project portfolio management. Based on PMI’s Standard for Portfolio Management several financial models like PV, NPV, FV, ROI, IRR, PP, DCF, BCF, PI are explained as well as the continuous stages as initiation, planning, execution, optimization and monitoring and control. Set-up of the chapter is somewhat difficult to follow. All the information can be found in 28 sub paragraphs of the last paragraph 1.7. Explanation of a specific financial model or portfolio governance or stakeholder engagement are all separate sub-paragraphs. I miss structure.

The next chapter The reality of Agility@Scale is more a chapter on lean thinking and principles. Important for agile portfolio management but looking at the title I was expecting something different. In this chapter a brief explanation of the Stacey Matrix and the Cynefin Framework, lean thinking and lean portfolio management (using the theories of the Toyota way, Womach, Larman and Vodde, Reinertsen, Poppendiecks, …), continuous planning, and innovation.

Chapter 3 Agile Portfolio Management starts with an explanation of the Agile Manifesto and underlaying principles. The twelve principles are expanded including (portfolio) practices. 

In many paragraphs a table has been used showing Portfolio Life-Cycle Stages (initiation, planning, executing, optimizing, monitoring and controlling), Portfolio Kanban (funnel, review/analyzing, portfolio backlog, implementation, done), Projectized and Recurring. There is no reference in the text or explanation. This table comes back, in exact the same form, multiple times. I would say that only table 3.9 The Portfolio Kanban High-level Overview makes sense. In total 20 times the same table except the title of the table in the field Projectized or Recurring. Even the title is sometimes wrong (same as the previous table). I have no clue and what this says about the quality of the book?

Some paragraphs, e.g., stakeholder analysis is discussed in too much detail (this is not different from PPM stakeholder analysis). Regarding risk management I can make the same remark, there is only a small sub-paragraph regarding a risk burndown chart and risk-based spikes. What I am missing are the real agile portfolio risks. Portfolio risk management is more than the sum of initiative or project related risks. Other topics which are typically Agile portfolio management e.g., portfolio value, portfolio metrics and reporting are lacking details, and the benefits of agile portfolio management is not explained. I have my doubts if a tool-driven portfolio reporting approach is an indication for a medium to high agile maturity. Unclear why the paragraph Exploring EDGE is positioned here, because in the next chapter agile portfolio management frameworks are explained.

Chapter 4 covers several (agile) portfolio management frameworks like SAFe, LeSS, AgilePfM, Nexus, DA (notice that DAD only covers the delivery life cycles), Scrum, XSCALE, Enterprise Scrum, RAGE and the Spotify model. The author mentioned that the latest version of SAFe is 5.0. It’s 5.1 but that is not what bothers me. The description of SAFe talks about the value-stream level (after version 4, it is called large solution). There are now three levels: portfolio, large solution and essential and not team, programme, value stream and portfolio. I would expect that the portfolio level was discussed in more detail, e.g., the portfolio Kanban, portfolio canvas and participatory budgeting. Table 4.3 Levels of SAFe shows the Conformity Rating for LeSS. 5 pages further, we can find table 4.4 Conformity Ratings for LeSS which shows the SAFe key terms! 

To refer to LeSS Huge for the agile portfolio aspects is not correct in my opinion. LeSS Huge is there if we need more than 8-10 teams to develop and maintain one product. Finally, the Spotify Model is explained. A pity the author didn’t discuss the Spotify Rhythm model with company beliefs, company, functional and market bets boards which is more related to agile portfolio management.

Chapter 5 compares Project Portfolio Management and Agile Portfolio Management. In chapter 1 it is stated that MoP is long overdue and the PMI’s Standard for Portfolio Management lifecycle is used to structure chapter 1. In chapter 5, it is stated that MoP is one of the best Project Portfolio Management standards and MoP is used to build comparison tables with Agile Portfolio Management (high level, key activities, roles, and documentation). Why no consistency throughout the book? I missed a paragraph explaining the Obeya room concept as an agile portfolio management artifact to replace the portfolio dashboard. 

I don’t believe that you can use the Stacey matrix, Cynefin model or the PRINCE2 Agile Agilometer to choose between project portfolio management or agile portfolio management. This only works if all your projects are the same (e.g., simple) and I guess you will have simple as well as complicated or complex projects in your portfolio.

The next chapter talks about hybrid portfolio management. Too short if you ask me. For me hybrid portfolio management is something you need when you have to select, prioritize and allocate initiatives to permanent agile teams responsible for the development and maintenance of specific products and services and/or to one-off temporary projects, to deliver your portfolio’s objectives. Resource management is two-fold. Individual resource capacity management for the temporary projects and up and down scaling of permanent agile teams. Et cetera. The author combines project portfolio management with agile portfolio management resulting in 6 different flavors: standard PPM stage-gate in combination with agile ways of working between the gates, with agile teams (each team is handled as a project), with projects using temporary and agile teams, with an agile framework or agile portfolio management with plan-based projects or with a combination of projects and agile teams.

Chapter 7 focusses on the implementation of agile portfolio management by describing the top 10 challenges and suggested actions for implementing agile portfolio management:

  • Defining large-scale agile framework concepts and terms
  • Comparing and contrasting large-scale agile frameworks
  • Readiness and appetite for large-scale agile frameworks
  • Balancing organizational structure and large-scale agile frameworks
  • Top-down versus bottom-up implementation of large-scale agile frameworks
  • Over-emphasis on 100% framework adherence over value
  • Lack of evidence-based use of large-scale agile frameworks
  • Maintaining developer autonomy in large-scale agile frameworks
  • Misalignment between customer processes and large-scale agile frameworks
  • Ensure people and process issues do not steal the show.

How to and the importance of tailoring agile portfolio management is the next chapter. The intro, before paragraph 8.1, is eight pages long, without empty or white lines! A bit of tailoring could make it more readable. Is the author now talking about tailoring the agile portfolio (selection or adjustment of initiatives) or tailoring the agile portfolio framework itself? What makes an agile portfolio different from a portfolio? Next a three-step tailoring process is discussed (initially tailoring based on the organization, tailoring based upon the content of the actual portfolio, and continuous tailoring of the portfolio).

The last chapter shows nine (brief) case studies on some degree of agile portfolio management. 

Too much traditional PPM theory, instead of agile portfolio management theory. And the case studies offer not enough practical aspects. Sometimes I review books and it’s clear that these books are self-published. This book with unbalanced chapters and paragraphs, inconsistency, the issues with the figures, blurred figures, misspelled names, typos, and wrong numbers, gives me the same impression but it isn’t. I would have expected more from the author’s publisher to improve the quality. Sorry to say, but I can’t recommend this book.

To order Agile Portfolio Management: bol.com

Review Better Agile

The book Better Agile – How every software firm can spend less time firefighting and have more fun building great software by David Daly highlights his experiences to make agile work. It offers Scrum and Kanban mistakes to avoid and three agile secrets to continuously improve your agility.

The book can be divided in two parts. The first part elaborates on the author’s three agile secrets: how to optimize for flow, how to get the right people doing the right things and the impact of the right feedback loops on the product as well as the team effectiveness. The second part gives 10-minute overviews and mistakes to avoid of Scrum and Kanban and how to choose between Scrum and Kanban. Maybe it was better to reverse the order and start with second part because that would be more in line how organizations will start with their agile journey.

Secret #1: Optimize for flow

In case people are overloaded, are multitasking to extreme levels, are too busy, have changes blocked, are spending more time on fixing then implementing new features, you must optimize for flow. To increase flow efficiency (is touch time divided by lead time) can be done by:

  • Reduce batch sizes: reduces overall lead time (or elapsed time is touch time + wait time), especially when large batches occur before a continuous process
  • Reduce overall lead time 
  • Use the ToC to identify and alleviate bottlenecks by increasing focus, support and/or capacity
  • Understand common sources of blockers on your team and find ways to reduce the delay they cause
  • Shorten feedback cycles to reduce the effort spent on rework.

To support this secret and the other secrets several coaching questions are mentioned as well as further reading.

Secret #2: Get the right people doing the right things

When people are not focused on the most important work or frustrated with always working on the same kind of task or technology or when there are not enough people with the right skills or there is a lack of knowledge sharing between team members you benefit from getting the right people doing the right things.

It will help when you:

  • Capture all requests for work in a single backlog (yes, but I would say a single ‘short’ backlog. Saying ‘no’ in a substantiated way is a key competence too).
  • Do just enough prioritisation of your backlog so the team knows what is most important to work on next
  • Make sure how work is added to the backlog and how it is prioritised is transparent and visible to all stakeholders
  • Use guided self-selection to allocate work
  • Allocate work to avoid key-person dependencies: the most experienced people on the team should spend much of their time coaching and supporting others.

Secret #3: Shorten feedback loops

Are mistakes made more than once, do changes not always deliver the intended benefits, does it take too long to diagnose and fix problems, it will help to shorten feedback loops.

  • Feedback about the product:
    • Software builds
    • Software testing (is it bug free)
    • Customers
    • End-users
  • Feedback about how effectively the team is working:
    • Analysis of key metrics (elapsed lead time, frequency of deployments, change failure rate, time to restore after failure)
    • Regular opportunities to reflect on their performance and proposed improvements
    • Information radiators (walls, whiteboards, screens, bells, et cetera).

Scrum mistakes to avoid

After a 10-minute overview of Scrum, the following 5 mistakes are explained:

  1. Water-Scrum-Fall
  2. Multi-sprint stories
  3. Ineffective Product owner
  4. Not reaching a potentially shippable state in every sprint
  5. Ignoring required technical practices 

Kanban mistakes to avoid

After a 10-minute overview of Kanban including a short explanation of Scrumban (using Kanban to support your Scrum way of working), the following 5 mistakes are explained:

  1. Task-board only
  2. Not limiting WIP
  3. Not starting with what you do now
  4. No feedback loops
  5. Mapping who does the work rather than the value-adding steps

Scrum, Kanban or?

The chapter How to choose between Scrum and Kanban is according to the author very short and rather obvious. Too short in my opinion if you want to use this to choose between frameworks like SAFe, LeSS or others.

The book ends with a 5-minute agility self-assessment to understand where to start to become more agile and a recap of the coaching questions to support the three agile secrets.

Conclusion.

Better Agile is a practical, easy to understand guide to continuously improve your agility. It gives insights in some common mistakes in Scrum and Kanban. It shows how to optimize for flow, how to get the right people doing the right things and the impact of the right feedback loops on the product as well as the team effectiveness. The 55 coaching questions and the 5-minute agility self-assessment are helpful. What I miss is a fourth secret regarding the agile mindset and culture. The organization’s culture is often at odds with the agile culture and that’s a key reason why agility isn’t improving. Finally, I have my doubts if, after reading this book, you have the skills to make an informed choice about any method, including frameworks for scaling agile. See e.g., my articles The evolution of agile frameworks and The bird’s eye view on the agile forest.

To order Better Agile: Amazon.com

Recensie De moderne digitale provincie

In het boek De moderne digitale provincie – Succesvol organiseren en digitaliseren neemt Jaring Hiemstra je mee in de eerste stappen die provincies zetten op het terrein van digitale transformatie zodat zij in staat zijn om betere beslissingen te nemen, de uitvoering efficiënter te maken en om op grote schaal samen te werken met burgers en andere overheden.

Dit boek is gebaseerd op een verkennend onderzoek naar digitalisering in de twaalf provincies, gecombineerd met eigen ervaringen van de auteur en kennis uit wetenschappelijk onderzoek. Het bestaat uit vijftien korte hoofdstukken verdeeld over 5 delen waarin stap voor stap het belang van digitalisering en wat daarvoor nodig wordt steeds duidelijk wordt.

In het eerste deel wordt ingegaan op de toegevoegde waarde van de provincie en wat de invloed van digitalisering daarop kan zijn. Hierbij staat digitalisering niet op zichzelf. Digitalisering zal leiden tot veranderingen van de primaire processen in de publieke organisaties. Er worden tien mechanismen beschreven die de primaire processen veranderen: 

  • van mens naar machine
  • van aannames naar weten
  • van lang cyclisch evalueren naar kort cyclisch leren
  • van statisch naar dynamisch werken
  • van generieke naar specifieke actie
  • van reageren naar proactief werken
  • van geoptimaliseerde punten naar optimalisatie netwerk
  • van eenvoudige verbanden naar sturen op complexe interacties
  • van uitwisselen naar platform
  • van overheid naar gedeelde community

Tenslotte wordt ingegaan op 70 jaar overheidsmanagement en worden een viertal belangrijke aandachtspunten voor de Nederlandse publieke sector gegeven.

Het tweede deel definieert wat provincies moeten doen. Vier handelingsperspectieven passeren de revue:

  • Anticiperen op effecten digitalisering
  • Reguleren van digitale innovaties
  • Innoveren met digitale mogelijkheden
  • Stimuleren van digitale transformatie

Daarnaast worden drie niveaus in digitale innovatie beschreven: optimaliseren (0-1 jaar), innoveren (1-2 jaar) en transformeren (2-4 jaar). Ook het proces van visievorming naar realisatie zal door digitalisering veranderen. De essentie is dat digitalisering ertoe leidt dat overheden transformeren van een op documenten gebaseerde sturingswijze naar een meer data gedreven wijze van besturen.

Het derde deel beschrijft de zes bouwblokken van de moderne digitale provincie:

  • Strategie – stabiliteit en adaptiviteit
  • Samenwerken – ecosystemen en platformen
  • Structuur – zelforganisatie en dienend leiderschap
  • Sturing – data en dialoog
  • Systemen – flexibiliteit en digitale assets
  • Professionals – vakmanschap 

Verder wordt ingegaan op de digitale competenties van de publieke leider, een viertal digitale rollen (data scientist, data engineer, GIS-expert en analytics translator) en het innovatieproces van een moderne digitale provincie (verkenning & prioritering, solution design, proof of concept, pilot, implementatie en beheer & doorontwikkeling).

Digitalisering biedt kansen, maar het kan ook de vertrouwensrelatie beschadigen. In het vierde deel worden een aantal voorwaarden beschreven waaraan een digitale provincie moet voldoen zoals het hebben van een wendbare IT- en datahuishouding (data eenmalig vastleggen, data integreren, data gebruiken, en data presenteren), een nieuwe bestuursstijl (van planmatig naar adaptief) en betrokken burgers.

Het laatste deel laat zien dat provincies een start gemaakt hebben met de digitale transformatie maar dat er een meer samenhangende benadering nodig is om digitaliseringspotentieel te benutten. De volgende stap is dat provincies digitalisering gericht gaan inzetten om de ruimtelijk-economische informatiepositie te versterken, om efficiency-voordelen in de uitvoering te realiseren en dat zij digitalisering gaan benutten om de samenwerking met burgers en andere overheden op grote schaal te vergroten.

Conclusie

Een vlot en toegankelijk geschreven boek met vele referenties over het belang van en de weg naar een digitale provincie. Het biedt inzicht in de huidige positie en het weer toenemende belang van provincies. Het beschrijft vier handelingsperspectieven (anticiperen, reguleren, innoveren en stimuleren) en drie niveaus van innovatie. Daarnaast geeft het boek een aantal bouwblokken van de moderne digitale provincie en wat het betekent voor publiek leiderschap. Ook laat het een aantal randvoorwaarden zien zoals vertrouwen en empathie, een moderne IT- en datahuishouding en een nieuwe bestuursstijl waarbij de burgers betrokken worden. Tenslotte worden een aantal uitdagingen geschetst en hoe er samenhang in verandering kan worden gecreëerd.  

Ik kon mij echter niet vinden in de positionering van de provincies in het kwadrant digitaal volwassen provincies. Het boek laat juist zien dat er nog vele stappen bewust genomen moeten worden om digitaal volwassen te worden. Maar 11 van de 12 provincies zitten in al dit kwadrant terwijl ik verwacht zou hebben dat de meeste provincies zich in kwadrant digitaal beginnende provincies of in de andere kwadranten digitale projecten provincies of digitaal behoudende provincies zouden zitten. Speelt hier wellicht het optimism bias van de geënquêteerden een rol? Daarnaast zouden er volgens de voetnoot maar 11 provincies zijn geplot, ik tel er 12?

Bestellen De moderne digitale provincie: Managementboek.nl

Recensie Sturen op resultaat

Het boek Sturen op resultaat – Hoe je samen werkt aan de grootste ambities! geschreven door Anton Vanhoucke en Denise visser is een praktijkboek waarin zelfsturing, doelen stellen en denken in experimenten centraal staan. Het geeft handvatten m.b.t. zelfsturing, het gebruik van KPI’s, OKR’s en het door de auteurs voorgestelde OPME’s en biedt inzicht in het hanteren van verschillende experimenten.

Het boek bestaat uit drie delen zelfsturing met inspirerende data, focus op toegevoegde waarde en het bouwen, meten en leren van experimenten. In lijn met het triple loop learning model waarbij single loop learning staat voor beter doelen te halen (experimenten), double loop learning staat voor beter doelen te halen en doelen te stellen (toegevoegde waarde) en triple loop learning staat voor leren om beter doelen te halen en doelen te stellen, waarbij je het proces van leren versnelt (zelfsturing).

Aangestuurd, zelfsturend, zelforganiserend of zelfbesturend?

In het eerste deel wordt duidelijk hoe je het lerend vermogen van een organisatie kan vergroten. Centraal staat hierbij de vraag hoe motiveer je mensen om continu te verbeteren op basis van waarneembare feiten. Denk hierbij aan de rolverdeling tussen teams en leidinggevenden, transparantie, zelfsturing en veiligheid, een cultuur van leren en zelfsturing ondersteunen vanuit leiderschap. Om naar de zelfstandigheid van teams te kijken wordt gebruik gemaakt van het groeimodel van Hackman:

  • Aangestuurd: zonder supervisie uitvoeren van opgelegde planning.
  • Zelfsturend: eigen planning opstellen en bijsturen. Eigen processen verbeteren.
  • Zelforganiserend: rollen en processen aanpassen aan de omstandigheden.
  • Zelfbesturend: eigen doelen bepalen, in lijn met de organisatie.

KPI’s, OKR’s of OPME’s?

Het tweede deel zet doelen stellen centraal. Er wordt uitgebreid stil gestaan bij het focus aanbrengen middels:

  • KPI’s: Key Performance Indicators (geschikt voor het beoordelen van een machine of proces, minder geschikt voor het managen van mensen).
  • OKR’s: Objective & Key Results (geschikt voor het managen van een team).
  • OPME’s: Objectives, Progress Metrics & Estimates. Een door de auteurs ontwikkeld raamwerk voor doelstellingen. Basiseigenschappen van objectives, progress metrics en estimates worden toegelicht. Daarnaast wordt het CRAFT proces voor het ontwikkelen van zowel OKR’s als OPME’s (create, refine, align, finalize en transmit). Ook wordt ingegaan op OPME’s als dashboard voor zelfsturing en de OPME roadmap.

Experimenten

Het derde deel beschrijft wat je kunt met experimenten, hoe je een experiment kan ontwerpen waarbij het hypothesecanvas gebruikt kan worden. Ook wordt het a/b/testen toegelicht. Daarnaast wordt ingegaan op het belang van een opeenvolging van experimenteren, een experimenteercultuur en het combineren van bouwen en testen (build, measure & learn, design thinking ,design sprint).

Metrics en canvassen

In de bijlage verschillende voorbeelden van metrics mbt productiviteit, klantenbinding, merkbekendheid, wenselijkheid, maakbaarheid en levensvsatbarheid. Daarnaast de canvassen die in dit boek gebruikt worden (5 strategische stappen-canvas, OPME canvas, OPME roadmap, bouw je eigen Craft-canvas en experimenteer A5 -kaart). De canvassen zijn ook te downloaden op https://sturen-op-resultaat.nl.

Conclusie

Een vlot geschreven praktijkboek waarin zelfsturing, doelen stellen en denken in experimenten centraal staan. Het geeft handvatten m.b.t. zelfsturing, het gebruik van KPI’s, OKR’s en het door de auteurs voorgestelde praktisch toepasbare OPME raamwerk, en biedt inzicht in het ontwerpen en uitvoeren van verschillende soorten experimenten. Het boek wisselt theorie af met verhelderende casestudies, waarbij een aantal praktische canvassen worden aangeboden. Een aanrader.

Bestellen Sturen op resultaat: managementboek.nlbol.com

Modified Agile for Hardware Development (MAHD) Framework

My ‘bird’s eye view on the agile forest’ gives a fairly complete picture of the different agile frameworks. I only adapt it when I come across really deviant frameworks. This time it’s MAHD.

Modified Agile for Hardware Development (MAHD) Framework was developed by Gary Hinkle and Dorian Simpson. It is similar to agile for software methods, but with critical differences. The MAHD Framework uses the principles of Agile to develop physical products in less time, with reduced risk and with higher customer satisfaction. Many companies have attempted applying Agile for SW methods directly to physical products with mixed results. Teams often struggle since current Agile steps, techniques and even language were not optimized for hardware development. A modified Agile approach can leverage the power of Agile, while addressing the unique needs of hardware development. 

More detailed information can be found at: www.agileforhardware.org

I classified MAHD as product-targeted. For a copy the latest version of the article see: Bird’s eye view on the agile forest