Auteurs: Eric Brechner; James Waletzky (draagt bij aan een hoofdstuk)
Het doel van Kanban is om op elk moment van de werking van de medewerkers waarde toe te voegen aan het product of de dienst ten behoeve van de klant. Het gaat dus om een soort optimalisatie van de inspanningen van de teamleden, ten behoeve van eigenlijk alle partijen.
De auteur (Eric Bechner) schrijft vanuit zijn ervaring als pioneer van Kanban bij Microsoft in het “Xbox engineering team”. Vanuit zijn ervaring toont hij aan hoe het zou kunnen werken voor andere teams.
In het eerste hoofdstuk geeft de auteur een hands-on manier aan om het management te overtuigen dat Kanban een manier van managen is die best wel aansluit bij de manier van werken in de huidige tijd. Deze argumenten worden verpakt als een een brief aan het management, die bijna direct copy-paste gewijs kan gebruikt worden, mits aanpassingen die nodig zijn voor uw organisatie.
In het tweede hoofdstuk “Kanban quick-start guide” kan je al direct aan de slag met Kanban. De eenvoudige principes van Kanban worden uitgelegd, zodat de leercurve om ermee aan de slag te gaan minimaal is. Uiteraard, zoals bij alle managementmethodes, moeten er soms problemen opgelost worden, zoals bijv. bottlenecks of trage voortgang van zaken, of zaken die een impact hebben op het hele team. Om daarin tegemoet te komen, zijn de meest voorkomende problemen opgenomen in de paragraaf “Troubleshooting” waarin de lezer kan putten uit de ervaring van de auteurs.
In hoofdstuk drie leert de lezer managementtechnieken van Kanban om o.a. tijdsschattingen te maken over o.a. hoe lang het project nog gaat duren. Daarbij worden begrippen geïntroduceerd zoals MVP (Minimum Viable Product), Aantal nodige taken om een product af te werken, “Task Completion Rate”, “Expected completion date”, “Current Task Estimate”, “Task Add Rate”… Spijtig genoeg worden formules textueel beschreven en er niet bij gezet in formulevorm, wat enige programmatie zou ten goede komen.
Hoofdstukken vier en vijf gaan respectievelijk over de nodige aanpassingen wanneer men overschakelt uit de waterval methode of de Scrumm methode naar Kanban. Vermits het doorgaans des mensen is om weerstand te bieden aan verandering, geeft elk hoofdstuk op het einde een “directe” Q&A sectie voor antwoorden op moeilijke vragen van medewerkers.
Hoofdstuk zes gaat over typische dingen voor ICT-teams, zoals “continuous integration”, “continuous publishing” en “continuous deployment” bij het ontwikkelen van componenten, apps en diensten. Daarbij kan de afhankelijkheid van een team van andere teams bepalend zijn voor de eigen prestaties.
Hoofdstuk zeven gaat over hoe je Kanban gebruikt in grote organisaties, met honderden engineers of meer. Daarbij zijn onderlinge afhankelijkheden nog meer bepalend voor de samenwerking van teams.
Hoofdstuk acht gaat over “sustained engineering”. Het heeft te maken met het gebruik van Kanban eens het project is opgeleverd, maar er nog nazorg nodig is zoals bijv. extra bugfixing of stabiliseren van de toepassing.
Het laatste hoofdstuk, hoofdstuk negen, kijkt naar andere bronnen en verder: wat kan je nog verbeteren eens je Kanban hebt geadopteerd? Het vertelt over het gebruik van Kanban in combinatie met Agile en Lean. Het vertelt over de principes waarvan Kanban gebruik maakt zoals visualisatie, minimalisatie, “Little’s Law”, “Single Piece Flow”, en de “Theory of constraints” en “Drum, Buffer Rope”. In dit hoofdstuk geeft de auteur bij elk onderwerp tips voor verdere literatuur, indien het de lezer interesseert om er meer van te weten.
Vond u deze boekbespreking waardevol? Ontdek dan ook deze gerelateerde artikels voor meer inspiratie en inzichten: