Recensie VeranderCanvas

9789462762084-480x600Ruim 10 jaar terug creëerde ik mijn eerste one-pager om een project te beschrijven en deze one-pager vormde de basis voor mijn boek De praktische PRINCE2. Canvassen bestonden toen nog niet maar mijn one-pager was het wel. Ondertussen hebben vele canvassen het licht gezien. Neem bijvoorbeeld het business model canvas, canvas omgevingsmanagement, portfolio canvas, programma canvas, project canvas, het wendbaarheidscanvas en vele anderen.

Dit boek voegt daar wederom een canvas aan toe. VeranderCanvas – Een praktisch boek voor iedereen die doordacht wil werken aan organisatieverandering is geschreven door Anne-Bregje Huijsmans, Lisa van Rossum, Sjoerd Segijn, Kim Grinwis en Wouter ten Have. Het VeranderCanvas staat centraal in dit boek en helpt je om, op een gestructureerde wijze, scherp te krijgen of een organisatieverandering wenselijk of noodzakelijk is, wat er gaat veranderen en hoe je dit het best kunt realiseren.

Het VeranderCanvas helpt je om in vier stappen om de verandering doordacht uit te voeren.

  1. Veranderidee: Waarom wil je veranderen en wat houdt de verandering in?
  2. Context: Wat zijn de externe ontwikkelingen (bv aan de hand van het DEPEST-model), wat speelt er momenteel binnen de organisatie dat invloed kan hebben op de verandering en wat zijn de belangrijkste stakeholders waar rekening mee gehouden moet worden zodat voldoende draagvlak ontstaat?
  3. Diagnose: De mate waarin de organisatie in staat is om de verandering te realiseren. Hierbij wordt gebruik gemaakt van het Veranderkrachtmodel.
  4. Aan de slag: De aanpak om de organisatieverandering succesvol te realiseren.

VerandercanvasHet Veranderkrachtmodel is de kern van het VeranderCanvas en bestaat uit vijf factoren die je in samenhang moet beoordelen resulterend in een totaalbeeld van de diagnose, om daarmee de verandering succesvol te kunnen realiseren. Per factor maak je zichtbaar wat er (al) goed gaat en wat er (nog) niet goed gaat, zodat daar gericht aan gewerkt kan worden. De factoren in het Veranderkrachtmodel zijn:

  • Rationale: Het grote verhaal van de verandering (is het waarom goed onderbouwd en aansprekend? Is helder wat moet veranderen om het uiteindelijke doel te realiseren?)
  • Effect: het kleine verhaal van de verandering (is duidelijk welke concrete resultaten worden opgeleverd? Wordt rekening gehouden met de consequenties voor betrokkenen en worden de resultaten in de gaten gehouden?)
  • Focus: Kaders om gewenst gedrag en samenwerking te stimuleren (dragen de strategische keuzes en de huidige inrichting van de organisatie bij aan de realisatie van de verandering? Passen de organisatiewaarden bij de verandering?)
  • Energie: Het vermogen om de verandering te realiseren (zijn leidinggevenden in staat de medewerkers te begeleiden? Is er draagvlak? Zijn er voldoende middelen?)
  • Verbinding: De organisatieverandering inrichten en besturen (Is er een plan en is het afgestemd met andere ontwikkelingen? Wordt er tijdig en juist gecommuniceerd?).

Totaalbeeld Diagnose: Beschikken we over voldoende veranderkracht om de verandering te realiseren? De diagnose is gebaseerd op onderzoek naar alle vijf factoren en kan op basis van de verschillende factoren rationale, effect, focus, energie en verbinding respectievelijk (on)begrijpelijk, (on)doordacht, (on)gericht, (on)vermogen en (on)gestuurd zijn of een combinatie hiervan.

Behalve een uitleg van de verschillende stappen bieden de auteurs voorbeelden van werkvormen waarmee je bij de verschillende factoren aan de slag kan gaan en verschillende manieren waarop je het VeranderCanvas kan toepassen. Uiteraard komen een aantal ingevulde praktijkvoorbeelden van het VeranderCanvas aan bod zoals een fusie van twee onderzoeksafdelingen van twee ziekenhuizen, een overheidsinstantie en zelf organiserende teams in een hogeschool.

Het boek sluit af met een toelichting op Evidence-Based Change Management waarin besluitvorming gebaseerd wordt op expertise en ervaring van jezelf en anderen, de waarden en belangen van stakeholders, de data en kenmerken van de organisatie en wetenschappelijke onderzoeksresultaten.

Uiteraard is een ingevuld VeranderCanvas pas de eerste stap op weg naar verandering en zal een project of programma je verder kunnen helpen.

Conclusie: een mooie manier om grip te krijgen op je verandering en een handig hulpmiddel om de verandering te communiceren.

Bestellen: VeranderCanvas

Advertisements

Recensie: 50 tinten nee – effectief stakeholdermanagement voor de product owner

9789024427079-480x600Ik vraag wel eens een product owner om zijn/haar product backlog te laten zien. Als deze backlog erg groot is, is dat voor mij een indicatie dat de product owner wellicht nog moet groeien in vak-volwassenheid of dat hij/zij te weinig mandaat heeft. In workshops of presentaties vraag ik wel eens naar de belangrijkste competentie van een product owner. Wat mij betreft NEE zeggen of wil je als product owner te boek staan als ‘shopping list manager’, order taker, of backlog secretary? Kortom, ik ben benieuwd naar dit boek 50 tinten nee – effectief stakeholdermanagement voor de product owner geschreven door Robbin Schuurman en Willem Vermaak.

Het boek begint met het neerzetten van de product owner rol en typen product owners (scribe, proxy, business representative, sponsor en entrepreneur). Vervolgens wordt ingegaan op een belangrijke competentie van de product owner namelijk stakeholdermanagement. Uit het boek Stakeholdermanagement – Start met wie worden 33 typen stakeholders gehaald waarvan velen ook voor de product owner interessant zijn. Als product owner helpt het om een stakeholder map te maken waarin het belang van (laag – hoog) en invloed door (laag – hoog) de stakeholders geplot kan worden om daarmee te bepalen hoeveel tijd je in de relatie moet stoppen (monitoren, informeren, tevreden houden en actief samenwerken).

Een volgend hoofdstuk gaat in op het effectief nee zeggen en waarom nee zeggen zo moeilijk is. Wat gebeurt er als je nee zegt, hoe kijkt men dan tegen je aan? Verder bespreken de auteurs vier patronen die het lastig maken om nee te zeggen zoals angst voor conflicten, angst voor teleurstelling bij anderen, angst voor hiërarchie en nee zeggen betekent ‘het patroon’ doorbreken.

QRC 50 tinten neeDownloaden: QRC 50 tinten nee

Het boek beschrijft een eenvoudig vijf stappenmodel om op een effectieve wijze nee te zeggen (zie ook bijgaande quick reference card):

  1. Wie – Tegen wie ga je nee zeggen?
  2. Wat – Wat is de vraag van de stakeholder?
  3. Intentie – Wat is jouw intentie?
  4. Zeg nee – Formuleer de juiste nee – wat je zegt
  5. Wederhoor – Heeft de ander het begrepen? En wat is de reactie van de ander?

De 50 tinten nee zijn in negen categorieën verdeeld:

  1. De duidelijke nee
  2. De vanuit de klant/gebruiker geredeneerde nee
  3. De vanuit waarde geredeneerde nee
  4. De vanuit budget geredeneerde nee
  5. De vanuit timing geredeneerde nee
  6. De vanuit de impact op de omgeving geredeneerde nee
  7. De vanuit kwaliteit geredeneerde nee
  8. De nee als alle andere nee’s niet (meer) werken
  9. Bonus: De nee om je mandaat mee te vergroten

Iedere categorie wordt toegelicht en er wordt een link gelegd met het type stakeholders in de stakeholder map. Niet ieder kwadrant met stakeholders in de stakeholdermap leent zich voor alle tinten in die categorie. De eerste zeven categorieën zijn onderverdeeld in zeven voorbeelden (tinten). Categorie acht beschrijft een uitzonderingssituatie waarbij geen van de voorgaande vormen werkt en je een stakeholder hoger in de organisatie laat beslissen. De laatste categorie laat een aantal tinten zien waarmee je meer mandaat verdient. Iedere categorie wordt afgesloten met een praktisch voorbeeld ter inspiratie en verheldering.

Conclusie

Een vlot leesbaar boek dat je aan de hand van een vijf stappenplan en negen categorieën met in totaal 50 tinten nee, meeneemt om op de juiste wijze nee te zeggen. Op verschillende plekken vind je kaders met daarin dingen om over na te denken. Dit helpt je om daadwerkelijk te begrijpen waar het over gaat. Ook krijg je praktijktips en vele praktijksituaties waarin op de juiste wijze nee wordt gezegd. Kortom verplichte literatuur voor product owners!

Af en toe had ik het idee dat heb ik in een ander boek ook gelezen maar ik miste verwijzingen naar bestaande boeken. Bijvoorbeeld de beschrijving van product owner-typen of de zin ‘moeten we dat nu doen’, In het hoofdstuk over nee zeggen had wellicht een link gelegd kunnen worden met het boek De kracht van Nee! – Positief Nee! zeggen om tot Ja! te komen geschreven door William Ury, daarnaast had een literatuurlijst niet misstaan (op mijn blog staan o.a. The Professional Product Owner, The Product Samurai).

Bestellen: 50 tinten nee – effectief stakeholdermanagement voor de product owner

Recensie Agile focus in besturing

9789401803878-480x600Agile focus in besturing – pocket guide voor executives in transformaties is geschreven door Marjolijn Feringa en Jeroen Venneman en biedt een praktische methode om als managementteam de focus te houden op de belangrijkste initiatieven en kwartaal voor kwartaal nieuwe focus aan te brengen zodat je als organisatie wendbaarder wordt.

Door het boek loopt een casus van een fictief bedrijf waarin het managementteam, onder begeleiding van een coach, het FOCUS-bord leert toe te passen. Dit visuele bord staat centraal in dit boek.

Het boek begint met een korte introductie op het Agile Manifesto en de vertaling van dit Manifesto voor directieteams in het Agile Executive Manifesto:

  1. Samenwerken aan teamdoelen boven gaan voor individuele mijlpalen
  2. Prioriteren van onderwerpen boven volgen van de agenda
  3. Wegnemen van belemmeringen boven stimuleren van resultaten
  4. Bijsturen op actuele inzichten boven analyseren van rapportages
  5. Visueel overzicht boven spreadsheet rapportages
  6. Verdeling van voorbereiding boven iedereen bereid alles voor
  7. Experimenteren binnen kaders boven plannen maken
  8. Elke kans om te verbeteren benutten boven tijd plannen voor verbeteren
  9. Stellen van vragen op de werkvloer boven accorderen van voorstellen in de vergaderzaal

Daarnaast wordt het belang van het hebben van een visie toegelicht en wat een verandering naar een meer wendbare organisatie betekent.

Het FOCUS-bord heeft drie doelen namelijk visuele ondersteuning, bevorderen van de samenwerking en het aanbrengen van focus. Het verbindt de strategie met de belangrijkste initiatieven, vertaalt de strategie (thema’s) in doelen op de lange termijn, het lopende jaar en het lopende/komende kwartaal (en uitgesplitst per maand). Er worden KPI’s gebruikt om eenduidig meetbare punten te creëren (status). Doelen worden middels initiatieven gerealiseerd. Initiatieven zijn verzamelingen van mijlpalen om een doel te bereiken. Mijlpalen worden als deliverables beschreven. Ieder initiatief heeft haar eigen facilitator die in de stand-up een update geeft over dit initiatief.

Het is de bedoeling dat wekelijks dit bord wordt bijgewerkt en besproken. Waarbij de voorkeur voor staand vergaderen wordt benadrukt. Voor deze stand-up hebben de auteurs een standaard agenda en grondregels opgesteld (Noot recensent: hoe verhoudt zich dit tot het tweede punt uit het Agile Executive Manifesto (Prioriteren van onderwerpen boven volgen van de agenda?). De agenda bestaat uit de volgende punten: check-in, status impediments, doorlopen initiatieven, hulpvragen/impediments/mededelingen, parkeerplaats-punten, fist of five (mini retro: vuist: kon niet slechter, 5 vingers: kon niet beter).

Iedere drie maanden moet het FOCUS-bord ververst worden, de zogenaamde kwartaalwissel. Hier vinden de volgende gebeurtenissen plaats: review resultaat afgelopen kwartaal en aanpassen/aanscherpen doelen, retrospective, planning komend kwartaal.

Het FOCUS-bord staat niet op zichzelf. Strategie verbindt alle teams en middels het cascaderen van strategische doelen naar onderliggende managementteams bereik je dat iedereen op dezelfde golflengte zit. Een mooie manier hiervoor is dat individuele directieleden op eenzelfde manier met een FOCUS-bord aan de slag gaan voor hun eigen MT.

Om in lijn met ontwikkelteams te blijven en hun werkwijze te begrijpen, wordt aanbevolen dat directie of MTs ook, een maar dan op maat gemaakte, Scrum werkwijze gaan hanteren. Verder beschrijven de auteurs een aantal technieken (FOCUS toolbox) zoals de manifesto workshop, strategy deployment (X-matrix) of Hoshin Kanri, veranderkompas, kanban-bord, focus radar, BCP-methode, feature mapping, de retrospective, delegation poker en de anticipate workshop.

Het boek eindigt met een drietal tips om te starten met agile focus in besturing, een agile leiderschap maturity niveau checklist en een beschrijving van de Rabobank case, de FOCUS way of working.

Conclusie: Vlot leesbaar boek met een praktische aanpak en voorbeelden waarmee je als managementteam direct aan de gang kan gaan om een meer agile focus in de besturing aan te brengen.

Jammer dat de voorbeeld FOCUS-borden zo klein gedrukt zijn (zal wel aan mijn ogen liggen maar ik kon de bovenste regel niet lezen). Daarnaast heb ik persoonlijk moeite met het gebruik van het woord facilitator van het initiatief. Deze facilitator kan volgens de auteurs periodiek wisselen. Ik zou liever geen wisselingen willen zien en dat het de eigenaar/sponsor van een initiatief is die toelicht als er problemen zijn. Daarnaast wordt eigenaar initiatief en facilitator door elkaar gebruikt in de tekst. Verderop in het boek wordt vervolgens het begrip facilitator gebruikt als iemand buiten het team die optreedt als procesbewaker.

Bestellen: Agile focus in besturing

via de auteurs heb ik een voorbeeld van een FOCUS-bord gekregen.

FOCUS-Bord

Downloaden van de drie in het boek genoemde voorbeeldborden: FOCUS bord

In de kop vind je de omschrijvingen van de kolommen, respectievelijk: Thema, Over een jaar doelen, Dit kwartaal doelen, Status van doelen, Belangrijke initiatieven mijlpalen afgelopen kwartaal, mijlpalen maand 1, mijlpalen maand 2, mijlpalen maand 3, mijlpalen komende kwartaal en mijlpalen later, Impediments / Acties (To do, Doing, done) en rechtsonder de Parkeerplek.

Recensies: Het bochtenwerk van de opdrachtgever en Schaalsprongen in de opdracht

Van Edwin van Dieën Kreeg ik bijgaande eerste twee publicaties Het bochtenwerk van de opdrachtgever en Schaalsprongen in de opdracht uit de Kennedy-reeks over goed opdrachtgeverschap. Naar John F. Kennedy vernoemd omdat zijn moon speech (1962] symbool staat voor inspirerend leiderschap en dat kunnen we zien als een sleutelcompetentie van opdrachtgeverschap.

Het bochtenwerk van de opdrachtgever

9789082061611-480x600De eerste publicatie Het bochtenwerk van de opdrachtgever is geschreven door Herman Walta. Geen theorieboek, geen business roman maar een toneelstuk (sketch) over opdrachtgeverschap. Deze sketch is voor het eerst opgevoerd tijdens de IPMA Parade (2012).

In het stuk volgen we een wethouder Onderwijs die als opdrachtgever optreedt bij de bouw van een nieuwe basisschool. In vijf bedrijven krijgen we verschillende dilemma’s en keuzes voorgeschoteld en zien we de consequenties van de gemaakte keuzes waarbij de wethouder steeds verder uit de bocht vliegt. Hierbij staan de vijf bedrijven voor: het goede begin ofwel het besluit tot bouwen, ik ben goed dus ik ben gulzig, als u haast heeft, neem geen tijd, uit de bocht! En ten slotte nog verder uit de bocht.

Een korte leesbare en aansprekende tekst waarin duidelijk wordt dat een opdrachtgever een project kan maken of breken. Prima bruikbaar voor opdrachtgevers in spé die voor hun eerste opdracht staan.

Bestellen: Het bochtenwerk van een opdrachtgever

Schaalsprongen in de opdracht

9789082061628-480x600In het boek Schaalsprongen in de opdracht, geschreven door Edwin van Dieën, wordt een link gelegd met het Cynefin model van Snowdon waarbinnen de auteur verschillende vormen van opdrachtgeverschap positioneert. Daarnaast wordt ook het situationeel leidershapsmodel van Hersey en Blanchard binnen het Cynefin model geplot.

De auteur schetst de samenwerking tussen opdrachtgever en opdrachtnemer aan de hand van het zandloper-model. Informatiestromen lopen van boven (de opdrachtgever) naar beneden (de opdrachtnemer) en terug waarbij de opdrachtgever de ruis van boven filtert en de opdrachtnemer niet alle details naar boven stuurt. Dit model wordt vervolgens geprojecteerd in de kwadranten van Cynefin model:

  • Simpel (klus): Opdrachtgever rol is heel beperkt, de opdrachtnemer voert uit
  • Gecompliceerd: Opdrachtgever beslist over oplossing, opdrachtnemer stelt oplossing voor en realiseert
  • Complex: stuurgroep (coalitie) die de rol van opdrachtgever invult
  • Chaos: opdrachtgeverschap zal gedurende de looptijd van het project door verschillende (combinaties van) personen worden ingevuld

Persoonlijk had ik een andere keuze gemaakt met de positionering van opdrachtgeverschap waarbij ik de rol van opdrachtgever gedurende de looptijd van een project in principe bij één persoon houd. In het gecompliceerde domein passen aanpakken zoals PRINCE2 prima waarbij een stuurgroep uit opdrachtgever, sr gebruiker(s) en sr. Leverancier(s) bestaat. In het complexe domein kan je, je juist afvragen of een agile aanpak (experimenteren) met veel decentrale besluitvorming, dus kleine stuurgroep niet beter werkt. In het chaos domein zou ik nog steeds voor één opdrachtgever bijgestaan door anderen gaan, waarbij juist de opdrachtnemer in de tijd kan wisselen (eerst opdrachtnemer om de crisis te stoppen dan een andere opdrachtnemer om puin te ruimen en dan iemand om op te bouwen).

Het tweede gedeelte van het boek koppelt situationeel leiderschap van de opdrachtgever wederom aan de kwadranten van het Cynefin model.

  • Simpel: Delegeren
  • Gecompliceerd: hier passen we, in lijn met de situatie, de bijbehorende stijl van leiderschap toe
  • Complex: hier vragen we van de opdrachtgever om de vier verschillende leiderschap stijlen tegelijkertijd toe te passen
  • Chaos: hier stelt de auteur dat de assen van taakbekwaamheid en motivatie verder doorlopen

Ik vind de opsomming wat gezocht en snap de weergave van het model binnen chaos niet. M.i. kan je afhankelijk van de situatie aan de hand van het model van Hersey en Blanchard de bijbehorende leiderschapsstijl bepalen en naarmate het project complexer wordt zal je vaker binnen dat project als opdrachtgever een andere leiderschapsstijl moeten kiezen.

Kortom een mooie poging om opdrachtgeverschap en stijlen van leidinggeven te positioneren in het Cynefin model maar persoonlijk hecht ik meer waarde aan de wijze waarop besluitvorming tot stand komt binnen de vier kwadranten van het Cynefin model:

  • Simpel: waarnemen – categoriseren – reageren
  • Gecompliceerd: waarnemen – analyseren – reageren
  • Complex: uitproberen – waarnemen – reageren
  • Chaos: handelen – waarnemen – reageren

Neemt niet weg dat ik de Kennedy-reeks een mooi initiatief vind en ik hoop dat er nog vele interessante delen mogen verschijnen. Naar wat ik begrepen heb zullen mogelijke volgende publicaties ingaan op paradigma’s rond opdrachtgeverschap en talentontwikkeling bij opdrachtgevers.

Bestellen: Schaalsprongen in de opdracht

Recensie NR. 6 – 2019 Vakblad Projectmanagement

12985_vkbl_projectmng_6_cover_14Zojuist een sneak preview van het zesde nummer van het vakblad Projectmanagement van KWD Resultaatmanagement gehad. Je zal nog een paar weken moeten wachten voordat het in de bus ligt maar ook deze keer weer een ruim aanbod aan verschillende artikelen.

In het eerste artikel Psychologische valkuilen in grote IT-projecten belicht Arno Nuijten een viertal valkuilen die de projectmanager er toe kunnen zetten om risico’s te nemen: doelsubstitutie (Noot recensent: PRINCE2 was zo gek nog niet met haar principe continue zakelijke rechtvaardiging), zelfbevestiging, de meters op het dashboard sturen onze beslissingen (casino-gedrag, completion effect, noot recensent: ik noem dat het 90% syndroom. Het is bijna af en dat wordt week na week herhaald) en de laatste valkuil perceived control. Vervolgens wordt ingegaan op een onderzoek waarin een aantal hypothesen worden getest om te zien in hoeverre het uitmaakt of de waarschuwing wordt gegeven door iemand die gezien wordt als ‘partner’ of juist als tegenstander.

Het volgende artikel Samenhang in het bouwen is verdwenen, geschreven door Cok de Zwart gaat over zijn interview met architect Hans Ruijssenaars. Vroeger was je zowel architect als bouwmeester en dus ook projectmanager. Tegenwoordig worden alle rollen los van elkaar gecontracteerd en mag je als projectmanager dit alles aansturen zonder te beschikken over een samenhangende, vooraf overeengekomen visie.

Gerard Meijer, Kaj Wijnands en Peter Storm gaan in op de trends binnen en de impact op het vakgebied projectmanagement zoals die tijdens de 12e KWD Projectmanagement vakdag door deelnemers zijn besproken. In het artikel worden de 7 belangrijkste besproken met als top 3: verschuiving van waterval naar agile neemt verder toe, er zullen steeds meer mengvormen worden toegepast in de aanpak van projecten en als nummer 3 de business kant van projecten zal nog meer geïntegreerd worden met de IT-kant. Waarbij het artikel eindigt met een scenario waarbij AI de rol van de projectmanager overneemt.

In een volgend artikel, als eerste in een serie van vier, gaan Liesbeth Rijsdijk en Maike de Bot in op wicked vraagstukken die per definitie niet projectmatig kunnen worden aangepakt maar vragen om een multi-actor procesmanagementaanpak binnen een netwerksamenwerkingsstructuur. In dit artikel worden de kenmerken van wicked vraagstukken besproken en hoe deze kunnen variëren op de dimensies: grenzen overschrijdend, wederkerige afhankelijkheid, einddoel, invloed en context, informatie en belangen, maatschappelijke relevantie en benadering/aanpak. Middels het 4Emodel voor waarde creatie (Explore, Engaging, Elaboration, Evaluation) kan een overzicht gecreëerd worden van oorzaken, gevolgen, oplossingen, stakeholders, activiteiten en gecreëerde waarden.

In het artikel Integrated agile pleiten Saskia Giebels en George Miles voor een combinatie van nadenken vooraf en agile ontwikkelen. Beginnen met het vaststellen van een visie, vervolgens risico’s adresseren (technologie, financiën en businessmodel, kennis en middelen, stakeholders, propositie en wet en regelgeving) en daarna agile ontwikkelen. M.i. Gaan de auteurs soms wat kort door de bocht. Bij agile ontwikkeling hoort een product owner en de professionele product owner begint met een productvisie, verder is de voorgestelde combinatie precies wat we tegenkomen in methoden zoals PRINCE2 Agile en AgilePM.

Roeland Rustema gaat in zijn artikel Agile werken kan wringen in bestaande organisatie in op zijn onderzoek om de interactie tussen agile softwareontwikkeling en de organisatie daaromheen te begrijpen en wat een organisatie kan doen om agile softwareontwikkeling beter te faciliteren. De belangrijkste bevindingen zijn de besturing rond/boven het teamniveau, het begrijpen van agile en de tijd die een agile transitie kost.

Luuk Ketel en Peter Storm gaan opzoek naar de menselijke factor in risicomanagement in het gelijknamige artikel. Zij stellen dat risico’s niet in de technologie maar in menselijke en organisatorische zaken zitten, risico-inventarisaties met oogkleppen op worden uitgevoerd en teams leren te weinig. In projecten die ontsporen zien we dat meerdere vicieuze cirkels (van vertraging, van publiek schandaal) aan elkaar worden gekoppeld en elkaar versterken en het is dus zaak om aan de hand van systeem- en gedragsignalen dit vroegtijdig te onderkennen en daarop te acteren.

Uiteraard ontbreken de drie ‘projectfilosofen’ John Hermarij die de balans zoekt tussen ik en wij, Ben Berndt die het falend toezicht door Raden van Commissarissen aan de kaak stelt en Peter Storm die zich afvraagt of het nog wat wordt met de Chief Project Owner, niet?

Deze keer twee een boekrecensies. Een van Remmelt van der Wal over Projectstrategie, ritmes en routine en een van mijn hand over het boek Teams door het vuur en voorzien van een quick reference card.

Het vakblad biedt weer een veelheid aan verschillende artikelen. Als ik deze uitgave echter vergelijk met de eerdere nummers dan vind ik het praktisch toepasbare gehalte voor de projectmanager deze keer wat minder.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het een kwestie van abonneren. Zie: KWD Resultaatmanagement.

Review: DevOps a business perspective

9789401803724-480x600Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.

Definition DevOps: “DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with modern information technology due to cultural, organizational and technical changes

The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.

The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.

Why DevOps:

  • reduce time to market (business idea testing, hypothesis evaluation)
  • Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
  • Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)

DevOps is based on five principles:

  • Value stream. Creating value in response to a customer’s request
  • Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
  • Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
  • Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
  • The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically.

Ten DevOps key practices:

  • Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
  • Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
  • Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
  • Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
  • Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
  • Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
  • Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
  • Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
  • Task prioritization based on cost of delay divided by duration
  • Continual identification, exploitation and elevation of constraints

The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.

Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.

To order: DevOps a business perspective

Review: The Professional Product Owner

poDon McGreal and Ralph Jocham wrote the book The Professional Product Owner – Leveraging Scrum as a competitive advantage.

This book gives you the insights how you, as a product owner, can identify, measure, and maximize value throughout your entire product lifecycle.

The authors explain that you can call yourself a professional product owner if you can excite, can envision, can cause the product to emerge and you can manage and administer the product as it matures.

The chapters in the book are clustered into three parts strategy, Scrum and tactics. Every chapter starts with a little quiz (statement: agree/disagree) and at the end of each chapter you will find the answers.

The first part – strategy focusses on proper agile product management and maximizing the return on investment (ROI of a product by looking at the three Vs (vision, value, and validation) as a way to achieve this.

Vision creates transparency, value provides you with something to inspect and validation causes adaption. The authors explain why the world of product management a lot bigger is than Scrum. There are many types of product owners starting with scribe, proxy, business representative, sponsor and entrepreneur. Going from left to right the expected benefits from the product owner type will increase heavily. We got an explanation of the business model canvas, the added value of a good vision and what it means to deliver value. Evidence-based management with current value, unrealized value, ability to innovate and time to market is illustrated (in grey boxes you will find the corresponding text from the EBMgt Guide (see review on my blog). In the last chapter – validation, the authors discuss feedback, the usage of different types of MVP’s, the Kano-model and the build-measure-learn feedback loop (based on Eric Ries’ book Lean Start-up).

Part II – Scrum explains empirical process control and how Scrum is a tool for managing complexity and continuous delivery of value. In the text you will find, in grey boxes, corresponding text form the Scrum guide too.

It starts with an explanation of complexity. You get a certainty quiz to measure the uncertainty of your own environment/team. To visualize complexity a modified Stacey graph (categorization model) is explained as well as the usage of Dave Snowdon’s Cynefin model (sense-making) with the five domains obvious, complicated, complex, chaos and disorder. The empiricism of Scrum helps to address risks (misunderstanding of requirements, lack of top management commitment and support, lack of adequate user involvement, failure to gain user commitment, failure to manage end user expectations and changes to requirements and lack of an effective project management methodology). For the rest of this part the focus is on Scrum itself. The pillars (transparency, inspection and adaptation), The Scrum roles (product owner, development team and scrum master) and stakeholders, the Scrum artifacts (product backlog, sprint backlog and the increment) and not official Scrum artifacts (Definition of done, burn-down, burn-up charts), and Scrum events (sprint, sprint planning, daily scrum, sprint review, sprint retrospective). For every element the authors explain the relation with the product owner.

qrc (backlog items, 190121) v1.0To download: qrc (backlog items, 190121) v1.0

The last part – tactics introduces more concrete practices and tools for managing product backlogs (see the attached QRC) and release plans and concludes by examining what it means to be a professional product owner.

It starts with an explanation of a requirement and you get an explanation of the different items on a product backlog (feature requirements, non-functional requirements, experiments, user stories, bugs/defects, user cases, capabilities, …) and an example of a product backlog item template with acceptance criteria and common ways of writing acceptance criteria (Test that …, Demonstrate that …, Gherkin syntax (given, when, then)). How you can order a backlog based on business value, risk, cost/size and dependency including measuring value, risk and size is a next topic. The definition of “done” is defined as well the meaning of ready. A lot of other techniques are discussed e.g. story mapping, impact mapping, specification by example and agile testing. Release management is the next big chapter in this part. What are release management, reasons to release, release strategy, major, minor and functional releases? How can you use estimation and velocity to answer the question when will I get it? Scaling in terms of more products or more teams as well as a brief overview of the Nexus framework are introduced. This chapter ends with some more techniques like the Monte Carlo simulation to estimate a product backlog, velocity breakdown by type (features, bugs, technical debt and infrastructure), budgeting, governance and compliance, release kick-off and quality (definitions, product and technical quality, keeping quality). This part ends with the skills and traits of a good product owner.

Conclusion: If you are a product owner this is absolutely a must read. You get explanations, techniques, examples and real-life cases from the authors how you have to and can play your role as a professional product owner.

To order: The Professional Product Owner