Author Archives: Sjors Meekels

Leading Image

Scaling agile in organisaties – Henny Portman

Verdwaald in het land van Agile frameworks, practices en scaling opties? In Scaling agile in organisaties neemt Henny Portman de lezer bij de hand en leidt hem langs de vele smaken en mogelijkheden die het Agile landschap inmiddels rijk is. Voor iedereen die zijn horizon wil verbreden of een referentie zoekt voor zijn of haar organisatie, is dit boek een prima startpunt.

Henny Portman is een ervaren IT-professional met een lange staat van dienst in projectmanagement rollen en de laatste jaren tevens werkzaam op het snijvlak met Agile werkwijzen. Hij heeft meerdere boeken en artikelen op zijn naam staan en is daarnaast als trainer werkzaam. In zijn recente boek Scaling agile in organisaties geeft hij een overzicht van de bekende en minder bekende Agile scaling werkwijzen.

Het boek is opgebouwd uit drie overzichtelijk delen, ieder met een duidelijk thema. De eerste drie inhoudelijke hoofdstukken beslaan achtereenvolgens Scrum, Kanban en Lean. Hierop volgt een hoofdstuk waarin de auteur zijn visie geeft op de veranderde rol van projectmanagement.

Het zwaartepunt van het boek ligt in de hoofdstukken 6 t/m 14 en beschrijft de inhoud van de verschillende Agile scaling frameworks. De opzet van het framework is hierin leidend en de auteur neemt de lezer mee in de belangrijkste kenmerken en toepassingen. De usual suspects als SAFe, Nexus, LeSS en Spotify zijn present. Tevens is ruimte genomen om een aantal minder bekende frameworks beknopt de revue te laten passeren.

Het derde en laatste deel omvat drie hoofdstukken en start met een gecomprimeerd overzicht van de meestgebruikte frameworks aan de hand van de kenmerkentabel. Daarnaast geeft Portman in dit deel een handreiking aan organisaties voor het selecteren en toepassen van een dergelijk framework.

Deel I: Eén agile team maakt de gehele organisatie nog niet wendbaar
1. Inleiding
2. Scrum in een notendop
3. Kanban in vogelvlucht
4. De essentie van lean
5. Invloed van agile op projectmanagement

Deel II: Verschillende frameworks voor scaling
6. Overzicht
7. SAFe
8. Nexus
9. Scrum at Scale
10. LeSS
11. Spotify
12. PRINCE2 Agile
13. AgilePM
14. Overige frameworks

Deel III: Selecteren en implementeren
15. De verschillende methodes naast elkaar
16. Transitie naar wendbaarheid
17. Epiloog

Het schrijven van een gestructureerd overzichtswerk over de verschillende Agile scalings methoden is absoluut een uitdaging. De auteur is erin geslaagd een aardig overzicht te creëren en plaats te geven aan grote en kleinere spelers. Naast de frameworks benoemt Portman ook diverse practices die veelvuldig worden gebruikt, zoals story maps, agile release trains en open spaces. De opzet van het boek leent zich prima voor cherry picking op onderwerpen waar je snel wat meer informatie over wilt. Tip: als je bekend bent met Scrum/Kanban/Lean, sla dan gerust de eerste drie inhoudelijke hoofdstukken over.

Naast het agile gedachtegoed hinkt het boek echter ook op een andere gedachte. Namelijk die van de projectmanagers en hun veranderende rol binnen organisaties. Gezien de achtergrond van de schrijver wellicht niet verrassend, maar binnen dit boek niet helemaal op zijn plaats.

Zoals zo vaak binnen de Agilewereld is er geen goed of fout voor het inzetten van een bepaald framework maar geldt ‘It depends’. Afhankelijk van de organisatie, de omstandigheden van de markt, de tooling die reeds beschikbaar is en/of het budget, is de keuze voor de een logischer dan de keuze voor de ander. Ook de inzet an sich is niet allesbepalend. Ieder framework moet worden getuned en aangevuld met practices die passen bij een specifieke situatie.

Conclusie

Scaling agile in organisaties is een nuttig startpunt om je een beeld te vormen van de materie en een gevoel te krijgen bij de verschillende frameworks en de belangrijkste kenmerken en termen daarvan. Vanwege het karakter van het boek zal de lezer zijn verdere verdiepingsslag zelf moeten maken in andere (online) literatuur.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op hwpconsulting.nl.

Filled Under: agile,book review Posted on: 16 January 2018

Leading Image

Retrospectives: tool for distributed retrospectives

Little gem for distributed retrospectives!
In recent years, I have worked with distributed teams occasionally. In an early team an eager colleague, Stefan Kemp, created an interesting responsive web application to support retrospectives in this team setup. That is already 5 years ago. Up until this week I have been using his app for different customers and teams. Let me walk you through it and share my enthusiasm.

Step 1: Getting organized
As a first-timer you create your account and you can register a new team straight away, go here: retrospective.rhea.infosupport.net. Once you are in, you can invite your fellow team members via email. Then you can plan your next retro and instruct everyone that the retro app is going to be used – and more importantly – is already waiting for the first items! There are three types of input awaiting: positive items, improvement topics and flowers to thank team members or other involved teams or persons.

Step 2: The retro
Usually the Scrum Master drives the retro, but in theory anyone can guide the team through the session. It works best if you have shared audio and a shared screen. In that case, everyone can see what is happening on the same screen . Depending on your organization’s tool-setup these can be facilitated by different technical solutions (e.g.: Skype, Polycom, Communicator or Hangout).

Before you start it is good to check if everyone was able to provide the input before the session. If not, you can take a couple of minutes to do so. Another approach would be to let people do it on the spot when it is their turn. When started, one person at a time explains his or her inputs and places these onto the shared canvas. In case people have prepared the same topics, these can be grouped together. If any item is no longer valid it can be deleted. After everyone has finished, it is time to vote and give the last sprint a personal rating. The voting and rating can be done on the screen or by personal device (tablet, phone or pc). For the mobile devices an easy access a QR-code is presented so everyone can get to the mobile version available in an instant.

The voting and rating result in an ordered list of improvement topics to discuss. Each topic can be given concrete actions and remarks. The actions can have a responsible team member assigned to it, or the team as a whole.

Step 3: Wrap up
Once you have discussed enough topics, or the time is up, you can finish the retro. The Scrum Master can send everyone the outcomes of the retro, so actions can be taken into the next sprint or picked up immediately. In the next retro you can start by looking back at the open action items and check what the results are.

Conclusion

The supported flow and functionality is pretty much that of a default retro with everyone available in the same room. The app itself is very easy to understand, usually after one first retro everyone is fully up to speed to use it to its maximum the next time. Even if you don’t have a distributed team the tool can be used. Either as the default modus operandi or as a change of retro scenery. Thanks Stefan!

Top features include:
• A very swift set up for your team, including invitations
• Adding your personal input throughout the sprint
• Easy format during the retro, including grouping and voting to reduce the numbers of topics
• Emails to remind your team of upcoming retro’s and the outcomes of them
• Some nice charts and trends related to team characteristics

Filled Under: agile,scrum Posted on: 9 January 2018

Leading Image

Lean: van hype naar verbetercultuur

Hoe bereik je meer met minder en hoe krijgt de burger weer een centrale plaats bij de uitvoer van het overheidswerk? In Lean: van hype naar verbetercultuur bieden de vier auteurs duidelijke handvatten voor het creëren van een verbetercultuur specifiek gericht op professionals in de publieke sector.

De vier auteurs, Daniel Niezink, Erik Ruijters, Manon Diepenmaat en Paul van Tiel, beschikken over een jarenlange ervaring met het implementeren, coachen en begeleiden van organisaties in het lean werken en denken. In dit gezamenlijke werk wordt hun ervaring gebundeld en maken zij lean praktisch toepasbaar. Wat dit boek speciaal maakt is de focus op de kenmerken en aandachtspunten die de publieke sector eigen is.

De opbouw van het boek is logisch. In de hoofdstukken 1 & 2 wordt gestart met een uitleg van lean, een summiere geschiedenis en de belangrijkste onderdelen. Dit laatste gebeurt onder andere aan de hand van het 4p model van Toyota. In het volgende hoofdstuk worden de kenmerken van de publieke sector toegelicht en bespreken de auteurs tot welke uitdagingen dit leidt bij de inzet van lean.

Inleiding, Leeswijzer en dankwoord
1. Over lean werken
2. Lean filosofie
3. Context van de publieke sector
4. Lean transformatie
5. Instrumenten en technieken
6. Lean transformatiescan
7. Tips voor een lean transformatie

Naast de theorie- en praktijkvoorbeelden introduceren de auteurs een eigen transformatiemodel in hoofdstuk 4. Het doel van dit model is het bieden van handvatten aan organisaties om hun eigen route te bepalen naar het bereiken van de verbetercultuur. Het bestaat uit zeven bouwblokken die de route mogelijk maken en ondersteunen. Enerzijds beschrijven deze de aanpak en proces; hoe en met wie start je een transformatie? Anderzijds zijn de bouwblokken gericht op gedrag en houding bijvoorbeeld op het acteren van leidinggevenden in bouwsteen 3 ‘Inspirerend en dienend leiderschap’.

Natuurlijk hebben de auteurs naast de basistheorie en het eigen model ook aandacht voor de veelal toegepaste instrumenten en technieken binnen Lean. Zo zijn de probleemanalyse, A3 en waardestroomanalyse (value stream mapping) onderwerpen die helder worden uitgelegd in hoofdstuk 5.

Ook de transformatiescan, beschreven in hoofdstuk 6, is een nuttig instrument. Alhoewel geen onderdeel uit het standaard lean assortiment, biedt het een mooie eyeopener voor organisaties die willen starten – of gestart zijn – met een lean transformatie. De scan start met het letterlijk groot ophangen van de bouwblokken en bijbehorende stellingen. Door middel van het stickeren met rood en groen op de goede en minder goede onderdelen wordt voor iedereen snel inzichtelijk wat de grootste aandachtsgebieden binnen de organisatie zijn. Alleen al het visueel maken van een dergelijk startpunt is op zichzelf een mooi voorbeeld van visual-management.

Conclusie

Het boek slaat een mooie brug tussen de theoretische kaders en het praktische ritme van het werken in het publieke domein. Met name door de beknopte praktijkcases komen de uitdagingen en concrete oplossingen naar voren. Leidinggevenden en professionals zullen hier veel herkenningspunten zien en een goede indruk te krijgen van de mogelijkheden en verschillende aanpakken.

Niet alleen voor mensen werkzaam in de publieke sector is Lean: van hype naar verbetercultuur interessant. Het transformatiemodel, de gebundelde theorie en de technieken zijn binnen alle sectoren toepasbaar. Het is een beknopt boek en leent zich prima voor het opdoen van inspiratie in het weekend.

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

Filled Under: book review,lean Posted on: 22 December 2017

Leading Image

Retrospectives: communication & personalities

Some time ago, I experimented with some team retros to start discussion and exploration on our communication and the team’s personalities. After a few tries I came up with this small format. It helped me and my teams getting a swift feeling on each other’s do’s & don’ts and to create a general team vibe. You can use this format either at a new team formation or whenever you are looking for an alternative retro.

Invite & preparation
This format starts with an explicit invite and personal preparation. Thinking on your individual story and using the results to formulate your ideas before the session gives people a head start and saves time during the session. In case new topics do come up, you can always still on-board them on the fly. For the Scrum Master this phase means collecting and preparing all the inputs and making sure they are available during the session.

Retro_invite

The actual retro
All team members do their personal pitch with the help of their preparation and a personal page provided by the Scrum Master. Sometimes teams are a bit shy to start. So it can be a good idea as a facilitator to start by setting the example and presenting your own slide. Usually other team members will come up with questions and then the session is kick started easily.

Retro Individual Slide

Team overview
After everybody has had his turn, you can present the team overview. The more diverse the better. A picture can tell a story but the value for me is in the interaction and flow that is created during the retro. Besides, most teams like to see their team picture! Based on the kind of tests you have selected for your team, you can get different options for visualization of course. There is no need for expensive material or assessment centers. Start with the options that are easy to use and for free (like the ones I have used).

Team Slide Personalities
Note: in the end it does not really matter which tests you use. This approach as such helps people thinking and talking about themselves. Although the graphs merely act as conversation starters, they do tell you a thing or two about the team……

Have fun!

Filled Under: agile,scrum Posted on: 11 December 2017

Leading Image

Alles draait om verandering – Edwin Tuin

Redenen voor organisatieveranderingen zijn er genoeg en de gevraagde verandersnelheid moet verder omhoog. Hoe krijg je dit binnen je eigen organisatie voor elkaar? In het boek Alles draait om verandering beschrijft Edwin Tuin zijn model om organisaties te helpen veranderen. Zijn veranderwiel stelt organisaties in staat om met nieuwe ogen naar verandermechanismen te kijken.

Edwin Tuin heeft zijn jarenlange ervaringen in veranderprocessen gebruikt om een eigen kijk op veranderen te creëren. Vormgegeven in zijn veranderwiel, biedt hij managers een concreet verfrissend mechanisme om veranderprocessen te borgen in bestaande organisaties. Alles draait om verandering bouwt verder op bestaande inzichten en legt verbanden met stromingen als Lean en Agile.

Hoofdstuk 1 & 2
In de eerste twee hoofdstukken bereidt de auteur de lezer voor op het nut en de noodzaak van organisaties om te veranderen. In een vlot tempo komen maatschappelijke onderwerpen zoals duurzaamheid en vergrijzing voorbij en is het duidelijk waarom organisaties wendbaarder moeten worden. Dit blijkt geen eenvoudige opgave. Bestaande strategieën passen niet meer en de klassieke organisatiemodellen maken plaats voor alternatieve, meer vloeiende, structuren. Alhoewel veranderen niet eenvoudig is, kan iedereen het leren. Het devies van de auteur is om het vooral veel te doen.

Hoofdstuk 3 t/m 6
In de hoofdstukken drie tot en met zes draait het volledig om het model. Tip: blader door naar de start van hoofdstuk 8 voor het schematische overzicht van het volledige veranderwiel. Hiermee vallen de verschillende onderdelen makkelijker om hun plaats. Na een korte algemene introductie start Tuin bij de binnenband. De vier kerndrivers in de binnenband zijn verlangen, vertrouwen, verantwoordelijkheid en vermogen. Alle vier moeten versterkt worden en haken rechtstreeks in op de strategie en cultuur binnen bedrijven. Herkenbaar uit de praktijk; voor veel organisaties zal met name de kerndriver ‘vermogen’ een belangrijk aandachtspunt zijn. Redenen om te veranderen zijn er helder, vertrouwen is aanwezig en de medewerkers willen verantwoordelijkheid nemen. Echter de daadwerkelijke veranderkracht – het vermogen om te veranderen – ontbreekt.

Vanuit de binnenband komen de ideeën – projecten – naar boven die nodig zijn om veranderingen in te zeten. Vervolgens bespreekt de auteur de zogenaamde loops die vanuit de as van regie en roadmap de verbinding vormen tussen de binnen- en de buitenband. Deze loops dienen om de nieuwe ideeën te toetsen en te verbeteren. Passen deze ideeën bij lopende initiatieven en zijn alle voorwaarden aanwezig om tot een succes te komen? Om dit proces handen en voeten te geven is een Verander Assessment Groep nodig die als werkgroep verantwoordelijk is voor de borging en aansluiting van de ideeën op de kerndrivers. Daarnaast schets het boek een Verander Monitor Board die zorgt voor de uitlijning van andere bestaande programma’s of lopende projecten en voldoende managementsupport.

De directe aansluiting van de nieuwe ideeën op de dagelijkse praktijk is voorzien in de buitenband. Hier komen de vraagstukken bij elkaar en wordt helder welke implicaties er voor de organisatie zijn. Het model als geheel heeft een dynamische opzet waardoor een vaste volgordelijkheid geen vereiste is. Zo kan het nuttig zijn om één loop meerdere keren achter elkaar te doorlopen of om een stap terug te zetten naar een vorige loop. De volgordelijkheid zal per organisatie en situatie verschillen. Voor de invoering van het veranderwiel gebruikt de auteur in hoofdstuk zeven een aantal scenario’s waarmee organisaties zich snel kunnen identificeren. Dit zijn bruikbare strategieën om concreet met een invoer aan de slag te gaan.

De auteur hanteert een actieve schrijfstijl waarin zijn gedachten, tips en voorbeelden elkaar snel opvolgen. De rode draad blijft het veranderwiel en de nadere uitleg van het veranderproces in de elkaar opvolgende hoofdstukken. Het is aan de lezer om de inzichten te plaatsen in zijn eigen kader en de meest nuttige en toepasbare hieruit te destilleren. Het is praktisch onmogelijk om het met alle uitspraken van de auteur eens te zijn. Maar dat is ook zeker geen voorwaarde. Juist de stelligheid van enkele uitspraken geven de lezer de kans zich te spiegelen en na te denken over alternatieven en eigen inzichten.

Conclusie

Het boek is toegankelijk geschreven en bevat diverse verwijzingen naar bekende namen uit de literatuur zoals Sinek en Semler. Of je het veranderwiel nu als mechanisme gaat invoeren of het als gedachtenexperiment gebruikt, er zitten genoeg handvatten in om met een frisse blik naar het veranderproces in de eigen organisatie te kijken. Hiermee is Alles draait om verandering een prima praktische start voor iedereen die zijn organisatie wil veranderen of het veranderproces wil veranderen. De quote op de kaft om het boek tevens alomvattend te noemen, is wellicht een stap te ver.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op victalis.nl.

Filled Under: book review,interim management Posted on: 17 September 2017

Leading Image

Visualization helps Agile Teams & Organizations

Transparency is one of the corner stones of great Agile teams and organizations. If that is the case, isn’t it strange that so many teams have little outwards visualizations? Not only teams benefit from visualization, but also management and other stakeholders could gain direct insights from the information presented. In this blog, I will discuss visualization from different perspectives using my own checklist as a starting point (see at the bottom of this blog). At the end, I will share a few pointers to get you started.

The eight examples on my checklist are a nice start. Depending on your team or department characteristics, you can probably add a dozen others. Some at least as important as the ones on the list. However, the true value for me lies in the dialogues and questions that arise from them instead of the – more fundamental – discussion on which items should or should not be on the list.

Team perspective
Let’s start with the team perspective. The first reaction and question that usually pops up is: for whom are we visualizing? Unarguably, it should be for ourselves and our stakeholders. So, if we do it for ourselves, we need to have information radiating that is important and useful for us. In my opinion, all topics on the checklist should matter to any given team. If not, there is a chance something is off in the basic way the team is functioning and/or supported by its organization. Do it, pick one topic and argue that it is not important for a healthy routine of your team.

The second reaction from teams can come from two directions: “we don’t have that information” or “it takes too much time to gather it”. Both arguments are excellent starting points for valuable discussions – during retro’s or just over coffee. Not having the information means that your team is flying in the dark. Either the product or the company’s road map is not clear or perhaps the feedback loop for continuous improvements is not implemented. If collecting these basic team drivers takes too much time, chances are that tooling is not in place or not used correctly. The reactions mentioned in this paragraph are indicators that the Way of Working can be improved.

Management perspective
Let us shift to the managerial perspective. In more Agile oriented organizations this perspective often leads to a different reaction compared to the ones above. “My teams are self-organizing, self-managing or self-supporting, so they decide what is shown and needed.” Wrong! As long as managers are responsible for their performance – either hierarchical or via a more servant-leadership – it is their job to have an interest in these subjects. If not, they’ll have a tough time explaining what added value they have for their teams and thus their organization. For example, how can a team manager not want to see Impediments or improvements made by his or her teams? In addition, teams often need directions and coaching on organizational goals and drivers. Outward visualization helps the process of aligning the organizational goals and the Way of Working of the teams.

In practice, it can be challenging to implement and decide on the most useful visualizations for your teams or department. Remember it is good to try things and ask around who is interested in what information. Or as a manager, discuss with your teams what the goal and improvements are from an organizational point of view. If done right, the information not only benefits the teams, it is also a source of information that could substitute numeral status meetings.

Stakeholder perspective
The third and last perspective is that of the stakeholders. Top priorities for stakeholders usually contain the question: “When is this or that feature finished?” By showing this information crystal clear in the team area, the team provides the stakeholders with direct insight. Moreover, it helps by building confidence and making the team predictable for its environment. Perhaps the expected date example is a bit simplified. How about this one: create a good Story map of the current product (iteration) and put it in a visible place in the area. Make sure you add significant release dates, in case you don’t go to production in every sprint yet. Now, the timeline has its own functional context which makes clear what the stakeholders can expect. For teams, it is good to adjust to the stakeholder’s needs. Thus, especially as a Product Owner you should invest in what the stakeholders would like to see and hear from the team. Also, be confident to use visualization and communication forms you have seen working before.

A few pointers to get started
Responsibility: who’s responsible for visualization? When teams just start, most of the times it is the Scrum Master who begins with Burn down charts and Impediment boards followed by other more Scrum – or process – related information. In my opinion, it should be a Scrum team effort. In other words, everybody – also the Product Owner – is using the team area to show road maps, examples or key metrics. This will stimulate the philosophy that if it is important for the team, we put it up there. Anyone can decide or try to use some new metric or insight. This does not mean that other stakeholders cannot let the team know what they would like to see.

Gemba walks: one practice that provides insights to all stakeholders is doing Gemba walks across multiple team areas. Don’t ask how things are going straight away. Instead, look around and see what the information presented is telling you. I have used this technique also with colleagues visiting other teams. Besides entertaining it is an easy mechanism to share practices and bring teams a little closer. A Gemba walk might be a catalyst for explorations on visualization benefits for teams, managers and stakeholders.

How to show: I did not elaborate on the form in which information is shown. That is on purpose. Depending on the team, tools and context, you’ll get different outcomes. The fact that I am not a great sketch artist results in more print outs for my teams. In companies with big screens available in team areas you can have as much metrics and info on the screen as you would like. In some companies on the other hand, there is a strict clean desk policy and very little information is allowed to radiate from team areas.

Conclusion

The discussions and feedback from teams and stakeholders can be as valuable as the visualizations themselves. So, make sure you are aware of their thoughts and needs before mounting all kinds of information to the walls. Depending on your role you can initiate the dialogue with or within your teams in diverse ways. Use the checklist, the Gemba walk or any another conversion-starter in your team or department to explore the benefits of visualization. I am curious to hear your experiences and/or remarks. The discussion and feedback from teams and stakeholders can be just as valuable as the visualizations themselves. So make sure you have these before you start mounting all kinds of information to the walls, or demanding this as management.

Visualization
Download the one-pager: Visualization helps Teams and Organizations

References

There is a lot of information out there, so I added just a few examples to get you going:
[1] www.infoq.com: Visualize Agile https://www.infoq.com/visualize-big-picture-agile
[2] Ben Linders: Visualizations https://www.benlinders.com/visualization-team-deliver-value/
[3] www.thoughtworks.com: Story-mapping https://www.thoughtworks.com/story-mapping
[4] Toolbox for the Agile Coach – 96 Visualization examples, Jimmy Janlén, 2015
[5] Coaching Agile Teams, Lyssa Adkins, 2010

Filled Under: agile,agile projectmanagement,kanban,scrum Posted on: 1 September 2017

Leading Image

Trends in Business, IT & OT – Barry Derksen

De veranderingen in de technologische sectoren volgen elkaar steeds sneller op. Wil je overzicht houden op de laatste stand van zaken en de belangrijkste ontwikkelingen voor de komende jaren? In de nieuwste uitgave van Trends in Business, IT & OT zet Barry Derksen de IT-trends voor 2017-2018 en hun invloed op de maatschappij op een rij. Het boek is voor alle niveaus in een organisatie interessant, maar heeft de grootste toegevoegde waarde voor managers en bestuurders.

In deze 20ste druk van Trends in Business, IT & OT neemt Barry Derksen de lezer mee in de continue stroom van technologische trends en ontwikkelingen. Niet alleen de techniek wordt beschouwd maar ook management en bedrijfsmatige trends. Na het lezen van deze editie is iedereen op de hoogte van de relevante trends voor nu en het volgende jaar. Hiermee kan de organisatie worden bewapend tegen het disruptieve effect van alle nieuwe mogelijkheden.

Het boek is opgebouwd in drie overzichtelijk gekleurde delen (roze, blauw en geel) die op hun beurt zijn opgedeeld in hoofdstukken.

Deel I: Richten
In sneltreinvaart worden in het eerste hoofdstuk, in het Engels, de belangrijkste internationale trends besproken in de gastbijdrage van Prof Dr. Jerry Luftman. Hierna wordt de scope vernauwd tot Nederland met de voornaamste managementzorgen, gebaseerd op onderzoek van onder andere de auteur. Tevens wordt de ondertitel van het boek – Disruptief SMAACT het best – nader toegelicht. De huidige fase waarin we ons begeven kenmerkt zich door disruptie in de markt van nieuwe bedrijven zoals Airbnb en Uber. Dit alles is mogelijk gemaakt door de snelle ontwikkelingen in techniek. De kwinkslag ‘SMAACT’ verwijst naar Social, Mobile, Analytics, Agile, Cloud & IoT en benoemt de belangrijkste technologische drivers achter de disruptie. Voortbordurend op SMAACT grijpt de auteur terug op ondernemingsregels uit 1999 gericht op opkomende nieuwe economieën. Deze regels sluiten nog verrassend goed aan bij de huidige fase en worden door de auteur toegepast en waar nodig aangepast. Ten slotte wordt beknopt het 4R-en model toegelicht. Dit laatste is nuttig, nu dit model in Hoofdstuk 3 veelvuldig wordt gebruikt bij het plotten van trends.

Deel II: Inrichten
In deze blauwe katernen zijn drie van de vijf hoofdstukken geschreven door gastschrijvers. De rode draad in dit deel is de werkwijze voor bestuurders – bv CIO’s – in het begrijpen van en sturen op trends. Aan de hand van de zogenoemde IT-scan krijgen zij een middel om de voor hun organisatie belangrijke trends te onderscheiden en planmatig in te zetten. Daarnaast is er aandacht voor de beginnende CIO-er, gevolgd door de nummer één prioriteit voor IT-managers in Nederland: Business & IT Alignment en de leerpunten uit een groot aantal (internationale) projecten. Het tweede deel sluit af met een beschrijving van de rol van de Chief Information Security Officer (CISO) en een beknopte uiteenzetting hoe deze rol in de praktijk gebracht wordt.

Deel III: Verrichten (Yellow Pages)
Het grootste deel van het boek, grofweg 100 pagina’s, is besteed aan de uitwerking van de 30 meest relevante trends. Dit derde deel vormt voor de voornamelijk inhoudelijk geïnteresseerden het hoogtepunt van het boek. De auteur verdeelt de trends in drie categorieën:
Business Trends, IT Management trends en Technologie trends. The usual suspects zijn allen aanwezig zoals Bitcoin, IoT, 3d Printing Agile, Security en Machine Learning. Maar ook voor – wellicht minder prominente – is in deze editie plaats: Internet of Me, Volumetic Displays of Connected Home.

Conclusie

Voor degene die snel inzicht willen krijgen in een aantal specifieke technologische ontwikkelingen inclusief verwachtingen, raad ik aan direct te bladeren in de Yellow Pages. De hier besproken interessante onderwerpen zijn prima te begrijpen als je alleen kort het 4R-en model hebt bekeken.

Met het lezen van dit boek krijgt de lezer een goed overzicht van de trends en uitdagingen die IT in Nederland op dit moment bezighouden, of bezig zouden moeten houden. Het is de kunst de relevante onderwerpen eruit te halen en je niet te laten overbluffen door de veelheid aan lijstjes en modellen in met name de hoofdstukken 1 en 2. Verwacht niet dat alle trends tot in detail worden toegelicht, daarvoor leent een overzichtswerk zich niet. De grootste uitdaging is ook zeker niet het lezen van het boek maar het maken van de vertaalslag naar de eigen organisatie en haar veranderende omgeving.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op www.bitti.nl.

Filled Under: book review Posted on: 25 July 2017

Leading Image

Interview with De Baak – Sjors Meekels

Being a manager-freak does not necessarily change while working Agile.

Daily planking to ensure short and concise sessions
I am now in an environment where we need to work with several teams simultaneously. In order to let people interact in another way, among others, I organize boot camps. Working out together; that is an excellent way to get to know each other better. It is team transient and it creates short lines. If you also know people from a different setting, it will make a difference than just passing the office. In addition, I have also seen organizations where they do the daily stand-up in the planking pose. Be sure that it helps keep things short and concise.

Working Agile won’t solve all problems, it does make them very visible though
I have been enthusiastic about working with agile teams and organizations for years. Being part of the IT side of an organization, you know how difficult it is to build things well and, on the other hand, to build the right things. The faster the uncertainties and problems that clutter the process are made clear, the better it is for everyone.
Sometimes you see new management that thinks ‘that’s a great method that will solve a lot of things for us’, they are wrong. Agile does not solve organizational problems. It will help, but the problems themselves are not resolved. The problems are systematically and quickly made visible.

Trust is an important bottleneck in transitions
An important bottleneck in an Agile transition is to keep everything controlled. One of the values of Agile is to make teams responsible and in control. Make them self-organizing to solve problems and do everything needed to become successful. This requires trust from managers and the room to fail. Sometimes this proves to be hard, it is not how we are used to run companies or departments. For all distinct roles we had people, procedures and guidelines. To overcome this, is a major challenge for a lot of organizations.

Don’t envy a Product Owner’s position
The Product Owner is the one who determines what is being build and in which order. He also ensures that stakeholders are involved continuously. It is a crucial role. The Product Owner must act in a field with many different interests, multiple stakeholders and many different priorities.
Classic is the contradiction between developing new customer demands versus upgrades or maintenance of systems. New opportunities then collide with the continuity of the systems.
So, you’ll have to be an excellent Product Owner with a good vision of what is best for the company. ‘Quick wins’ and stability of the system should be considered. That is an unfortunate position! A product owner must act as a small entrepreneur and be daring. In my opinion, this is the most critical role in an Agile environment. The Product Owner is the one controlling flame or fame.

Cross team knowledge sharing: Lunch pitches
Also within an Agile context knowledge sharing will not happen on its own. If a team has gained brilliant insights, as an organization you’ll want other teams to learn from it. At one organization, we actively went shopping at the teams. If you have something you would like to share, please let us know, we will schedule it. We made sure that were no blockers: at lunch time! There are always a few first movers who will stand up: I have something to share. ”

Does Agile impact the way we communicate?
Communication per se? I do not see that would be very different if you work agile. If you were a freak in the old organization, you could be very well be one the agile organization.

About this interview

This interview was originally in Dutch and held for De Baak, in case you’re interested: interview. De Baak is one of Hollands leading firms when it comes to education on topics as management and leadership. More information about De Baak can be found here: www.debaak.nl. Any faults in the translation can only be my mistake…

Filled Under: agile Posted on: 17 June 2017

Leading Image

Lean Basis – Rudy Gort

In zijn boek ‘Lean Basis‘ maakt Rudy Gort de belofte uit de titel waar en beschrijft hij de basis en kernpunten van Lean. Hij richt zich op een brede doelgroep van zowel leidinggevenden als medewerkers met een interesse in Lean.

Na zijn boek “Lean vertaald naar projecten” is Rudy Gort terug met zijn nieuwste boek “Lean Basis”. In dit tweede boek richt hij zich op de basis en kernpunten van Lean. Hiermee is het boek geschikt voor iedereen die zich snel een beeld wil vormen en eerste indruk op wil doen. Laat je echter niet op het verkeerde been zetten door de titel; het volledige spectrum van Lean komt aan de orde.
Het boek heeft een overzichtelijke indeling met een duidelijk kop, romp en staart. In hoofdstuk 1 wordt Lean geïntroduceerd en worden een aantal kernbegrippen bondig toegelicht. Hoofdstuk 2 vormt het zwaartepunt van het boek en in 6 paragrafen neemt Gort zijn lezers mee in alle facetten van het Lean-huis. Vervolgens sluit de auteur in het laatste derde hoofdstuk af met enkele slotconclusies en bevindingen.

Hoofdstuk 1
Om de lezer de juiste handvatten te geven, begint het eerste hoofdstuk de oorsprong van Lean en zijn ontstaan bij Toyota. De waarde en kracht van deze methode hebben geleid tot interesse bij het brede publiek, maar ook tot verwarring over termen en inzichten die vaak slechts gedeeltelijk waar zijn. In de rest van het hoofdstuk legt hij relatie met begrippen als Agile, Six Sigma, Ketenintegratie en gerelateerde methodes als Total Quality Management.

Hoofdstuk 2
Het Lean-huis staat centraal in het tweede hoofdstuk. Aan de hand van Nederlandse en internationale voorbeelden beschrijft Gort de vijf elementen van het metaforische huis:
§1. De ondergrond: purpose
§2. Het dak: waarde
§3. Het fundament: waardestroom
§4. De pijlers: kwaliteit en tijdigheid
§5. De kern: gedrag

De beschrijving van het huis start met de ondergrond waar het geheel op rust. Dit is de purpose. Gort stelt dat dit aangeeft wat de reden van het bestaan is van organisaties. De volgende paragraaf staat in het teken van de waardecreatie voor klanten. Deze waardecreatie vormt het dak binnen de metafoor. De doelstelling binnen Lean om de waardecreatie als belangrijkste taak te zien is voor veel bedrijven een enorme uitdaging. Niet alleen omdat bedrijven gewend zijn te maken en leveren wat ze altijd al deden, maar ook omdat klanten mondiger en veeleisender zijn geworden.
Waar het in de praktijk vaak misgaat is de waardestroom, het fundament van het huis. De stroom van activiteiten die zorgt voor de creatie van de waarde, zoals deze door klanten wordt ervaren en beleefd. Een stabiele flow zorgt voor een constante stroom van werkzaamheden en hieruit voortkomende resultaten. De auteur legt beknopt uit hoe de wachtrijtheorie concrete wetten en inzichten geeft in (in? Of ms voor?) de onderbouwing van het principe. Met name de gehanteerde voorbeelden zullen de lezer daadwerkelijk overtuigen van de kracht die in het fundament schuilt. In de deze paragraaf komen ook de bekende leantools aan bod, zoals visueel management, feedbackmechanisme, en gelijkmatigheid. Tussen het dak en de ondergrond bevinden zich de pijlers kwaliteit en tijdigheid. Zonder deze twee zal het dak nooit kunnen bestaan. De pijlers bevatten onderwerpen als just-in- time (JIT), value stream mapping en kanban.
Uiteindelijk komen alle onderdelen van het huis terug in de meest invloedrijke: het gedrag van de organisatie en haar mensen. Zonder aandacht en respect voor dit onderdeel zal het huis nooit zijn maximale potentie bereiken. Continue verbeteren, aandacht voor mensen en teams vormen belangrijke bouwblokken. Herkenbare managementknelpunten komen voorbij zoals de hoeveelheid tijd die managers hebben voor verbetering ten opzichte ad-hoc werkzaamheden – voor bijvoorbeeld brandjes blussen. De beschrijving van het Lean-huis maakt duidelijk dat de onderdelen onlosmakelijk met elkaar verbonden zijn en een holistisch geheel vormen.

Hoofdstuk 3
In het laatste hoofdstuk komen de grootste voordelen en te behalen resultaten van een Lean implementatie terug. Het zelflerend vermogen, ondersteund door kort cyclisch werken, en innovatie kracht stellen organisaties in staat de concurrentie daadwerkelijk voor te blijven.

Conclusie

De heldere uitleg van de auteur maakt duidelijk hoe organisaties kunnen profiteren van Lean. Niet alleen door het toepassen van de meest bekende onderdelen, maar juist door het echt te doorgronden. Leren, leren en blijven leren in plaats van een eenmalige implementatie van Lean.

Wat het boek tevens interessant maakt, is de hoeveelheid extra informatie die de lezer naast sec Lean ontvangt. Bekende methoden en managementtechnieken worden door het hele boek gekoppeld en bekeken vanuit een Lean perspectief. Dankzij deze verwijzingen en de gecreëerde informatiedichtheid is het boek – naast naslagwerk – een goed startpunt voor verdere verdieping.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op www.leanvertaald.nl.

Filled Under: book review,lean Posted on: 7 May 2017

Leading Image

Product Owners! What is dominant on your Backlog: Urgent or Important matters?

Product Owners have a great responsibility in prioritizing the work on the Backlogs. Their role can hardly be underestimated. How about some support from the past? Decades ago Eisenhower made a quote on important and urgent matters. His idea has transferred into a matrix used to prioritize personal actions. Can Eisenhower’s priority matrix help Product Owners in prioritizing backlog items? I think so. In this post I will combine Eisenhower’s ideas with those of Agile product backlog management, and a little wild life.

Eisenhower’s matrix
In short, Eisenhower’s matrix focuses on four distinctive quadrants created by the two viewpoints – urgency and importance. The goal is to determine someone’s priorities [1][2].

Urgent matters: require immediate attention. If possible you should act on these matters now. Important matters: these relate to long term objectives and need constant focus. When combined this leads to the following overview and actions:

Eisenhower Matrix

Now let’s transpose these quadrants to backlog management in an Agile environment. All work on the Backlog can be qualified according to Eisenhower’s quadrants. But what is the optimum setup for your Sprint Backlog? Is there any? Based on the model, I will discuss a set of situations which are all taken from projects and teams I have worked with over the years. In these situations, teams are working on Product Backlog Items that primarily originate from one of the quadrants. To make teams easily recognizable, they all have a different nickname which sticks out.

 

1. Orange Firefighters, brave and busy
Agile firefighting dog

If your teams are busy working on the urgent important issues or new work of this category is entered each running sprint, it seems like your teams are firefighting. This is only a good thing when a) there is an actual fire and b) – more importantly – they can extinguish the fire. If this pattern is more the rule than the exception, changes are something is not OK. This could relate to your production environment, either the applications, the infra, people handling it, or all. Try to look for the root causes and fix those, via the regular process of course. Instead of focusing on optimizing the fire-hoses and firemen. Although your teams are working on the top priority work items, there are risks and down sights. For example, every Product Backlog item which is refined or taken in the sprint and pushed out by the orange firefighters, has been a waste of time. Moreover, the company’s short term future may get hurt if this situation occurs for too long a time.

PROS: working on top priority items, CONS: waste in preparation time, pressure within teams, ATTENTION: should not persist for long, focus on fixing root causes!

 

2. Blue Coyotes, opportunistic
Agile Coyote

Sometimes teams are working on urgent but not important issues sprint after sprint. These teams are the so-called coyotes. This scenario also raises an interesting question. Are those issues really urgent? If you and your team tend to say no, there should be a dialogue. Re-discuss these issues with your stakeholders and try to balance them out with your company’s important stories. In practice it is more convenient to work on topics that are urgent to our stakeholders now. However, don’t go for convenient, but invest in discussions and long-term goals.

Okay, so are you done when the answer is yes? Well, sorry, no. If this situation is continues for a long period of time, it could be a sign that you are understaffed. Not working on the important issues, could be a serious threat to business continuity on the long term. Perhaps you can consider to appoint a temporary team that can eliminate the ‘pile’ of urgent stuff, which is in the way of working on the important stories. However, one thing should be in place before you scale up: a clear vision on what is actually important. This may sound like a no-brainer, but more than a few Product Owners are struggling in identifying what is really contributing to the company’s future.

PROS: satisfying to stakeholders, CONS: not working on the long run, ATTENTION: are backlog items really that urgent or is there too much stuff in the way?

 

3. Green Tortoises, steady but a bit boring
Agile Tortoise

The third scenario reflects the mindset of the tortoise. Namely, where the majority of the work directly relates to important backlog items. Good for you, you keep the company or department in business. However, you might be missing out on immediate revenues from low hanging fruit. Why not optimize your SEO rank now and then, or eliminate that bug 80% of your users are complaining about? These small improvements won’t harm the long-term objective and they do give you a change to help users, increase the short-term cash-flow and satisfy a few stakeholders along the way. Like their nickname, these projects or teams can be a bit boring and move slowly towards a certain ‘old age’ or goal. In their journey, they could lose the connection with the rest of the organization when results are not made visible in the meantime. Besides that, if these projects entail migration without new functionalities, also the teams can get bored. They may benefit from the diversion of small improvement stories.

PROS: working on the mission of the company, CONS: in long running projects stakeholders can get detached, ATTENTION: room for quick wins along the way?

 

4. Well… Black Dodo’s
Agile Dodo

If you have teams working on the black stuff, something is off. Perhaps you are way overstaffed, or backlog management is in utterly disorder. Avoid this situation at all costs. When nothing changes soon these teams will become extinct…

PROS: none, CONS: waste of time and energy for all, ATTENTION: immediate action required!

Balancing act, rhythm and focus

Do you feel like you are getting mixed signals now? You are right. This is the arena where great Product Owners can stand out of the mediocre crowd. If they are able to balance the Product Backlog with the stakeholders and find a rhythm together with their team(s) to ensure enough focus, you have a winning combination. Relevant questions to be answered are: Who is your most important stakeholder? And how are competing stakeholders managed? What is most important for the customer and the future of the company?

A predicable heartbeat helps the team and PO in delivering on regular intervals. Yet, it also promotes alignment in the rest of the organization. The characteristics play an profound role in the optimum heartbeat. For example, if you are part of a true DevOps team, you know ad-hoc work (important and urgent issues) will emerge and that is part of your sprint routine. In another case you might have a more component oriented team, building stuff for other teams.

If you only have one development team available, the balancing act of shifting priorities becomes more precarious. The team can feel comfortable working on multiple topics in one sprint and it is not forbidden to do so, as long as there is enough clarity and stories are really Done at sprint’s end. However, most teams benefit from focus during the sprint, so when possible, craft your Sprint goal on one or two categories only. You could for example spend one sprint on urgent matters and the next two or three on the important trajectory. In general, true orange stories are always executed asap. When multiple teams are involved you can have more flexibility and for example rotate duties between teams every few sprints.

Last thoughts

So, Eisenhower can help in identifying certain wanted or unwanted patterns in your current Product Backlog. What it cannot do is provide the ‘correct’ distribution. That task is still meant for the Product Owners and their teams. I am curious, what kind of wildlife represent your teams currently and how is your Backlog setup in terms of Eisenhower’s quadrants?

References

[1] Eisenhower: http://www.eisenhower.me/eisenhower-matrix
[2] Eisenhower: http://www.businessinsider.com/dwight-eisenhower…..
[3] Coyote: https://nl.wikipedia.org/wiki/Coyote
[4] Tortoise: https://en.wikipedia.org/wiki/Tortoise
[5] Dodo: https://en.wikipedia.org/wiki/Dodo

Filled Under: agile,scrum Posted on: 14 April 2017

Mission statement

Setup, guide and coach high performing teams capable in delivering truly great software.

Be Awesome

How? Try to improve something small everyday..... In management, in coding or life.

Learn from anybody

Be aware that every colleague, teammember or friend is capable of something that you are not.

Fail and letting fail

Failure is the only way to success, so fail fast and fail often, especially in software development.