lean – Agitma

Category Archives: Lean

03 Dec 2019

Terminology matters: Agile/Scrum vs CD/CI vs DevOps

Chances are you were triggered by the enumeration of buzz words in this blog’s title. Without effort you could probably squeeze in a few more, like Lean or another flavor of ‘Continuous x’. A lot of managers and teams struggle explaining the company’s meaning regarding these terms. Striking is the absence of a clear and concise understanding of the vocabulary. DevOps is translated into Business involvement, CD/CI is equated to Scrum and Agile is basically a term covering everything. The point is, you need to make sure everyone around you understands what you mean and how the terms relate to your organization’s context. During sessions, I use the diagram above to explain the different angles that Agile / Scrum – Continuous Delivery – DevOps have. In this blog, I will dive in a little deeper and share my thoughts on the terminology and how I explain the nuances and differences.

Agile/Scrum and Continuous Delivery

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

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

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

Continuous Delivery and DevOps

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

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

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

DevOps and Agile/Scrum

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

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

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

Conclusion

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

Cheers,
– Sjors Meekels

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

References & recommended reading:

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

Download blog as PDF

This blog is available here:

Filled Under: agile,continuous delivery,devops,kanban,lean,scrum,software development Posted on: 3 December 2019

19 Nov 2019

DevOps in beweging – Heunks

DevOps in beweging van Jan Heunks is een Nederlandstalig verzamelwerk dat DevOps uit de doeken doet. Raakvlakken met onder meer Agile, Lean en Continuous Delivery komen uitgebreid aan de orde. Voor een allround beschouwing van DevOps, inclusief plaatsing in de huidige organisatiestructuren, is dit boek een uitstekend startpunt.

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

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

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

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

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

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

Conclusie

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

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

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,devops,lean,software development Posted on: 19 November 2019

12 Sep 2019

De Lean Strategie – Daniel Jones ea.

‘De Lean Strategie’ is de Nederlandse vertaling van een inspirerend Engels werk over de kracht van Lean om grote bedrijven te veranderen. De vier auteurs: Michael Balle, Daniel Jones, Jacque Chaize en Orest Fiume nemen de lezer mee tijdens de zoektocht van enkele bestuurders die met behulp van Lean de enorme uitdagingen binnen hun bedrijf te lijf zijn gegaan.

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

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

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

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

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

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

Conclusie

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

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

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: book review,kanban,lean Posted on: 12 September 2019

09 Mar 2018

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.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

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

22 Dec 2017

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.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

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

07 May 2017

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.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

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

02 Apr 2016

Quality == Speed

I like the sound of this brisk statement. In my recent experience and discussions with fellow Agile practitioners, I am more convinced than ever that this statement is true. It doesn’t matter what subject or profession, any neglect on quality will always come back to haunt you and your project. I will discuss a few recognizable examples we see every day, each sprint and all year round.

Aiming for quality or aiming on costs // quality in engineering skills
First, is it really necessary to mention that in order to create great software you need great – at least good – programmers and excellent tools to support them? Yes and no perhaps. Why is it that in our field of expertise we always have to defend our teams for the costs (wages) they carry? A greater and ability experience should be worth something. Research has shown good programmers can be more efficient by a factor 10 of than average programmers [2]. This is nothing new. However, it does seem paradoxical that even experienced managers are addicted to use “cheap labor” to staff new teams. Why? If you can afford a team of above average engineers, the speed of coding is most likely going to be well above average. These guys will have a profound understanding of quality code [3] and nothing will be holding back the team from becoming very, very efficient. This is why I am convinced that any investments made in enough above average programmers to set up a team, for arguments sake say 15 Euro more per hour than average pay, will be worth your money.

People over process, but still process // quality in communication processes
The following seems to happen quite often. At the start of an important project the project leader organizes a team kick off; somehow he fails to explain and discuss the communication lines you have with your client. This can be risky. Team members might be losing precious time in unstructured discussions about what is required. They contact the wrong people, or the right people with the wrong questions, or the right people and questions but at the wrong time. Delays and unclear requirements will pile up. In no time any team will feel the urge to improve on these processes and will hopefully do so. Yet, at a time where projects are getting smaller and customer expectations only bigger, the need for clear communication from the start is paramount. Yes even in Agile & Scrum you need to have this well organized. Quality in communication processes is often an underestimated factor in software engineering. Potentially it is one of the biggest drains and wastes of energy and time [4]. So take a little time to establish clear ground rules for interacting with your Product Owner and client.

Pipelines and usage // quality in deployments pipelines
In the not so distant past, 10 years ago, it was state of the art to have an automated build in place. By having these in place, your code would be compiled and unit tested every night. In the last few years the continuous-x-movement has provided us with numerous tools and platforms in which almost every step of the software process can be automated. There is no argument left to Not implement the smallest feedback cycle possible for programmers as described in chapter 5 of the CD Bible. But, better yet also for Product Owners and clients. Programmers can get their direct feedback on their code check in, based on coding guidelines, pre written acceptance tests. Enabled by the continuous deployment [5] on specific environments, Product Owners and clients can actually experience how new code – the newest version of the product – is working, and how the UX design looks and feels. If these benefits are so huge, why don’t all projects use them already? Well, setting up a build pipeline takes time and requires knowledge of infrastructure and a lot of tools. Large companies have dedicated teams to set up and maintain these pipelines, so development teams can focus on actual software. Smaller companies may well be helped by CD consultants helping them, and in doing so increasing the quality of their delivery process. But even for smaller projects it is still well advised to do so. Not convinced yet? Check out Jez Humble’s post and Poppendieck’s “Lean Software Development”[6] and come back if you are still having second thoughts.

Conclusion

As you might have noticed, I am convinced about the enormous role a quality-in-everything approach can have in software projects. Quality on all levels but also the right level of quality for a specific project. The examples mentioned above will obviously not hold for some demo projects in which a only new design needs to be demonstrated. However, the moment you are starting a new project or team (or redefining existing ones), that is the time to think and design your strategy based on a good quality approach and implement as good as possible right from the start. Take a look at some of the points below and ask yourself if your project is sufficiently equipped:

• Team mission is clear and shared
• Enough talented engineers
• You (as manager), the team and your customer agree on a realistic planning
• Communication process is clear
• Team & customer are aligned on strategy
• Continuous delivery pipeline set up
• Releasing goes without stress
• Code quality is measured and good
• Delivery keeps a steady pace
• When finishing a project no skeletons are found

This list can go on and on of course. Remember nothing is set in stone, but a good start can provide a necessary jumpstart for a successful project.

Cheers,
– Sjors Meekels