In de wereld van Scrum is Gunther Verheyen geen onbekende. Hij heeft jaren samengewerkt met Ken Schwaber bij Scrum.org en heeft eerder het succesvolle “Scrum – A Pocket Guide” geschreven. Als eindredacteur heeft Verheyen de taak op zich genomen om de essays te selecteren en de auteurs van feedback en suggesties te voorzien. Zodoende is “97 Things every Scrum Practitioner should know” een rijke bundel gericht op iedereen met een interesse in Scrum. Het is niet de eerste verzameling van “97 zaken die elke … zou moeten weten”. Eerdere versies waren gericht op programmeurs, software architecten en bijvoorbeeld projectmanagers. De huidige uitgave is volledig bedoeld voor Scrum practitioners waarbij wederom gebruik is gemaakt van de gedeelde kennis en ervaring vanuit de Scrum community.

De verzameling internationale auteurs die een bijdrage heeft geleverd is indrukwekkend. Het lijkt mij dan ook sterk dat de lezer alle schrijvers zal kennen. Mijn eigen score kwam uit op 20, waaronder bijvoorbeeld onze landgenoten Bas Vodde en Sjoerd Kranendonk. Het mooie is dat de auteurs echt uiteenlopende achtergronden hebben, dit zie je ook duidelijk terug in de bijdragen. De ene keer worden hele concrete tips gegeven en een andere keer wordt er bijvoorbeeld ingegaan op een van de principes van Scrum.

Het boek leent zich goed om willekeurig door de essays te bladeren en te lezen. Of pak de inhoudsopgave en begin bij de meest prikkelende titel. Mijn tip voor lezers is: lees dit boek niet in één keer uit, maar neem het in een paar keer door. Het liefste in een aantal weken. Dat geeft je de tijd om te reflecteren op de stellingen en je eigen beelden te vormen. Het boek is overigens niet volledig zonder structuur. Verheyen heeft tien verschillende onderwerpen als kapstok geselecteerd en de essays hieraan opgehangen. Wellicht overbodig maar verschillende essays passen natuurlijk prima bij meerdere haakjes. Ieder essay bestaat uit maximaal 2 pagina’s, welke de lezer door de drukwijze altijd openliggend voor zich heeft. Dit geeft de essays een goede leesbaarheid en ook de mogelijkheid om random het boek open te slaan, hiermee kom je altijd op een volledig essay terecht.

Delen (parts):
I. Start, Adopt, Repeat
II. Products Deliver Value
III. Collaboration Is Key
IV. Development Is Multifaceted Work
V. Events, Not Meetings
VI. Mastery Does Matter
VII. People, All Too Human
VIII. Values Drive Behavior
IX. Organizational Design
X. Scrum Off Script

Inhoudelijk bevat de bundel voor iedereen interessante inzichten. Je zult zien dat zo en dan auteurs minder verrassen en hun reeds bestaande ideeën wederom in dit werk delen. Dat is niet erg en zeker niet storend. De lezer zal het – net als ik – ook niet met alle meningen en ideeën eens zijn. Dit zal veelal van de context en je eigen ervaring afhangen, wellicht ben je nog niet in een situatie geweest waarin het gesuggereerde een passende practice is. De ruimte en noodzaak voor context afhankelijke practices en invullingen is ook een direct gevolg van de opzet van de Scrum Guide – de nieuwste versie bevat slechts 19 pagina’s. Dat sluit aan bij het beoogde doel van de guide, zoals Ken Schwaber’s in zijn essay bevestigt.

Het is onmogelijk om alle bijdragen samen te vatten. Daarom enkele quotes en meningen die mij persoonlijk prikkelden:
– Todd Miller: “Existing teams find themselves surrounded by so many complementary practices that is negatively impacts their ability to look inspect, adapt and be transparent”
– Bas Vodde: “Never use Jira for Sprint Backlogs”
– Derek Davidson: “Humility could be the sixth Scrum Value”
– James O. Coplien: “Running an Agile enterprise is a matter of introducing such hubs (people connected to other people) and nurturing latent hubs, rather than routing communication through the least common manager”

Conclusie

Scrum zelf lijkt misschien eenvoudig, het effectief kunnen inzetten van Scrum om met teams complexe problemen op te lossen blijkt in praktijk nog steeds een stuk lastiger. Dit boek helpt je op weg met zijn rijke verzameling van essays van internationale Scrum professionals. Door de kwalitatief hoge inhoud en toegankelijke opzet kan het zowel een startpunt, naslagwerk als een bron van inspiratie zijn voor iedereen met een interesse of gezond kritische houding ten opzichte van Scrum.

Voor meer informatie over de editor en het boek zie: guntherverheyen.com.

Cheers,
– Sjors Meekels

Agile Transformeren (Van Solingen ea.)

Wat is Agile transformeren en hoe pak ik dit binnen mijn organisatie aan? Met deze vragen zijn de vier auteurs Bas van Lieshout, Hendrik-Jan van der Waal, Astrid Karsten en Rini van Sollingen aan de slag gegaan. Niet zonder resultaat. Agile transformeren geeft een degelijke beschrijving van een stappenplan en aandachtsgebieden voor een Agile transformatie. Hiermee is het een goed naslagwerk ...

Lees volledige review

Performance management in een Agile werkomgeving

Waarom is het zo moeilijk om goede beoordelingsgesprekken te voeren? En waarom gaat het zo vaak fout? Hoewel organisaties veel tijd besteden aan de uitvoer en de vastlegging, zijn de betrokken managers en medewerkers vaak teleurgesteld in het eindresultaat. Er moet inmiddels toch een betere aanpak op het gebied van belonen en beoordelen zijn. In het boek Performance management in een agile ...

Lees volledige review

30 Creatieve workouts – Ina Sok

Op zoek naar inspiratie voor workshops voor jezelf, je team of je hele organisatie? In 30 Creatieve workouts beschrijft auteur Ina Sok 30 manieren om je eigen creatieve spier te ontwikkelen of die in je organisatie te ontdekken. Ina Sok omschrijft zichzelf als een ‘een creatieve synergist’. Haar achtergrond in zowel organisatieadvies als de kunsten heeft haar doen inzien dat creativiteit ook ...

Lees volledige review

Voor alle boekreviews zie: Alle boekreviews of de side navigation.

Where does the need for an agile management attitude derive from? In many organizations Agile adoption was a bottom-up movement. A few teams started experimenting with Scrum or XP and soon the Agile oil stain was spreading throughout the organization. Currently, complete organizations are transformed into Agile driven structures from top to bottom and back up again. These organizations, but especially the teams, require a different management style. This is where an agile attitude towards managing teams becomes indispensable. The behaviour I encourage managers to show is on the one hand vision and leadership (including being able to make the necessary ‘judgement calls’). And on the other hand, the ability to create the right climate for teams to self-organize and solve problems. In my experience it is hard for (senior) managers to find a good balance between servant leadership – acting according the Scrum values – and having a more direct / autocratic leadership style. Especially when things get tense and the stakes are high.

Let’s illustrate the difference between servant and direct leadership in an example. If, when and how you intervene as manager – in case a commercially important deadline is under threat of non-delivery – is distinctive. Probably one would say: “It depends”. Yet, it is striking to see how many managers will fall back into ‘old school’ habits of completely taking over, bringing in the well-known-go-to guys (heroes) and demanding daily updates from a team lead. Although there might still be cases where this is the best temporary approach, it comes with a risk. If you don’t coach teams to determine root causes or fail to make sure they learn and come out of these situations in a better shape, a lot of organizational value is unfulfilled. In fact, the exact opposite behaviour is encouraged. The go-to-guys remain the organizational heroes and no one is stimulated to really change something because top down interventions remain the norm.

Applying the Scrum values to the managerial level
Now we take the Scrum values into account. In the said example, Respect and Openness – or the lack thereof – immediately come to mind. Respect towards the teams and professionals (including their agreed upon way of working) and Openness to existing challenges but also to possible solutions. Courage is found in placing your trust in the people to do the right things and to help them to improve. Root causes – in aforementioned case a commercial disaster – are often founded in unrealistic goals from the start or vague promises that were made before the teams were even aware. So, it may take Courage and Commitment to address these as a manager in your own organization. Following the Scrum values may prevent you to fallback into old behavioural ‘steering patterns. Let’s briefly explore three key focus areas of managers.

1. Leading by example. An important managerial aspect is leading by example; show your teams that a promise means something. That the suggestion of you willing to help them is not an empty one. Even better, go the extra mile for your people and teams. Being an example also resonates with being involved. Know what is going on and why. You are aware of the biggest impediments the teams are facing, you also know what the plan is to fix them and what your role is in it. You know this not from a bi-weekly status update from a team lead. No. You know this because you were at the Review, possibly the Retrospective and you got the latest at this morning’s Stand ups. You show Respect for the Scrum framework, Focus on team goals and the Commitment to help and serve them.

2. Defining organizational structure. Defining the actual structure of the organization is a classic management responsibility, including establishing the rules on the development playground. In every organization there are boundaries and contexts that determine the observed self-control or freedom that teams have. It is important to have a clear common understanding on these boundaries and levels of freedom. (See Jurgen Appelo’s delegation poker in Managing for Happiness as a tool to discuss ideas with your teams and establish shared understanding.) This includes making sure the teams have capacity available to improve, to experiment and to work on a learning organization. Openness and Respect of the rules and the process of getting the rules in place, Courage to leave room in packed backlogs and keeping Commitment when situations are tense.
Delegation poker

3. Caring for (managing) people. Show people they matter and that they are the company’s major asset instead of just resources. This means making time for them, enough time. Instead of being always late for personal appointments or worse, cancelling them more than having them. In other words: having Respect and Commitment for the well-being of your colleagues. Sometimes urging people to go home instead of stressing a deadline. It would be great if the leaders of the future coach their teams to act with these values in mind and at the same time allow them to make mistakes. Courage also means to be able to have the ‘difficult talks’ with people and on the other side being transparent about your own mistakes or short comings.

These are just three of the important trades managers need to employ. When you keep the Scrum Values in mind an Agile attitude feels like a natural thing to do. Luckily, I have witnessed a few excellent managerial examples. People that have a genuine interest in people, are a little geeky on technology and have fundamental organizational antennas. Don’t make the mistake to think these men and women were soft. They were honest and clear. Did they make mistakes? Yes, and they were the first to acknowledge this. And that is great Courage!

Duck & Birdie and more comics.

These comics are originally called “Fokke & Sukke” and created by the Dutch team: illustrator Jean-Marc van Tol and writers John Reid and Bastiaan Geleijnse. See: Fokke & Sukke for more information.

If you are looking for more comics on Agile you can check out: Dilbert still struggles working Agile & Dilbert saves the Agile day and see how Dilbert is overcoming it all.

[1] http://www.foksuk.nl/ & https://nl.wikipedia.org/wiki/Fokke_%26_Sukke
[2] https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/
[3] https://www.scrum.org/resources/scrum-values-poster
[4] https://management30.com/practice/delegation-poker/
[5] https://www.agitma.nl/managing-for-happiness-jurgen-appelo

Van de vier auteurs is Rini van Sollingen waarschijnlijk het meest bekend onder het grote publiek. Dat kan zijn van een van zijn eerdere boeken zoals De Bijenherder of Agile, als spreker op Agile events, deeltijdhoogleraar of als adviseur bij vaak grotere adviestrajecten. Dat neemt niet weg dat alle auteurs duidelijk hun achtergrond en ervaringen mee hebben gegeven aan hun gezamenlijke werk Agile Transformeren. Een mooie mix van coaching, Scrum, SAFe en HR-achtergronden naast jaren ervaring in het veld zorgen voor een keur aan inzichten en praktijkvoorbeelden.

De opbouw van het boek is eenduidig. Deel A beschrijft de noodzaak tot transformeren, deel B beschrijft het plan om de Agile transformatie uit te voeren en in Deel C worden thema’s behandeld die extra borging behoeven tijdens de transformatie. Deel A is niet het meest spannende deel, toch geven de auteurs hier een interessante inkijk in de drijvende kracht achter de enorme aandacht waar Agile zich al jaren op kan verheugen. Zij beargumenteren dat deze drijvende kracht niet ‘Agile-als modeverschijnsel’ is, maar de verregaande digitalisering en verandering van klantverwachtingen. Deze observatie maakt direct duidelijk waarom een Agile transformatie nooit een doel op zich kan zijn maar slechts een middel.

Het stappenplan in deel B waar zij de lezers doorheen voeren is transparant beschreven. Vanaf het begin is helder dat het een aanpak betreft die uitgevoerd wordt met eenzelfde mindset als opgenomen in de titel van het boek. Agile dus. Het stappenplan biedt voldoende houvast en kaders om de route uit te stippelen, maar gedurende het traject zal het plan gegarandeerd bijgestuurd en aangepast moete worden. De stappen zien er als volgt uit:

1. Transformatievisie: bepaal de scope
2. Transformatievisie: onderzoek de (start)situatie
3. Transformatievisie: communiceer de urgentie
4. Transformatie-executie: maak een bouwschets
5. Transformatie-executie: bepaal de veranderstrategie
6. Transformatie-executie: maak een transformatieroadmap
7. Transformatie-executie: implementeer in korte iteraties
8. Transformatie-executie: meet de voortgang

Het verbaast niet dat het stappenplan veel gelijkenis vertoont met de aanpak van andere veranderprogramma’s. Een transformatie is immers een verandertraject. Verwacht bovendien niet dat je met het lezen van dit boek een recept in handen hebt om één op één in je eigen organisatie toe te passen. Zoals de auteurs keurig melden, zul je je eigen plan moeten maken op basis van de kenmerken van jouw organisatie. Het plan geeft met de stappen en aandachtspunten grofweg de ‘Wat’ en een beetje het ‘Hoe’ weer. Echter, het exacte ‘Hoe nu daadwerkelijk in praktijk’ zul je zelf moeten vormgeven. Wel helpen de cases en de hoofdstuk afsluitende ‘Aan de slag’ lijstjes je goed op weg. Kleine kanttekening is dat – hoewel de ‘Aan de slag’ lijstjes goede suggesties en ideeën bevatten – de suggesties en ideeën vaak one-liners zijn waar dikwijls een nieuwe wereld van vragen achter schuil gaat.

Om de kans van slagen van de transformatie te vergroten worden in Deel C een zevental thema’s besproken die naast de transformatie als zodanig extra borging verdienen. Het betreft een mix van harde en zachte criteria en gezamenlijk geven zij een inkijk in zaken die in de praktijk vaak foutlopen. De borgingsthema’s zijn:

1. Talentontwikkeling
2. Leiderschap
3. Strategische besturing
4. Meten en afstemmen
5. Financiën
6. Compliance
7. Technologie

De uitdagingen op het gebied van Financiën, Compliance en Technologie (thema’s 5, 6 en 7) waren voor mijzelf het meest herkenbaar, gevolgd door Leiderschap en Strategische Besturing (thema’s 2 en 3). Deze vijf thema’s zullen in menig traject tot wrijving en hinder hebben geleid. Het is handig dat de auteurs deel C hebben losgekoppeld van het stappenplan. Dat geeft meer structuur en de mogelijkheid om direct naar een borgingsthema te bladeren als je daar extra aandacht aan wil geven.

Eerlijkheidshalve nog het volgende; vooraf was ik terughoudend om het boek te lezen vanwege de line-up van auteurs. Vier, door de wolf geverfde, Agile professionals allen werkzaam bij een en hetzelfde consultancy bedrijf dat leeft van de inzet van deze consultants en adviseurs. Een verkooppitch leek in de maak. Mijn angst bleek ongegrond; de auteurs geven een goede inhoudelijke beschrijving van hun ervaringen, inclusief de zaken waarmee zij worstelden. Persoonlijk had ik het passender gevonden wanneer het voorwoord wel door iemand van buiten het eigen bedrijf was geschreven, maar dat terzijde.

Conclusie

Voor lezers die werkzaam zijn of zijn geweest binnen organisaties in een transitie zal het boek een feest van herkenning zijn. Ik verwacht dat iedereen minimaal 2 of meer cases zo kan projecteren op zijn of haar eigen organisatie. Dat is niet erg, integendeel zelfs. Het laat zien dat – hoewel geen transformatietraject hetzelfde verloopt en plannen altijd worden bijgestuurd – er veel terugkerende patronen en aandachtsgebieden zijn. Dat geeft Agile transformeren zijn waarde voor de lezers. Ondanks de herkenning, zijn er voldoende aandachtsgebieden en handvatten om mee te nemen in ieder transformatieproces.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Er moet inmiddels toch een betere aanpak op het gebied van belonen en beoordelen zijn. In het boek Performance management in een agile werkomgeving geven de drie auteurs, Kilian Wawoe, Maud Schaapveld en Rutger Verbeet antwoord op bovenstaande vragen over performance management en doen zij een voorzet voor een nieuw systeem van performance management.

Ben u wel eens een leidinggevende tegengekomen die uitzag naar de eindejaarsperiode? Vrijwel niemand heeft het maken van beoordelingen en voeren van beoordelingsgesprekken als favoriete bezigheid. Hoe komt dit? Een van de problemen is dat het gewoonweg ontzettend moeilijk is om een eerlijke beoordeling op te stellen. Daarnaast is er nog de kunst van het bespreken van deze beoordeling en een medewerker met het juiste gevoel het gesprek laten uitgaan. De drie auteurs, Kilian, Schaapveld en Verbeet schetsen de geschiedenis van performance management en laten zien waarom organisaties dit proces nooit volledig in de vingers hebben gekregen. Hiermee is Performance management in een Agile werkomgeving geschikt voor iedere HR-professional of leidinggevende die een nieuwe kant op wil met performance management.

Het boek is logisch opgebouwd. In het eerste deel, dat vier hoofdstukken omvat, wordt het klassieke theoretische kader beschreven en komen belangrijke historische stromingen, zoals operante conditionering, de equity -theorie en goalsetting-theorie aan bod. Daarna volgt de ontwikkeling en de toepassing in praktijk van grofweg honderd jaar geleden tot nu. De twee bepalende visies hierbij, de bedrijfskundige- en de mensgerichte visie, worden tegen elkaar afgezet. In het laatste hoofdstuk worden de knelpunten besproken en wordt de noodzaak voor aanpassingen aan het huidige systeem aangetoond.

Deel II van het boek, met drie hoofdstukken, is gericht op een nieuwe invulling van performance management. De auteurs starten met het definiëren van ontwerpcriteria in hoofdstuk 5. Daarna beschrijven zij de taxonomie van het nieuwe systeem dat zij voor ogen hebben. Deze taxonomie bestaat uit 9 deelprocessen en wordt per deelproces afgezet tegen de huidige gangbare werkwijzen. Tot slot wordt in hoofdstuk 7 beknopt een route voorgesteld hoe de invoering van een nieuw systeem eruit kan komen te zien. Het is geen verrassing dat het meest vernieuwende deel van het boek in de hoofdstukken 5 en 6 zit. Een belangrijk inzicht dat de auteurs uitwerken is het splitsen van traditionele rollen die bij één leidinggevende liggen naar het beleggen van deze rollen bij meerdere personen. Hiervoor onderkennen zij 3 rollen (coördinator, coach en rechter) en per rol een drietal processen waarmee het hele performance management afgedekt is. Zodoende trekken zij niet alleen het beoordelen los van belonen maar zorgen zij dat een medewerker:

– gestuurd wordt door reflectie op dagelijks werk (door de rol: coördinator);
– gecoacht wordt op mobiliteit, kennis en vitale (door de rol: coach);
– beoordeeld wordt op zijn werk via onder ander persoonlijke inschaling en benchmarking (door de rol: rechter).

Het onderwerp performance management heeft de afgelopen jaren op veel interesse en aandacht mogen rekenen. Veel organisaties hebben stappen genomen om de eigen systemen aan te passen aan de nieuwe eisen van het Agile werken. Soms met succes, soms met vallen en opstaan, en vaak ook met tegenvallende resultaten. De auteurs hebben voor dit boek een groot aantal professionals van uiteenlopende organisaties gesproken en veel vragen gesteld over de invulling en benadering van performance management en hoe goed deze in de praktijk functioneren. Zij zijn erin geslaagd om ondanks de vele meningen en tegenstrijdige antwoorden, een samenhangend verhaal op te stellen. Een intrigerende observatie is dat met name managers moeite kunnen hebben bij het loslaten van de ‘macht’ van het beoordelen en belonen. Erg interessant, zeker omdat uit alle theorie en ervaringen blijkt dat de huidige systemen voor kenniswerkers echt niet langer voldoen.

Conclusie

In het boek zijn diverse casussen opgenomen waarin verschillende praktijkinitiatieven zijn beschreven. Deze geven de lezer een neutrale inkijk in de benaderingen die organisaties hebben gekozen, zonder dat sprake is van een beoordeling of ‘succesverhaal’ van de auteurs zelf. Voor mijzelf voelde het eerste deel van het boek als een interessant college over de ontwikkeling en opbouw van performance management. De theorieblokken zijn niet te lang en schetsen een goed beeld hoe we zijn uitgekomen op de huidige toegepaste inzichten. Zeker voor (beginnend) leidinggevenden zonder P&O opleiding kan dit deel erg boeiend zijn. Deel II van het boek zal ook HR-professionals inspiratie bieden bij het herijken van de eigen processen. De vraag of de nieuwe taxonomie succesvol zal zijn in de praktijk is nu nog niet te beantwoorden. Wellicht dat de auteurs in een volgend boek hun ervaringen kunnen delen als organisaties met het voorstel aan de slag zijn gegaan. Al met al erg de moeite waard om Performance management in een Agile werkomgeving thuis, zeker nu tijdens de corona-crisis, rustig te lezen en te beoordelen welke onderdelen toepasbaar zijn binnen uw organisatie.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Ina Sok omschrijft zichzelf als een ‘een creatieve synergist’. Haar achtergrond in zowel organisatieadvies als de kunsten heeft haar doen inzien dat creativiteit ook in organisaties nodig is. Niet zozeer om de eigen werkplek vol te hangen met eigen kunstwerken, maar juist voor nieuwe en originele inzichten om problemen te tackelen en organisaties verder te brengen. In haar boek 30 Creatieve workouts geeft ze individuen, teams en organisaties oefeningen om deze benodigde creativiteit te ontwikkelen. Een geruststellende gedachte die we van de auteur meekrijgen is dat creativiteit vele uitingsvormen kent en zeker te trainen is.

De indeling van het boek is als volgt: grofweg de helft van het boek (kleine schatting, het boek kent geen bladzijdenummers) is besteed aan inzichten, theoretische kaders en ervaringen van de auteur. Deze korte stukjes lezen makkelijk weg. Voorzien van quotes van bekende en minder bekende artiesten en kunstenaars biedt het een mooi begrip van verschillende onderdelen van het creatieve proces.
De tweede helft van het boek richt zich vervolgens op de 30 workouts die de titel ons belooft. Het gaat hierbij van de individuele vormen naar teamvormen en uiteindelijke de organisatiebrede vormen. Het is echter niet nodig om vooraan te beginnen, je kunt doorbladeren naar de workouts die je interesseren en daarna met die workout direct aan de slag.

Het is niet mogelijk om in deze review alle workouts de revue te laten passeren. Van elke categorie licht ik er een uit die ikzelf zou willen toepassen. Hierbij opgemerkt: soms was het lastig kiezen.

Individuele workout 10: Improviseren
Eén dag zeg je op alle vragen ja. Echt ja, dus geen ja-maar. Ervaar bewust wat er gebeurt en kijk waar deze mindset je naar toe leidt. Hoe reageren mensen? En hoe reageer je zelf? De kracht bij deze oefening zit in de herhaling, dus herhaal deze workout periodiek en bekijk of dingen anders, makkelijker of moeilijker gaan? En natuurlijk of je nieuwe ideeën en inspiratie opdoet door deze oefening.

Team workout 8: Transformeren
Het idee hierbij is om teamleden bewust een periode (een maand of een sprint) een andere rol aan te laten nemen binnen het team dan ze normaal hebben. Als je bijvoorbeeld altijd als eerste reageert, wacht je nu wat langer af of juist het tegenovergestelde. Iedereen houdt bij wat de persoonlijke ervaringen zijn en hoe de omgeving reageerde. Vervolgens wordt in een aparte bijeenkomst door het team gereflecteerd op de afgelopen periode. Wat hebben mensen geleerd en op welke wijze kunnen zij elkaar binnen het team ondersteunen met de opgedane inzichten?

Organisatie workout 8: Contrasteren
Deze workout richt zich op het identificeren van essentiële onderdelen voor organisatieveranderingen. Je start met een gemixte groep deelnemers die een goede doorsnede vormt van de organisatie. Deze groep maakt met losse woorden en kreten op een canvas een inventarisatie van de benodigde onderdelen voor de gewenste verandering. De verhouding tussen positieve en negatieve onderdelen en de oorzaken hiervan kunnen uitgediept worden. Deze inzichten vormen de basis voor een nieuwe compositie waarin de positieve punten de boventoon voeren zonder dat elementen verloren gaan. In stap drie worden connecties gelegd tussen de positieve en negatieve elementen en wordt bekeken op welke wijze de organisatieverandering bereikt kan worden. Ten slotte wordt minimaal één nieuw inzicht concreet uitgewerkt naar acties.

Conclusie

Voor wie bekend is met het boek Liberating Structures is er goed nieuws; er is nauwelijks overlap met dit werk. 30 Creatieve workouts is een prima uitbreiding voor je repertoire van werkvormen. Zeker omdat er ruimte is gemaakt voor individuele werkvormen en niet alles gericht is op groepen of teams.

Fouten maken mag. Dat komt meermaals terug in 30 creatieve workouts en is onderdeel van het creatieve proces. In het boek zelf is ook een fout geslopen, tenminste zo laat een inlegsheet weten. Er is echter besloten om de druk niet te laten vernietigen maar handmatig de fout te herstellen. Een lovenswaardig initiatief en zeer klimaatvriendelijk. Het herstel is keurig gedaan, zelf ben ik er niet achter gekomen waar de fout zat. Wellicht jij wel?

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Voor meer informatie over de auteur zie: creativityincompany.nl.

Cheers,
– Sjors Meekels

Agile/Scrum and Continuous Delivery

Agile/Scrum focuses on the ability of teams and organizations to absorb the array of changes that happen while making software. The setup of the Scrum rituals ensures that transparency is present at all times, for the team itself but also for the stakeholders. When functioning well, the Product Owner helps the stakeholders in guiding the product development in the right direction. Adapting change and changing course now and then is part of the normal process. The main aim of Scrum is to deliver as much value as possible working in a sustainable pace [1]. The framework says nothing about how this should be achieved from a technical perspective. Not what tools to use or what platform is appropriate, nor does it mention test automation, infra structure as code or deployment pipelines.

The power of short cycled feedback (highly valued within Scrum) is strengthened enormously when teams can focus on developing the properties of the systems (functional and non-functional) instead of spending time on manual tasks. Manual tasks can include everything from testing code by hand, setting up new environments or executing tedious deployment scripts following a step by step manual. This is the area where Continuous Delivery steps in. Continuous Delivery empowers teams by giving them the tools and methods to automate their process as much as possible and minimize manual labor. Not only does it save time, it also decreases the error rate by eliminating the human factor [2].

Simply stated: by combining Scrum and Continuous Delivery, teams can create a new feature, run automated tests and deploy the new software to environments where validation by business can be done. All covered by a framework supporting transparency, inspection and empiricism at all times.

Continuous Delivery and DevOps

Continuous Delivery is largely based on the technology that enables teams to automate as much of the development process as possible. Traditionally, a handover moment between development and operations was in place when software was finished and accepted. The deployment to the production environment and the responsibility for the quality of service once running was in hands of the operation teams. In DevOps, teams become responsible for the entire chain all the way to production [3]. Technically, the tools and actual deployment on production are not so different than those used on other stages. Having the explicit mandates and authorizations marks the distinction, these include access to production monitoring and logging information.

Often the biggest chasm to cross in a journey towards DevOps is organizing the rights and responsibilities for newly formed DevOps-teams (see “DevOps understanding the Evolution” to have a brief chronological overview of DevOps). This becomes more evident when discussing quality of service. Who is allowed to see how a system is running, how to deal with production data and what information has been logged? Especially large organizations with a history of separated departments and teams for operations and development are discussion prone. If you find yourself in a mandate-discussion going in circles, what can help is the next simple question: Who would be responsible if we only had one team? Clearly, it is only logical that this one team should be in the lead. Barricades often dissolve after discussing why it should be different just because you have multiple teams.

A well-aged mantra reads as follows: ‘if you want to have a stable environment, don’t change it’. This contrasts with the nowadays popular one: ‘fail fast and fail often’. The technology now present – based on Continuous Delivery – enables teams to develop and deploy new software with no or hardly any downtime. Combined with DevOps, teams can take ownership for the entire life cycle of the product. Responsibility only ends when a system is decommissioned.

DevOps and Agile/Scrum

While DevOps ensures that teams are able to take technical and organizational ownership for the quality of service of the products they develop and maintain, the term says nothing about the team dynamics that should be in place to support this responsibility. The other way around is also true, Agile/Scrum makes no mention of different environments or how to address major production incidents. Of course, it is possible to have for example Scrum without DevOps. However, this means you will have a delay in your feedback loop and miss valuable information about the production environment. More importantly, teams that have production responsibility have more insights in the behavior – intended or not – of their system.

Naturally, DevOps requires some additional agreements in a team’s Scrum process. How is monitoring approached (not technical but process wise) or how much time can be spent on improving ‘the run’. By discussing the time spend on monitoring and analyzing the software in production, a more in-depth analysis can be made based on value. These Lean influences from DevOps provide the structure to improve operational excellence as well. For example: ownership and code-logging hygiene go quickly hand in hand when a team has to fix its own production problems. Decision making and prioritization by Product Owners is more coherent in DevOps. The total costs of running a system become more transparent and are influenced more directly by the Product Owner’s team. See “Product Owners in DevOps” to read more on backlog prioritization in DevOps.

Combining the flow and value stream ideas from DevOps with the sustainable pace and delivery of Done increments from Scrum is powerful. Feedback from clients or the business on the latest software can continuously be weighted up against other aspects of running the product.

Conclusion

While it is theoretically possible for teams to use exactly one of the ‘buzz terms’ without the others, it is not common. What I usually see in organizations is a mix of all three. That makes sense, the terms and related concepts focus on team responsibility and share the desire for short feedback loops, build-in quality and transparency towards stakeholders and teams internally. They re-enforce each other and offer opportunities to improve specific parts of an organization’s way of working. That is one of the reasons why you should be able to describe in a concise way what you mean when discussing improvements to your development process.

Cheers,
– Sjors Meekels

Disclaimer: the description above is not complete and it surely is not one hundred percent perfect. It is not meant to be. It is a personal simplification to address the consistency of a set of popular tech-buzz words.

References & recommended reading:

[1] SCRUM – a Smart Travel Companion, Gunther Verheyen
[2] Continuous Delivery, Jez Humble & David Farley
[3] The DevOps Handbook, Gene Kim, Jez Humble i.a.
[4] DevOps: understanding the Evolution: https://www.agitma.nl/devops-understanding-the-evolution
[5] Product Owners in DevOps: https://www.agitma.nl/product-owners-in-devops-what-dominates-your-backlog-urgent-or-important-matters
[6] https://www.linkedin.com/pulse/differences-between-continuous-integration-delivery-versteijnen Pieter Versteijnen (last checked 19-11-2019)

Jan Heunks laat zijn ervaring met Lean en Lean IT terugkomen in zijn boek ‘DevOps in beweging’. Alleen Lean noemen naast natuurlijk DevOps doet het boek te kort. Het is een overzichtswerk waarbij een veelheid aan zowel technische- als managementontwikkelingen beschouwd door een DevOps-bril.

‘DevOps in beweging’ is opgebouwd uit drie delen, met per deel twee hoofdstukken. Ieder hoofdstuk wordt afgesloten met een korte conclusie en de delen als geheel met een aparte samenvatting. Het boek heeft een soft cover en pagina grootte A4, dit maakt het wellicht wat minder geschikt om zo mee te nemen maar wel prettig leesbaar. Het is jammer dat niet alle figuren even scherp in het boek zijn opgenomen, storend is dit echter niet.

In Deel I legt de auteur uit wat de toegevoegde waarde is van DevOps. Onderdeel hiervan is een korte geschiedenis en de belangrijkste invloeden die geleid hebben tot de huidige denkbeelden omtrent DevOps. Natuurlijk komen de invloeden van Agile software development en Continuous Delivery aan bod. Bij het uitdiepen van de waarde voor de keten en organisatie legt hij de verbanden met Lean (IT & Startup) en beheerprocessen zoals ITIL.

Deel II betreft het theoretische kader van DevOps. De auteur borduurt net als in Deel I voort op Lean & Agile en op bekende werken als The DevOps handbook, The Phoenix Project en Continuous Delivery. De hoofdstukken 3 en 4 vormen zo een stevig gecombineerd kader van relevante management aspecten (o.a. Theory of Constraints, IT-servicemanagement) en technologische principes (o.a. Infra structure as code, Simian Army). Sprekend voor de huidige uitdagingen bij het uitleggen en bediscussiëren van DevOps is het ontbreken van één heldere & geaccepteerde definitie. Paragraaf 4.2 illustreert dit door de gegeven voorbeelden en vergelijking.

Het laatste deel richt zich op de integratie van DevOps binnen organisaties. Helder is dat investeringen gedaan in bestaande processen en structuren vooral niet direct overboord gegooid moeten worden. Nee, DevOps kan prima een logisch opvolgende evolutie zijn van de huidige organisatiestructuur. Wat niet ontbreekt bij het beschrijven van de aanpak binnen organisaties is een DevOps niveau-indeling voor teams (hfd 6). Dergelijke formats, vaak maturity models genoemd, zijn al gemeengoed bij veel organisaties die certificering hebben of gestructureerd verbeteringen willen doorvoeren.

Het is indrukwekkend om te zien hoeveel bestaande vakliteratuur, modellen en theorieën zijn meegenomen in de beschrijving van DevOps. Het geeft hiermee lezers aanknopingspunten vanuit bekende referentiekaders en achtergronden. Dit helpt bij het vaststellen wat DevOps toevoegt aan de eigen organisatie en waar huidige knelpunten kunnen zitten. De veelheid kan echter ook overweldigend zijn, zeker wanneer je alle figuren en tabellen wilt begrijpen of onderling verbinden. Met name de verschillen tussen de theorieën en figuren kunnen het lastig maken, termen worden anders geïnterpreteerd of uitgelegd en het is onmogelijk om alles in één overkoepelend raamwerk te plaatsen. Dat laatste is echter ook geen doel van de schrijver.

Conclusie

Al met al, is het een stevig boekwerk wat een goed beeld neerzet van DevOps. Het is volledig Nederlands, op het Engelse vakjargon na natuurlijk, wat voor sommige lezers de drempel net zal verlagen. Een goede combinatie van management aspecten en technologische invloeden maken dit boek tot een prima startpunt voor het uitdiepen van DevOps voor de eigen organisatie.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Het is goed mogelijk dat de naam Christine Karman bij menigeen een belletje doet rinkelen. In de jaren negentig en zero’s maakte ze nationale bekendheid met de door haar opgerichte bedrijven Tryllian, gespecialiseerd in mobile agents en Izecom, gericht op secure email. Helaas voor Karman waren beide bedrijven geen lang leven geschonken. Met haar boek Agile zoals het bedoeld is is zij terug aan het IT-front en deelt ze haar ervaringen en kijk op het Agile werken.

Het handzame boekje is opgedeeld in 11 korte hoofstukken met een zestal intermezzo’s er tussendoor geplaatst. De intermezzo’s beschrijven persoonlijke ervaringen van de auteur tijdens opdrachten bij klanten of in haar eigen bedrijven. Met 125 bladzijden lees je dit boek in één avond rustig uit. Ieder hoofdstuk richt zich voornamelijk op één concreet onderwerp. Het boek start met de geschiedenis van Agile, het ontstaan van Scrum en zoomt in de hoofdstukken daaropvolgend steeds meer in op het Agile werken zelf en wat hiervoor nodig is.

In veel organisaties lijkt de implementatie van Scrum meer een doel te zijn geworden dan een middel om slagvaardiger software te kunnen realiseren. Hierin heeft de auteur zeker een punt. Niet alle projecten of software ontwikkeltrajecten zijn hetzelfde en niet alle Agile frameworks zijn even passend. Een van de pijnpunten die Karman meerdere keren benoemt, is het gewillig volgen van opgelegde patronen (bijvoorbeeld de Scrum rituelen, kortom: de vergaderingen) zonder de achterliggende waarde hiervan te benutten. De vraagt die rijst: ligt dit aan de organisatie, de implementatie van Scrum of aan Scrum zelf? Karman lijkt de oorzaak voornamelijk bij Scrum zelf te plaatsen.

Op de vier principes die Karman noemt voor effectief Agile werken, is niet veel af te dingen. Het betreft: (i) stop met vergaderen, (ii) werk met multidisciplinaire teams, (iii) kies voor continuous delivery en (iv) maak het team de baas. Echter, in de praktijk zijn deze principes niet eenvoudig te realiseren. Dit wordt in het boek alleen niet nader uitgediept. Het hoofdstuk dat mij het meest aansprak, was hoofdstuk 8. Hierin beschrijft de auteur een verfrissend voorbeeld van een projectstart – efficiënt en met het team direct in de lead. Begin je project met een eendaagse startup hackathon! Alle betrokkenen van het project doen mee en aan het einde van de dag wordt het resultaat gedeeld en besproken. Een ludieke werkvorm om iedereen te laten kennismaken en de eerste ideeën uit te wisselen. Bovendien geeft het een enorme energieboost voor de deelnemers.

Mijn persoonlijke kanttekening bij de stellingen en voorbeelden is de ervaring dat in praktijk niet alles vanzelf goed gaat als teams en mensen worden vrijgelaten. Met name in grote organisaties is niet iedereen beschikbaar, niet iedereen even goed (of zelfs goed genoeg) en werkt niet iedereen goed samen. Bovendien, hoe groter teams of projecten worden hoe meer behoefte er is aan een helder minimaal proces dat voor iedereen bekend is. Dit doet niets af aan het willen streven naar een zo simpel mogelijk ontwikkelproces zoals de auteur voor ogen heeft. Echter in mijn ervaring kom je met alleen ‘ongeplande koffie overlegjes’ niet tot het gewenste resultaat. Sturing, coaching en soms zelfs vergaderen, is noodzakelijk.

Conclusie

Door de stevige uitspraken die de auteur doet is Agile zoals het bedoeld is een prikkelend boek. Met name ‘Scrum puristen’ zullen het niet altijd eens zijn met de uitspraken. Toch kan juist voor deze groep het boek stimulerend zijn omdat je wordt gedwongen na te gaan waarom je het niet eens bent met de auteur. Is dit afhankelijk van de context of ben je het fundamenteel oneens? De auteur dwingt je om je eigen Agile fundament opnieuw kritisch te beschouwen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Het is niet zomaar een kwartet auteurs wat dit boek geschreven heeft. Het betreft de coauteur van onder het Lean standaardwerk: “The Machine That Changed the World”, een ervaren leiderschapscoach met meerdere Lean boeken op zijn naam en een tweetal zeer ervaren bestuurders van grote bedrijven. De vier combineren hun inzichten in dit boek en beschrijven de praktijk op basis van hun ervaringen. “De Lean Strategie’ is hierdoor geschikt voor iedereen die Lean wil inzetten om de eigen organisatie duurzaam te verbeteren door te zien, te leren en te innoveren.
Inhoudsopgave

Inleiding
Hfd 1. Dingen beter maken
Hfd 2. Anders denken
Hfd 3. Leiden van onderaf
Hfd 4. Een kader voor leren
Hfd 5. Organiseren voor leren
Hfd 6. Een nieuwe formule voor groei
Hfd 7. Herbruikbaar leren om doorlopend meer waarde te creëren
Hfd 8. Versneld vooruitgang boeken
Hfd 9. Van Kaizen naar innovatie
Hfd 10. Een mentale omschakeling
Conclusie

De auteurs nemen de lezer in 10 hoofdstukken mee in de inzichten en ervaringen in het bijsturen van grote organisaties. Een van de belangrijkste leerpunten die zij benadrukken is de kracht van de Gemba. Maar al te vaak bestaan in de top van bedrijven diepgewortelde misvattingen over de uitvoering van het werk. Wil je als bestuurder weten wat er fout gaat in je bedrijf? Ga dan echt kijken. Echt kijken wil zeggen dat je de tijd neemt om op de werkvloer te ervaren welke uitdagingen zich in de operatie voordoen. Alleen zo kom je los van financiële rapportages of dashboards waarmee bedrijven vaak op afstand worden gerund.

Er zijn diverse voorbeelden opgenomen waarin bestuurders verrast werden door de wijze waarop organisaties zichzelf onbedoeld tegenwerkten. Illustratief zijn de verschillende afdelingen die zo zijn gecompartimenteerd dat men elkaars problemen niet kent en de organisatie als geheel niet in staat is het fundamentele onderliggende probleem op te lossen. Juist door de onderliggende problemen zichtbaar te maken voor iedereen, lukt het om de root causes te zien. Dit doorbreekt een reactie die we vaak in organisaties zien; het compenseren van datgene wat fout gaat in de één afdeling in plaats van het structureel oplossen van het probleem voor de gehele organisatie.

De opgedane inzichten van de vier auteurs onderschrijven de noodzaak om de wijze van leiding geven te herzien. In plaats van klassiek top-down te leiden moet er volgens hen meer worden geleid van onderaf. De kennis en kunde van de mensen op de werkvloer moet worden ingezet om de fundamentele problemen van de organisatie aan te pakken. Vaak begint dit met kleine – ogenschijnlijk – triviale verbeteringen. Onderschat hierbij niet dat ook verbeteren op zich een leercurve heeft. Mensen en organisaties moeten leren verbeteren; ze moeten leren kijken naar de situaties om zich heen en inschatten hoe deze kunnen worden verbeterd. Het is de taak van het management om de omstandigheden te creëren en te cultiveren waarin leren mag, kan en zelfs moet. Bij deze cultivatie spelen de lean tools een belangrijke rol. Deze worden niet ingezet om ad-hoc problemen te tackelen. Nee, ze worden zo ingezet (en in het boek beschreven) dat ze helpen de organisatie continu te verbeteren. Kleine verbeterexperimenten leiden op die manier tot innovaties (toegelicht in hoofdstuk 9).

Vanzelfsprekend wordt het succes van de toepassing van Lean niet alleen gemeten in de wijze van leidinggeven of verbetertrajecten. Uiteindelijk moeten aanpassingen ook bij Lean resulteren in strategische voordelen ten opzichte van concurrenten. Kosten, klanttevredenheid en andere harde financiële graadmeters blijven meewegen. Gelukkig sluiten de inzichten van de auteurs en Lean aan bij de huidige tijdsgeest waarin onderwerpen zoals duurzaamheid & medewerker tevredenheid steeds belangrijkere worden, ook in de boardroom.

Conclusie

Waarom dit boek lezen? Vanuit mijn eigen Agile achtergrond ben ik Lean gaan waarderen op een aantal punten die goed in dit boek aan bod komen. Het daadwerkelijk borgen van verbeteringen zit diep verankerd in Lean en het inzetten van Visueel Management wordt veel breder ingezet dan ‘slechts’ de Scrum borden die veel Agile teams hanteren. De inzichten in dit boek vormen een mooie verbreding ten opzichte van organisaties die voornamelijk werken vanuit een Agile mindset.
Lees dit boek niet omdat je snel bij wilt zijn met het inzetten van de Lean tools of het opfrissen van je lean woordenschat. Lees dit boek vooral als je wilt nadenken over een andere wijze waarop je strategisch je bedrijf wilt veranderen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels