Author Archives: Sjors Meekels

Leading Image

Scrum a Smart Travel Companion – Verheyen

In the last 20 years Scrum has proven itself to be the market standard framework for organizations working Agile. Despite this tremendous success many organizations still find themselves in the middle of an Agile transition. The Scrum beginner and professional both have an ongoing need for a short descriptive overview of the framework. For both target audiences the book “SCRUM a pocket guide – A Smart Travel Companion” is a useful tool in the world of Scrum.

The first version of this book appeared in 2013. Now, six years later the second edition has arrived. It has been polished a little bit and the cover also has had a makeover. The overall appearance is a bit larger in the second edition, but this makes the reading easier and holding the book handier. Verheyen is still affiliated with scrum.org and very active in the Scrum field. He is a well-known trainer, author and consultant.In roughly 90 pages he directs the reader in four distinct chapters from the root of scrum to the rules of the game itself, followed by the application of the latter. The book concludes with a short consideration on the future state of scrum.

Chapters:
1. The Agile paradigm
2. Scrum
3. Tactics for a purpose
4. The future state of Scrum

The need of leaving behind the old way of working is combined with the start of Agile thinking in chapter one. Without rambling Verheyen paints a clear picture of the biggest challenges and problems when transitioning into an Agile way of working. Especially the firm statements on Agility not being an end-state are refreshing.

In chapter 2 the author positions Scrum as a game with the intent to maintain control over the software delivery process in complex environments. As with other games, ground rules are in place to be followed by all participants. Whilst the rules aren’t many, it requires a great deal of discipline of the players to adhere to them. The reward of the rules and discipline is an unleashed flow of motivation, self-steering and problem-solving capabilities within Scrum teams.

Practical – and for many readers possible an eyeopener – are the examples in chapter 3 covering mandatory rules versus possible usage of good practices. The team’s freedom to choose and experiment with these practices provides insights in the power and adaptability of Scrum. Even the more seasoned Scrum professionals sometimes assumes that certain topics are prescribed and must be followed. Just because they have seen these in other teams or organizations. Verheyen meticulously explains the placement of the boundaries of the rules next to the fields of options and practices in the game.

At the end of chapter 3 a few paragraphs are dedicated to the scaling of Scrum in larger setups, like for multiple teams or products. Surprisingly common scaling frameworks like DAD, SAFe and LeSS are absent. Even Nexus Scrum.org’s own initiative to join the scaling frameworks is still not mentioned. Although the ideas and patterns described are almost identical to that of Nexus. Perhaps this was a conscious decision. A choice that does keep the focus solely on Scrum.

In the final chapter he provides a short perspective on the evolution of Scrum in organizations in the – near – future. Upstream, as he describes, Scrum has the potential to rise above development teams and come in use within management, product development and eventually in entire organizations.

Conclusion

The book is a swift read and on occasion touches other Agile frameworks. The true value of the book is its strong focus on the rules of Scrum. Due to the concise writing it is very suited for both the beginning Scrum enthusiast as well as the more experienced professional or manager who is looking to refresh the knowledge at his fingertips. The book has been around a few years already, yet it is still one of the first books I would recommend for people diving into Scrum! You can finish it easily on a slow night and provides enough thoughts to bring to the job the next day.

Filled Under: agile,book review,scrum,software development Posted on: 27 March 2019

Leading Image

Power of positives

Last week a co-worker suprised me with a very cool gift. Namely a new coffee mug with my own name and accompanying logo on it. It reminded me straight away on the positive impact that such gestures can have. You can make someones day simply by complimenting them. Or surprise someone with a gift. Same is true for letting people know they are valued and showing a genuine appreciation for the labour that they put in. Thanx Martin for reminding me again.

Filled Under: personal Posted on: 9 March 2019

Leading Image

Het SCRUM Modellenboek

‘Het SCRUM modellenboek’ levert datgene wat de titel uitdraagt. Een verzameling modellen die goed toepasbaar zijn in omgevingen waarin Scrum gebruikt wordt. Rik van der Wardt heeft 41 meer en minder bekende modellen verzameld, beschreven en gebundeld in deze uitgave. Zijn doelgroep bestaat naast Scrum Masters in principe uit iedereen die met Scrum of een andere Agile organisatievorm in aanraking komt, zowel binnen als buiten de IT.

In “Het SCRUM Modellenboek” schotelt auteur Rik van der Wardt de lezer een bord vol nuttige modellen voor die gebruikt kunnen worden bij het werken in Agile teams. Laat je niet misleiden door de titel die wellicht het zwaartepunt legt op Scrum. Verreweg de meeste van de modellen zijn in algemeenheid geschikt voor het werken met teams en zeker in een Agile omgeving. De auteur komt zelf overigens niet direct uit de IT maar is werkzaam voor met name niet-IT-organisaties.
Waarom is dit boek handig? De theoretische basis van Scrum, gecodificeerd in de 19 pagina’s tellende Scrum guide, is zeer beperkt. Dit kan de indruk wekken dat het toepassen van Scrum eenvoudig is. Niets is minder waar. Juist het invullen van de ruimte die dit framework biedt is een van de meest uitdagende zaken bij het inzetten van Scrum. Bij het tackelen van die uitdaging kan dit werk gebruikt worden. Of het nu de rituelen, het teamspel of de interactie met management betreft, er is een model voor handen om je te helpen.

Dan de indeling van het boek. In de korte inleiding wijdt de auteur een aantal alinea’s aan de oorsprong en kracht van Scrum. Hierna volgt een schematische weergave van de modellen op Scrum-rollen en -rituelen zodat de lezer gericht op onderwerp of interesse door kan bladeren naar een bepaald hoofdstuk. De opbouw van de hoofdstukken en dus modellen volgt een vast patroon. Eerst wordt het doel van het model geformuleerd gevolgd door gebruiksvoorbeelden. Deze gebruiksvoorbeelden zijn geschreven in het format: Als een Wil ik Zodat ik . Een leuke knipoog naar de wijze waarop User Stories vaak worden opgesteld. Hierna wordt het model in meer detail toegelicht, in totaal trekt de auteur 4 pagina’s uit per model. Dit maakt dat je als lezer snel een idee hebt over de toepassing en inzetbaarheid. Wil je meer weten dan word je op weg geholpen door een aantal referenties ter afsluiting.
Een persoonlijke greep uit de modellen om een indruk te geven. Voor alle Scrum rituelen is er in ieder geval één model beschikbaar in de vorm van een checklist. Zo zijn de meest voorkomende valkuilen afgedekt en de mechaniek van de rituelen geborgd. Natuurlijk zijn bekende teammodellen aanwezig zoals: de teamrollen volgens Belbin, het Johari-venster van Ingman & Lyft en de pyramide van Lencioni. Erg handig als je op zoek bent naar invalshoeken om de samenwerking in teamverband te versterken.

Er is ook plaats voor Nederlandse inbreng in het boek, met name op het snijvlak met management. Zo is model 3 gewijd aan het Scrummen van je Strategie. Hierbij zet de auteur de feedback loop in van Sjors van Leeuwen om management in staat te stellen een wendbare strategie voor het bedrijf op te stellen. In model 19 wordt Management 3.0 van Jurgen Appelo, ingezet om een toepasselijke managementstijl te ontwikkelen. Hierbij worden tevens dwarsverbanden gelegd met andere modellen in het boek.
Een tweetal modellen die voor mijzelf nieuw waren zijn GROW-coaching (model 13) en SOAR (model 32). De eerstgenoemde kan ingezet worden voor doelgerichte coachinggesprekken op individuele- of teambasis. Wanneer je het acroniem uitschrijft krijg je zicht op de verschillende stappen en zie je direct de focus op het behalen van een resultaat (Goal, Reality, Options, Way forward). Het heeft vooral naamsbekendheid gekregen door het boek van Whitmore in 1992 Coaching for Performance. Ook SOAR betreft een acroniem, Strenghts, Opportunities, Aspirations en Results. Dit model is prima geschikt als kapstok voor een retrospective. De nadruk wordt gelegd op de sterke punten van een team en het uitbouwen van deze punten door ze te koppelen aan concrete acties.

Conclusie

Het Modellenboek leent zich prima als inspiratie voor de beginnende Scrum enthousiasteling. Maar ook voor de ervaren Scrum-professional zullen er voldoende interessante modellen inzitten die direct toepasbaar zijn in het dagelijkse werk. Natuurlijk zijn niet alle modellen nieuw en toegegeven, sommige modellen (checklists) zijn wellicht wat ‘licht’ om echt als model geclassificeerd te worden. De kracht en toegevoegde waarde van het boek zit hem echter in deze enigszins bonte verzameling en het feit dat de meeste modellen breder kunnen worden toegepast dan alleen bij Scrum!

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

Filled Under: agile,book review,scrum,software development Posted on: 12 February 2019

Leading Image

Dilbert still struggles working Agile

In my previous blog featuring Dilbert in 2016 – Dilbert saves the Agile day – we elaborated on a few of the challenges he encountered. Now 2,5 years later, new ones have arrived. That is why I have made a short selection of observations I had in the area of Agile team management. Let’s continue our journey and see how DevOps and Agile are working out for our friends…

‘One Dilbert still says more than a thousand words.’

1. Not my job
Dilbert_not_my_job

Two of the pillars in the Agile universe are autonomy and ownership of teams. With great power comes great responsibility. So, when you are part of a DevOps team and you have the responsibility for a production environment, you should know its health. Good teams will take the necessary steps to get the information needed and act upon it. However, this philosophy is not only applicable for teams. It is also true for Scrum Masters, Product Owners, Team Manager or any other role. For example:
– Scrum Masters should know when the team is feeling down or is experiencing difficulties in its delivery process.
– Product Owners should know, which features are being used and how the accumulated technical debt will impact future development.
– Team Managers should know the top three impediments their teams are facing and where they need help.
The fact that sometimes you simply don’t know, is not bad in itself. As long as you perceive this as an indication to get informed. “I did not know” is not an excuse, it is your job to know.

2. Who actually need good engineers?
Dilbert_worthless_employees
Although the percentages are perhaps steep, bottom line is that I have seen this a few times in practice. It requires strong leadership and vision on skill and people development to keep your employees in shape. This responsibility works both ways. In my opinion, employees should be equally accountable for their personal development. As part of a good feedback cycle from peers and managers, people should develop a fair insight in their own capabilities. Companies and departments are in trouble when management attention is lacking or is too weak. In that case you are at risk of employing workers with deteriorating skill sets that have less and less value. Developing a continuous learning culture is vital in software companies who are rapidly moving from Scrum to DevOps and beyond. I would like to see teams, Scrum Masters and managers team up for this challenge!

3. That’s just not Agile
Dilbert_That_is_not_Agile
At times you find yourself being part of a discussion that doesn’t seem to make sense while the people surrounding you seem to think otherwise. A topic I find particularly intriguing is the popular phrase “That is not Agile”. It is like you can silence all questions or discussions with that one line. I am a strong believer in the Agile way of working. However, at times you need to understand that change – especially cultural change – does not happen overnight but requires small steps. It is not a terrible thing if some stuff does not feel a 100% Agile, yet. For example, it can be very fruitful to have that extra check or coordination in place when lots of teams are involved in releasing a new software version. I favor the idea of experimenting and enlarging team’s autonomy. Especially when team basics are in place and embedded in the right organizational conditions (that last part is not meant as rigid as it may sound). Remember, being Agile is not a goal in itself, it remains a means to an end.

4. Please don’t use that language here
Dilbert_twizzle_the_flurm
“My manager has absolutely no idea what I am doing all day” it is not the first time that I have heard that sentence. It is part of a recurring discussion I have with Scrum Masters, engineers and my fellow managers. How much knowledge, insight and hands-on experience does a manager need in order to lead a group of well-trained engineers? I don’t dare to think that there is only one truth, as always it probably depends. Without speaking too much to the choir, I can only elaborate on my own experiences as a manager and Scrum Master. It has helped me a great deal that I have a technical background. On the other side I have seen some talented colleagues without any technical background, working outstanding without any problems. Technical background or not, teams have their own responsibility in transparent communication; they have to be able to explain what they are doing and why it is important. And not only in bits, bites and flurm but also in a comprehensive manner so Product Owners, customers, users, business colleagues and managers are well informed.

5. Agile strategy in place, check
Dilbert_Agile_strategy
As all companies seem to be going Agile it is normal that employees need information on the actual changes in their company. Whether you are introducing Scrum or trying to move to DevOps, people will want to know what the impact is going to be. What does it mean for my role, my team or my career path? The people – or team – in charge of the change should be able to explain the new expectations towards the teams and individuals. What are the responsibilities, tasks and accompanying authorizations? Even more interesting, how is the balancing act envisioned of team freedom & mandates on one hand and organizational governance on the other. The expressed desire to make teams more autonomous often contrasts with un underlying basic lack of trust. As a result, in practice teams are not being allowed to act autonomously. It all comes down to breaking free from previously existing structures and organizational boundaries. A major shift has to be made in the managerial aspects of leading teams and delegating decision making to teams.

Many companies are well under way in their Agile journey. At times it proves to be difficult and challenging. Thank God Dilbert is here to make us laugh along the way…

Copyright:
[1] DILBERT © 2019 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.
[2] DILBERT © 2018 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.

Filled Under: agile,interim management,scrum,software development Posted on: 8 February 2019

Leading Image

Agile – Rini van Solingen

“Agile” is de eenvoudige maar heldere titel van het nieuwste boek van Rini van Solingen. In deze bewerkte verzameling van eerder verschenen artikelen laat Van Solingen zijn licht schijnen op veel voorkomende Agile-uitdagingen waar organisaties voor staan. Vanuit verschillende perspectieven benadert hij de vraagstukken en dat maakt de doelgroep van het boek dan ook breed.
Managers, Agile trekkers en veranderaars kunnen dit boek als overzichtswerk zien en de handreikingen gebruiken als inspiratie of startpunt voor vervolgonderzoek.

Rini van Solingen is geen onbekende auteur in het Agile werkveld. Eerdere publicaties van hem zijn – naast zijn verschenen artikelen – onder andere: “De kracht van SCRUM” en “De Bijenherder”. In zijn nieuwste werk “Agile” verbindt hij eerder verschenen artikelen met elkaar tot één geheel. In twintig hoofdstukken neemt hij de lezer mee in zijn praktijkervaringen en observaties die hij in de laatste 9 jaar heeft opgedaan. De inzichten die hij biedt tonen geen utopisch beeld waarin de sky-de-limit is. Zo nu en dan zelfs het tegenovergestelde. De voorbeelden van moeizame of tot stilstand gekomen transities spreken meer tot de verbeelding dan een bloemlezing over de potentie en de best geslaagde voorbeelden uit de praktijk.

Agile_recensie

De hoofdstukken zijn kort, bondig en mooi vormgegeven met passende illustraties. Het boek leest prettig, met name omdat de schrijver scherp formuleert. In grofweg een halve dag ben je het boek van voor tot achter door.

Inhoudsopgave:
1. Het waarom, wat, wanneer en hoe van agile
2. Gaat het de juiste kant op?
3. Wendbaar door afmaken
4. Gevaren van agile
5. Scrum of agile?
6 Is agile haastwerk?
7. Agile transformaties
8. Valkuilen van agile transformaties
9. Agile cultuur
10. Agile leiderschap
11. Agile besturing en structuur
12. Product Owner valkuilen
13. Kwaliteit door autonomie
14. Hyperproductieve agile teams
15. Agile op grote schaal
16. Agile PI Planning
17. Agile opdrachtgeverschap
18. Agile en fixed-price
19. Automatiseren van herhalend werk
20. Agile schatten met Planning Poker

Een volledige beschrijving van de hoofstukken gaat deze recensie te buiten. Ik noem enkele opvallende aspecten.
De introductie en uitleg van het Ralph Stacey model in hoofdstuk 1. Hierin wordt uitgelegd voor welke type werkzaamheden, Simpel, Gecompliceerd, Complex tot Chaotisch, Agile werken een goede aanpak is. De schrijver laat zien dat Agile het beste past bij gecompliceerd werk ten opzichte van een alternatief als Lean, wat beter werkt bij gecompliceerd – planbaar te maken – werk.

Het uitvoeren van een Agile transitie brengt vaak frustraties en teleurstellingen met zich mee. In hoofdstuk 4 wordt een aantal veel voorkomende gevaren benoemt die hieraan ten grondslag liggen. Twee daarvan zijn voorkomend maar vaak onvoldoende zichtbaar voor de buitenwereld, of de mensen die een voortrekkersrol bekleden in een Agile verandertraject. De eerste betreft de randvoorwaarden die niet, of onvoldoende, door management of directie worden aangepast. Als deze er niet zijn zullen de medewerkers en de organisatie als geheel niet in staat zijn de verwachte cultuuromslag waar te maken. De tweede heeft betrekking op de rol van de Product Owner in het Agile gedachtegoed. Veel organisaties verwachten te snel te veel van de mensen die deze rol invullen. Zonder ook voor hen de juiste voorwaarden als training & opleiding en mandaat te scheppen. Wat is een mooier voorstel dan de verandering naar Agile aan te pakken op een Agile wijze? In het laatste deel van dit hoofdstuk wordt deze “Paradox van gecontroleerde flexibiliteit” helder toegelicht.

Hoofdstuk 15 draait om het Scalen van Agile naar meerdere teams in grote organisaties. In de praktijk zijn hiervoor diverse frameworks beschikbaar met meer of minder adoptie en ondersteuning vanuit de markt. De auteur benoemt hier echter alleen SAFe, als meest bekende en populaire framework. Mijns inziens doet hij daarmee alternatieven als LeSS, Spotify of Nexus, en hiermee de lezer, net te kort.

In het boek is ook aandacht voor de meer projectmatige of hardere kant van zakendoen, hetzij via aanbestedingen hetzij via andere contractvormen. In hoofdstuk 18 wordt besproken hoe fixed price contracting past binnen een Agile werkwijze. De auteur komt met voorbeelden en maatregelen en maak zo inzichtelijk dat deze twee beter samengaan dan menigeen verwacht.

Conclusie

Bij een nieuw boek over Agile rijst al snel de vraag naar de toegevoegde waarde ten opzichte van de bestaande literatuur. In dit geval zit de kracht van het boek vooral in de heldere uiteenzetting van de tips, maatregelen en voorbeelden die voor specifiek vraagstukken relevant zijn. Doordat de vraagstukken soms een zekere mate van overlap kennen kun je als lezer een gevoel van herhaling krijgen; dit is echter niet storend. Dit geldt temeer omdat je niet lineair door het boek hoeft te gaan, je kunt praktisch in ieder hoofdstuk beginnen op basis van je eigen behoefte. Kortom, een overzichtelijk Agile naslagwerk en handig startpunt bij concrete vragen of probleemsituaties.

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

Filled Under: agile,agile projectmanagement,book review,scrum Posted on: 12 January 2019

Leading Image

Agile – with a Smile

Agile is en blijft de trend maar tegelijkertijd is Agile alleen niet meer zaligmakend. Voor sommige organisaties is de Agile storm hen meer overkomen dan dat hier doelbewust op is gestuurd. Mede hierdoor zien Dion Kotteman, Henny Portman en Bert Hedeman een aantal terugkerende problemen ontstaan in Agile projecten. In hun gezamenlijke werk “Agile with a smile” nemen zij concrete vraagstukken door en bieden handige tips om Agile projecten en organisaties succesvoller te maken.

Op het eerste gezicht hebben PRINCE2 en Agile niet veel overeenkomsten. Voor de hardcore Agile evangelisten zijn woorden als projectmanagement en PRINCE2 zelfs als vloeken in de kerk. Toch laten de auteurs Kotteman, Portman & Hedeman zien dat het Agile gedachtengoed en PRINCE2 beter bij elkaar aansluiten dan gedacht. Het boek “Agile with a smile” geeft organisaties handvatten om het Agile werken te voorzien van practices om bekende valkuilen te omzeilen.
De verhaallijn van het boek is een niet-IT-organisatie die met Scrum & Agile aan de slag is. We leren Bob kennen als de manager die de driver is van het Agile werken maar al snel tegen knelpunten aanloopt. Gelukkig kan hij leunen op Charles, die zijn ervaringen deelt met het Agile werken uit de IT-wereld.

Inhoudsopgave:
1. Prologische introductie
2. Een team als een dream
3. Prioriteren of uitsmeren
4. Rapporteren en escaleren
5. To comply or not to comply
6. Past iedereen in Scrum
7. Lever wat nodig is
8. Verliest er iemand zijn beheersing?
9. Goede architectuur behoeft geen krans
10. Digitaal epilogisch

Concreet bespreekt het boek een aantal onderwerpen waar Agile teams in de praktijk regelmatig tegenaan lopen. Van de prioriteitstelling van de Product Owners, tot rapportage en een geschiktheidscheck voor het werken met Scrum. Ook het moeten voldoen aan kaders of rapportages voor toezichthouders is een thema dat de revue passeert. Stuk voor stuk problemen waar organisaties, zeker de grotere, inderdaad tegenaanlopen in hun transitie naar het Agile werken.
De auteurs breken daarnaast een lans voor PRINCE2 en beargumenteren, middels Charles, dat PRINCE2 eigenlijk heel Agile is en jarenlang verkeerd is ingezet. De combinatie van PRINCE2 en Agile werken is zelfs een heel logische en de twee concepten vullen elkaar in de praktijk goed aan. Gezien de achtergrond van de auteurs in het PRINCE2 Agile domein is dit geen verrassende conclusie.

Wat of wie is de doelgroep van het boek? Deze vraag vind ik lastig te beantwoorden. Het is in ieder geval nuttig enige ervaring te hebben met Scrum en Agile werken. Is dit niet het geval dan mis je bij de gestelde uitdagingen al gauw de context. Aan de andere kant moet je ook niet te veel ervaring hebben omdat de handreikingen en tips weinig dan nieuws voor je zullen bevatten. De situationele beschrijvingen en tips die gegeven worden wisselen tussen projectmatig werken en het acteren in de lijnorganisatie. Deze contextwisseling zie je ook in de reflectie van de marketingafdeling van Bob ten opzichte van de situatie in de softwarewereld. Dit maakt het boek niet alleen geschikt voor IT-professionals maar juist ook voor mensen daarbuiten.
Het is een onmogelijke opgave om in een onderwerp als dit volledig te zijn. Het grootste thema binnen het onderwerp dat ik mis betreft het managen van afhankelijkheden en het werken met meerdere teams. Daarnaast gaan de auteurs nauwelijks in op het basisprincipe van Scrum dat het team al het werk doet en welke gevolgen dit uitgangspunt heeft voor de rollen die mensen hebben in een team of project. In dit kader worden Continuous development en DevOps wel vluchtig genoemd maar niet uitgediept.

Conclusie

Of het “Agile with a smile” of ”met een frons” is na het lezen van dit boek hangt af van je achtergrond en ervaring met Scrum en projecten. Hoe dan ook doet dit toegankelijke boek je snel een aantal suggesties aan de hand om je organisatie, in de Agile storm, met ‘oude’ practices uit de PRINCE2-wereld in rustiger vaarwater te brengen.

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

Filled Under: agile,agile projectmanagement,book review,prince2 Posted on: 6 July 2018

Leading Image

Kanban in de praktijk – Growing Agile

Focus aanbrengen en zaken daadwerkelijk afmaken voordat je aan iets nieuws begint. Het klinkt zo eenvoudig, maar in de praktijk blijkt dit toch lastiger dan gedacht. Met – het van Japanse origine zijnde Kanban – kun je deze uitdaging te lijf gaan.

In het boek Kanban in de praktijk leggen Karen Greaves en Sam Laing stap voor stap uit hoe je Kanban voor je kunt laten werken. Er is geen technische of praktische voorkennis benodigd, het boek is voornamelijk gericht op beginnende teams en organisaties.

De auteurs hebben vanuit hun bedrijf Growing Agile inmiddels al een aantal publicaties op hun naam staan. Ze beschrijven steeds concrete thema’s uit het Agile werkveld. Zo ook Kanban in de praktijk, de Nederlandse vertaling van Kanban Workbook uit 2016. Aan de hand van het fictieve hoveniersbedrijf Growing Garden nemen Greaves en Laing de mogelijkheden van Kanban door. Door de geleidelijke opbouw, zonder gebruik van jargon of bijvoorbeeld IT-gerelateerde termen, is dit boek geschikt voor iedereen die met Kanban aan de slag wil om meer te doen in minder tijd.

Inleiding
Hfd 1. Werk visualiseren
Hfd 2. WIP en pull
Hfd 3. Doorstroom verbeteren
Hfd 4. Expliciete afspraken
Hfd 5. Samen verbeteren
Bijlage – Personal Kanban
Bijlage – Het vliegtuigspel

De verhaallijn is duidelijk. Er wordt een gezamenlijk project gestart door Linda, Ellen en Joost, tussen de reguliere werkzaamheden van iedereen door. De drie besluiten Kanban in te zetten met als doel dat het werk, het schrijven van een boek, daadwerkelijk afkomt. In elk volgend hoofdstuk leren onze hoveniers dat er best nog wat verbeterd kan worden aan de opzet die zij tot dan toe gebruikten. De leercurve die zij meemaken zie je ook vaak in de praktijk terug, met trial en error ontstaat een werkwijze die passend is voor situatie.

Qua theoretische volledigheid zit het boek goed. De basisprincipes worden uitgelegd en daarna komen vaste onderdelen aan bod: initiële Kanbanborden, WIP-limieten per persoon of kolom, creëren van Pull en spelregels. Het geheel wordt aangevuld met praktische tips, voorbeelden en vragen voor de lezer. Op deze wijze rol je eenvoudig door een scala van opties en kun je de beste opties voor je eigen situatie bepalen. De suggestie die de auteurs geven om na ieder hoofdstuk zelf met de aanpassingen en vragen aan de slag te gaan, is nuttig. Zo ervaar je direct wat voor- of nadelen van bepaalde keuzes zijn.

Daarnaast hebben de auteurs in het verhaal een aantal bekende kenmerken van Scrum aan het gebruik van Kanban toegevoegd. De dagelijkse Standup, Retrospective en Definition of Done zijn ingebed. Zij hebben deze practises hiermee onderdeel gemaakt van Kanban, logisch want deze Agile practices zijn hiervoor prima geschikt. Puristen zullen zeggen dat zij hiermee feitelijk ScrumBan beschreven hebben. Deze samenvoeging doet echter niets af aan de waarde van het verhaal en sluit aan bij de ontwikkelingen in de praktijk. Zo heeft Scrum.org vorige maand een publicatie uitgebracht waarbij Kanban wordt beschreven als werkwijze binnen Scrum teams. [zie https://www.scrum.org/resources/kanban-guide-scrum-teams].

In de bijlagen van het boek zijn tevens twee extra’s opgenomen ‘Personal Kanban’ en ‘Het vliegtuigspel’. De laatste sprak mij het meeste aan en geeft snel inzicht in de kracht van Pull. Probeer deze eens uit met je team en je zult zien wat het effect is van een kleine aanpassing in werkafspraken.

Conclusie

Kanban in de Praktijk is geschikt voor iedereen die weinig bekend is met de werkwijze Kanban en graag met concrete voorbeelden en/of stappen werkt. Mocht je een vlotte lezer zijn dan bestaat de kans dat je het boekje binnen een uur uit hebt. Dat is geen ramp, in dat geval ben je waarschijnlijk ook al bekender met de materie en kun je wellicht met een aantal tips direct aan de slag.

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.growingagile.co.za.

Filled Under: agile,book review,kanban,scrum,software development Posted on: 6 April 2018

Leading Image

Agitma & Sjors in the media

It can be interesting to see what Google can find on you. I just tried it out…
Besides the usual stuff, like the content of the Agitma website, they came up with a few other pages as well (most of them are in Dutch)

Interview with FourCorners on their Agile journey: www.werken20.nl/agile-werken-verovert-creatieve-sector
Interview with De Baak: debaak.nl/een-hork-van-een-manager-blijft-ook-met-agile-een-hork
Meetup in Craiova: meetup.com/Craiova-Software-Technology-Meetup
Girlsday at ING Mobile: www.ing.jobs/Girlsday-bij-ING
Old interview for Info Support: www.youtube.com/infosupport
Bachelor thesis award: www.computable.nl/prijs-voor-scriptie-autonomie-in-softwarestructuren
Scrum.org profile: www.scrum.org
Karate (personal): www.arnhemsekoerier.nl/je-afkomst-of-baan-speelt-geen-rol

Note: the last one is not directly work related, but a nice picture to share..

Filled Under: agile,personal Posted on: 23 March 2018

Leading Image

What I gained from 100+ retrospectives

Nothing teaches better lessons on retrospectives than running retrospectives in practice. In this blog I will share personal lessons on retros and some ideas for alternative structures. The first four topic describe mindsets and things to consider during preparation or follow ups. The latter four provide ideas on alternative retro formats.

Boy-scout-approach: It is okay not to have life changing outcomes of the retro. Small steps count very much in the overall picture. If every retro would produce a live changing outcome, all teams would be top notch by now. Why not use a boy-scout-approach: each time you sit together try to leave the room in a slightly better shape than you came in. It is just like Uncle Bob advises programmers to do before checking in code.

No absolutism in having one: It is also okay to skip the retro occasionally, for example when the whole team wants to work on finishing an important feature in a sprint or simply because a lot of people are not in. This forms no problem just as long as this is incidentally and not structural.

Attendees & information: Some teams and Scrum Masters are really outspoken on who should or should not attend their retrospectives. My personal ‘ground rules’ are:
– Always invite and encourage Product Owners to join in;
– Let management know they can sometimes join, I only invite them directly when needed;
– Actively share the outcomes of the retro with PO, teams and management.
For me it is a healthy sign if Product Owners like to participate and have a genuine interest in being there. In general, the same holds for occasional attendance of line management or perhaps even project managers. In case of the latter two, their role should be kept equal to that of the team members or should be that of an observer. Although when teams don’t feel safe anymore, you should reconsider the setting and check what is hindering the team. In case (project) management or Product Owners show no interest in the outcomes, this indicates a gap in involvement and should be addressed. Of course, there is a mutual obligation to inform, but management should have a basic interest in the teams.

Historical perspective: Save the teams retro outcomes in a form, so you can see what is happening over time. Not just to check if actions and outcomes are put to effective use. If you have done this a few times for multiple starting teams, you see some patterns emerging. For example, in the type of topics discussed during retros. Knowledge, team spirit, basic rules on the Agile Way of Working are all topics to be found for starting teams. More importantly, you can see if topics reoccur and if topics in general relate to more process or enhanced improvements. These insights enable you to think about the ‘why’ of these reoccurring topics and appropriate actions.

Team-coffee: After a sprint went sour, it could work just to have a team-coffee and let people spill their guts and let their frustrations run freely. Change of scenario helps in getting people in the trusted zone to talk. No need for a formal routine, just write down what you hear and do a summary & wrap up of what you have heard to. If you feel more comfortable with increased structure, you can follow the steps of lean coffee to steer the session, see: lean coffee.

Communication & personalities: Working on team collaboration and being able to understand each other’s dos and don’ts can add real value. I have created an easy format to help teams through a session by prepping and explaining themselves. The personal test results are not interesting to me – although sometimes the combined results of a team can tell you a few things – but it certainly is a nice personal pitch starter. By allowing everyone to share their own characteristics people often surprise each other. For more info on the format see: retrospective-team-communication-and-personalities.

Feedback & speed dating: For teams who are a more familiar with each other, you can try a setup for providing and accepting feedback. Step one would be to share some basic rules and theory. And of course, invite people to provide each other feedback. Mind that this usually does not mean people will start doing it. It seems giving feedback is not that easy. A little trick here is to setup a retro like a speed date session. People sit in one-on-one sessions and give each other a tip and a compliment on their work in the team. This will help team members overcome the first hesitations to share their thoughts. To conclude everyone can present the top-tip he or she received to the group.

Retro tools: In some situations, you might be part of a co-located team. The team could be spread across a building, city or even across countries and time zones. Working in these teams requires extra energy and work from everybody. This is especially true for sessions like a retro where discussions and interactions are the foundation of valuable outcome. Some tools support distributed retrospectives like retrospectives-tool-for-distributed-retrospectives. Even when you are perfectly sitting together, the change in format by using a digital tool can be fun.

Additional reading:

samples.leanpub.com/funretrospectives-sample.pdf (retro formats)
leanpub.com/50quickretrospectives (retro formats)
www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective
(basic explanation of running a retrospective by Mike Cohn)

Agile Retrospectives – Making Good Teams Great (Esther Derby & Diana Larsen)
Coaching Agile Teams (Lyssa Adkins)
Large-Scale Scrum – Chapter 14 (Craig Larman & Bas Vodde)

Special thanx to Stefan Jansen for letting me use the retro picture as he is the only person recognizable in the collage. Furthermore, the teams of Zoover, Weeronline, PGGM, Info Support, Softelligence and FourCorners have very much contributed!

Filled Under: agile,scrum,software development Posted on: 9 March 2018

Leading Image

Lean in de Logistiek – Schuurmans / Plas

In Lean in de logistiek bundelen Esther Schuurmans en Caroline van der Plas hun kennis en ervaring in de wereld van lean implementaties. Hoewel de titel zich specifiek richt op de logistieke branche, leent het werk zich prima voor een bredere kijk op het thema. Met een kleine tijdsinvestering heb je zo een verfrissing van je lean kennis en een voorbeeld implementatietraject gezien.

Esther Schuurmans en Caroline van der Plas hebben veel ervaring in kwaliteitssystemen, lean, en logistieke omgevingen. In dit gezamenlijke handboek Lean in de logistiek bundelen de auteurs hun krachten en geven zij een beknopt overzicht van wat lean organisaties te bieden heeft. Het is een to-the-point beschrijving waarvoor geen specifieke voorkennis of ervaring benodigd is.

Het boek is opgedeeld in drie overzichtelijke delen. Kort gezegd beschrijft deel 1 de uitgangspunten en de belangrijkste onderdelen de je van lean moet weten om de rest van het boek goed te kunnen begrijpen. In deel 2 worden handvatten gegeven voor de implementatie van lean in organisaties. Het laatste deel bespreekt een praktijkcasus op basis van de werkzaamheden van de auteurs bij Docdata.

Deel 1: Wat moet je weten over lean (blz. 17 t/m 62)
Geen boek over lean zonder een korte introductie in de achtergrond en geschiedenis. In vogelvlucht worden de belangrijkste begrippen aangestipt die nuttig en nodig zijn om de rest van het boek op waarde te kunnen schatten. Het is mooi dat de auteurs ook stilstaan bij de drie stakeholders van lean implementaties, zodat duidelijk is dat je een lean implementatie niet alleen doet voor je klanten. Het tegengaan van verspilling is een van de bouwstenen van lean, dit kunnen herkennen en verminderen zijn belangrijke eigenschappen die binnen organisaties ontwikkeld moeten worden. Als laatste wordt het neerzetten en uitbouwen van een lean cultuur besproken.

Deel 2: Hoe implementeer je lean in jouw organisatie (blz. 63 t/m 112)
In dit hoofdstuk delen de auteurs de TROTS-aanpak die zij hebben gedefinieerd. De aanpak staat voor Toewerken naar, Resultaten op, Operationeel, Tactisch en Strategisch niveau. Het aardige aan deze aanpak is dat deze wordt opgehangen aan het lean huis en tevens een de link wordt gelegd met de verschillende niveaus waarop naar organisaties gekeken kan worden. Daarnaast worden verschillende lean tools zoals S5, Value Stream Mapping en bijvoorbeeld A3, qua toepassing en effect in detail besproken.

Deel 3: Praktijk (blz. 113 t/m 151)
De praktijkcase die in het derde en laatste hoofdstuk centraal staat, is gebaseerd op de ervaringen van de auteurs die zij in de periode vanaf 2010 bij Docdata hebben opgedaan. De naam Docdata is voor velen waarschijnlijk een onbekende. Dat verandert waarschijnlijk wanneer je hoort dat zij de grootste dienstverlener in e-commerce was in 2015 en optrad als een belangrijke partner van bijvoorbeeld Bol.com in de logistieke afhandeling van orders. Inmiddels is Docdata een onderdeel geworden van het internationale INGRAM MICRO Inc. De auteurs beschrijven welke lean methoden zij hebben ingezet en welke resultaten deze hebben gebracht om de groei van het bedrijf te ondersteunen. Er is bijvoorbeeld gestart met 5s en het inrichten van teamcorners om informatie zichtbaar te maken voor teams (Visual management). In dit hoofdstuk maken zij een heldere connectie met de theorie en implementatie strategie uit de vorige hoofdstukken. Natuurlijk ontbreken ook de resultaten van het traject niet.

Kleine noot aangaande de eindredactie; de afbeelding op blz. 76 heeft mij even doen twijfelen over bullets 1, 2, en 5. Het blijkt echter dat de verkeerde afbeelding in het boek is terecht gekomen. Geen zorgen, negeer de afbeelding en richt je op de tekstuele uitleg. Wil je per se de juiste afbeelding hebben? Ga dan naar de website van leanindelogistiek.nl/formats om deze, en eventueel ook andere afbeeldingen, te downloaden.

Conclusie

Lean in de logistiek is compact vormgegeven en bevat een aantal kleurrijke foto’s en afbeeldingen met quotes en/of diagrammen. Persoonlijk vond ik de leukste quote: ‘Alleen ga je sneller samen kom je verder’. De quote raakt voor mij echt de kern van het werken in team- of organisatie verband. Ook een lean implementatie zal je nooit alleen kunnen doen. Kort samengevat: het boek is geen zwaar leesvoer en laat zich rustig in een paar uurtjes doorlezen, prima investering!

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

Filled Under: book review,interim management,lean Posted on: 9 March 2018

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.