Archief Portfolio - agile4all

Tech & More

Peter — Fri, 07 Dec 2018 15:00:01 +0000

Leestijd: 3 min.

In Tech & More beschrijf ik alles wat ik interessant vind voor de bezoekers van agile4all.nl

Hoewel ik op termijn over veel verschillende onderwerpen zal schrijven, focus ik mij op verhalen die op de een of andere manier verbinding met agile maken.

Achtergrond

Ik ben zeer geïnteresseerd in populair wetenschappelijk nieuws en artikelen over natuur, ruimtevaart, biologie, innovatie, duurzaamheid en technologie. Ieder zijn tech & more hobby zal ik maar zeggen. Wat voor jou van belang zou kunnen zijn, is dat veel ontwikkelingen op (korte) termijn impact gaan hebben op jouw business en agile werken.

Ik weet dat hier hele leuke haakjes zijn om interessante verhalen te schrijven. Vanzelfsprekend passen een aantal achtergrondverhalen beter bij agile dan andere onderwerpen. Helaas zal er niet altijd een enorme wetenschappelijke diepgang kunnen worden geboden. Jammer, maar wat ik beoog is dat je het leuk of interessant vindt om het artikel te lezen. Misschien word je zelfs getriggerd om meer te willen weten over een onderwerp welk ik beschrijf. Vooral als je door het artikel mogelijkheden ziet voor jouw organisatie.

Science

Hoewel agile werken heel recent lijkt en vrij losjes overkomt, herkende ik direct de onderliggende wetenschappelijke basis. Dit zal ik later verder onderbouwen. Om het heel herkenbaar te maken: agile lijkt op een vernieuwde vorm van de PDCA cyclus (Plan, Do, Check en (re)Act).

Science Fiction

Agile werken vergelijk ik met een volgende stap in de evolutie van mensenwerk. Agile werken is een mooie stap vooruit, maar ook deze stap zal gevolgd worden door een volgende stap. Degene die denkt dat agile een oneindige levensduur heeft, wil ik het volgende meegeven. De eerste verbinding tussen mens en machine is al gemaakt, een mens met een echte robotarm kan via internet op een ander continent een andere robotarm laten werken. Ook wordt een robotarm door chirurgen al ingezet voor operaties. Dit lijkt nu nog een detail, maar wat gebeurt er als een deel van de mensheid ‘cyborg’ gaat. Ik weet het niet, dan lijkt het net Science Fiction. Ik kan de link met agile dan nog niet overzien.

Back to reality

Wat ik wel zie is dat binnen agile werken het samenwerken met en binnen teams van groot belang is. De moderne technologische mogelijkheden maken het al mogelijk om teamleden werkzaam op verschillende plaatsen tegelijkertijd met verschillende devices als 1 team te kunnen laten functioneren. Ook dan is onderling contact en teamspirit doorslaggevend. Dit vinden we eigenlijk al heel gewoon, maar dat was een aantal jaar geleden nog ondenkbaar.

En dat is waarom ik het zo interessant onderwerp vind. Balancerend op science, science fiction en een vinger op de pols voor realiteitszin.

**Technologie (tech & more)**

Toch zijn er ontwikkelingen die op (korte) termijn impact kunnen hebben op jouw business. De onderwerpen die ik op korte termijn ga beschrijven vallen binnen het kopje technologie.

Omdat agile ontstaan is vanuit de IT heb ik een aantal belangrijke technologische ontwikkelingen in mijn vizier. Deze ontwikkelingen zullen vaak de drivers van snelle verandering zijn. En snelle verandering legt de basis voor het toepassen van agile methodes. Een aantal onderwerpen hieronder passen vanzelfsprekend heel goed bij agile werken, omdat deze nu al grote stappen maken en tot grote veranderingen zullen leiden.

Welke artikelen zijn beschikbaar:

Blockchain
Artificial intelligence
11 voordelen van Agile software ontwikkeling
Wat is UX – User Experience?

Wat ik ook interessant vind is o.a.:

Virtual Customer Assistent of Chatbot
Data science

Ik beloof nog niets, maar het is wel leuk om hier over te schrijven.

More (tech & more)

Dit wordt voor mij ook een ontdekkingsreis. Ik kom veel interessante onderwerpen tegen, waar ik graag door een Agile bril naar wil kijken en over schrijven. Een plek waar ik o.a. interessante boeken bespreek, maar ook zaken die vragen om veel deskresearch en dieper graven dan wellicht bij deze site past en/of tijd beschikbaar is. Ik zie het als een topping op een Agile ijsje. Het ijsje wordt er echt lekkerder door, maar de basis blijft de smaaksensatie van het ijs. Kijk zelf maar of er wat voor je bij zit.

Wat er zeker bij hoort zijn boek reviews, deze staan hieronder en er worden regelmatig nieuwe toegevoegd.

Boek reviews:

Het bericht Tech & More verscheen eerst op agile4all.

Agile

Peter — Thu, 06 Dec 2018 15:32:01 +0000

Leestijd: 9 min.

Onder de agile paraplu passen veel verschillende agile methodologieën. Deze beschrijf ik hier, maar ik start met de management uitdaging.

Wat beoogt dit artikel?

Dit artikel behandelt het begrip ‘agile’. De bedoeling van dit artikel is een totaaloverzicht te creëren. Het wordt dus een omvangrijk artikel, waar de meeste zaken in beschreven zullen worden. Elke keer als er een verdiepend artikel klaar is, vind je een link daar naar toe.

Dit artikel bestaat uit 5 delen:

De management uitdaging
De agile methodologieën
Metrics
Boekreviews
Modellen

Heb je weinig tijd dan adviseer ik je Agile in 3 minuten.

Wil je eerst meer lezen waarom Agile werken relevant is? Dan verwijs naar het artikel: Agile in historisch perspectief.

Hier lees je: Wat is een Agile Coach?

1. Agile denken

De basis van Agile denken is gelegd door IT professionals met het Manifesto for Software Development in 2001. Daardoor werd agile tot voor kort gezien als een set van management tools voor IT toepassingen. In 2016 verschenen er berichten in Harvard Business Review en van McKinsey, dus na een periode van 15 jaar werd dit gedachtegoed breed gedeeld, erkend en bleken er ook andere niet IT-toepassingen mogelijk.

In het artikel ‘agile in historisch perspectief’ beschrijf ik hoe deze basis vanuit de IT is ontstaan.

De groei van agile lijkt niet te stuiten, het is inmiddels een wereldwijde methodologie. Organisaties willen ‘continue veranderen’ bewerkstelligen. Dit om te reageren op sterk veranderende markten, onzekerheid, complexiteit, maatschappelijke en technologische ontwikkelingen etc.

1.1 Consequenties agile gedachtegoed.

Het bijzondere is dat de IT-specialisten die het Manifesto hebben bedacht, zich niet konden voorstellen welke impact hun filosofie op organisaties zou hebben. In de lange aanloopperiode is veel geëxperimenteerd en zijn zeer veel vragen beantwoord. Zoals hoe moet een agile organisatie er uit zien? Hoe zien de werkplekken eruit? Hoe werkt men samen? etc. etc.

Veel agile variaties zijn bedacht. Vaak waren de variaties in praktijk min of meer gelijk, maar kregen ze verschillende benamingen. De succesvolste variaties zijn vaak opgenomen in of gegroeid naar de huidige bekende methodologiën. Dit is meteen ook de reden waarom voor buitenstaanders ‘agile’ zo lastig te overzien is. Zelfs voor agile specialisten van het eerste uur was het moeilijk om het agile landschap blijvend te overzien.

Uiteindelijk werd helder wat wel en niet werkte. Een gedefinieerde set van doelen, principes en values bleek duidelijk productiever en de klantbehoefte beter te bedienen dan traditioneel management. De echte doorbraak van agile kwam naar mijn mening met het schaalbaar maken van de methodieken. De technische oplossingen voor het opschalen van agile werken waren er al, maar waren vaak nog gelimiteerd in het aantal mensen die tegelijkertijd in de agile projecten werkten. tevens bleek het management met een been in het ‘oude denken’ te blijven staan.

Totdat bedrijven als Spotify, Google en Netflix kozen voor een volledige agile organisatie.

In 11 voordelen van Agile Software ontwikkeling ga ik hier dieper op in.

1.2 Top management kiest voor Agile.

Dat hippe, trendy en uiterst inspirerende bedrijven kozen om agile te gaan werken bracht een schokgolf in de management gelederen. Er bleek een radicaal andere oplossing te zijn om als organisatie te reageren op de steeds sneller veranderende maatschappij.

In 2016 bracht McKinsey & Company de Global Agility Hackaton, waar 1500 online senior leiders tot een eensluidende conclusie kwamen. ‘ontwerp een geheel nieuw, agile organisatie architectuur en cultuur’. Mooie conclusie, maar je vraagt dan veel van een management die gewend is top-down te denken en te handelen.

Er zijn daarna talloze onderzoeken geweest. Hieruit bleek dat veel organisaties die aangeven ‘agile’ te zijn en zelfs agile werkwijzen hadden ingevoerd, in werkelijkheid nog steeds een top-down structuur hanteerden. Andere organisatie bleken echter volledig overgestapt te zijn naar agile at scale. Hanteerden agile doelen en bleken de principes en waarden volledig geïmplementeerd te hebben.

1.3 Huidige stand van zaken

Inmiddels weten wij dat dingen als: het agile inrichten en het hanteren van de juiste methodologie en bijbehorende stappen en tools belangrijk zijn. Daar wordt ook het meest over geschreven: gereedschappen, processen, methodes, technologie, platform, big data etc.

Mensen bepalen het succes van agile! Dit is veel belangrijker dan de ‘dingen’.

Het zijn de doelen die mensen inspireren, de open mindset over hoe de wereld werkt, hoe je samenwerkt, de gedeelde waarden en samen communiceren.

Zonder agile mindset, gereedschappen en processen bereik je weinig.

1.4 Uitdagende implementatie

je doet geen agile, je bent agile!

Stel! Je bent al jaren lang manager die top-down werkt. Opeens hoor je dat deze werkwijze achterhaald is. De basis van wat je weet, kent en jouw jarenlange managementervaring wordt weggeslagen. Je emotie schreeuwt naar je: doe wat!

Veranderingen gaan zo snel dat jij en jouw organisatie snel moet veranderen. Je weet al lang dat er geen ontkomen aan is, maar hoe ga je hier echt mee om? De symptomen zijn duidelijk. In je MT-sessies is al besproken dat het moeilijk is om talent aan jouw organisatie te verbinden. Ze hebben geen zin om in een ‘ouderwetse hiërarchische organisatie’ te werken.

Een hypothetische vraag; ‘ bereik jij als manager meer dan 100 vrijdenkend handelende medewerkers?

Wat het nu echt lastig maakt voor managers is dat het geen methodologie of proces is wat je kan implementeren in de huidige organisatie. De ‘agile way of working’ herdefinieerd het organisatie concept welk ruim een centennium gehanteerd is.

Je vraagt een organisatie om te schakelen van een efficiënte productiemachine naar een groeiende, lerende, levend organisme die constant nieuwe mogelijkheden oppakt en nieuwe waarden brengt voor de klant. Agile gaat uit van dat degene die het werk doen, geïnspireerd moeten worden om vernieuwing te versnellen om werkelijk toegevoegde waarde voor klanten te creëren.

1.5 De basis van alle Agile concepten.

I.p.v. een top down benadering geeft agile werken medewerkers autonomie in zelfsturende teams met ruime bevoegdheden en beperkte controle. De waarden transparantie en voortdurende verbetering staan boven voorspelbaarheid en efficiency. Het erkend de waarde van open interactieve gesprekken. Er wordt gestopt met alles wat geen waarde voor klanten oplevert en dat sneller werken ondergeschikt is aan slimmer werken. Slimmer werken levert meer waarde op met minder werk (kosten).

Wanneer agile werken goed wordt toegepast werken alle bedrijfsonderdelen aan het toevoegen van waarde voor klanten. Dit levert meer werkplezier en voldoening op voor de medewerkers, maar levert ook inkomsten op voor de organisatie.

Als agile coach en voormalig manager geloof ik dat agile in de basis een betere manier is om een organisatie te runnen. Het is beter voor de mensen die het werk doen, levert meer waarde voor de klant en is beter voor onze maatschappij.

2. De agile methoden.

In dit deel behandel ik de meest voorkomende agile methodes en agile frameworks.

Handig om eens door te lezen om te beoordelen welke methode(n) het best bij jouw organisatie past. Ik zal de omschrijving van methoden in de loop der tijd verder verdiepen. Nu volsta ik met een het beschrijven van de kernmethode of ik verwijs je naar een ander artikel.

2.1 Agile paraplu

In voorgaande alinea heb ik beschreven wat de basis vormt van alle agile concepten. Dat beschrijf ik niet nogmaals. Ik vat dit samen door te verwijzen naar het agile manifest in het Nederlands.

Hou vast dat de agile principes en values voor alle agile methodes gelden.

2.2 Scrum

Hiervoor verwijs ik je naar mijn uitgebreide artikel: scrum framework

2.3 Extreme Programming (XP)

Een andere veel voorkomende Agile methode is Extreme Programming. In deze systematische software methode zijn er twee partijen: de klant en de ontwikkelaars.

De klant geeft de belangrijkste wensen aan voor een nieuw software product d.m.v. testimonials. De ontwikkelaars leveren elke paar weken een verbeterde set software o.b.v. de verkregen informatie en gaan continue door met innovatie.

XP werkt het beste met kleine teams van zeer ervaren developers, die ook nog goed zijn in communicatie en (zelf)management.

De overeenkomst met Scrum is dat beiden een korte doorlooptijd (iteratie) hebben voor het opleveren van gezamenlijk werk ,die betrokkenheid van managers vraagt en er continue getest wordt.

2.4 Feature-Driven Development (FDD)

FDD hanteert strikte procedures waarin de developer centraal staat.

In tegenstelling tot XP en Scrum is er een vastgestelde procedure waarin bijvoorbeeld design, code en inspectie wordt doorlopen.

Eerst wordt er een wensenlijst samengesteld. De kenmerken van elke wens (features) worden in een ontwikkel en designplan opgenomen. Daarna volgen de inspecties, zoals een unit test om te beoordelen of de feature klaar is om gebouwd te worden.

FDD vereist vervolgens een strikte organisatie van het bouwproces. Het doel is betrouwbare software die op continue basis geproduceerd kan worden. Het positieve aan deze methode is dat er zeer goede documentatie en goede (design)testen plaatsvinden. Het nadeel is echter dat deze methode een zeer hoge mate van deskundigheid vraagt, zoals design, planning en foutherstel. Zoals je begrijpt is deze methode niet voor iedereen geschikt, het is te overwegen voor organisaties waar volwassen ontwikkelprocessen de standaard zijn en kwaliteitscontrole verplicht is.

2.5 Chrystal Methodologie

De Chrystal methode bestaat uit een hele familie kleine agile methoden. Men hanteert benamingen als Chrystal clear, Chrystal red, Chrystal yellow, etc.

De overeenkomst tussen al deze Chrystal methoden is dat deze geïntroduceerd zijn door een van de ondertekenaars van ‘het agile manifesto’. Net als de andere agile methodes, stuurt Chrystal op snelle oplevering van werkende software. Hoge frequentie, hoge betrokkenheid van gebruikers en minder bureaucratie.

Deze methode werkt met 3 hoofdthema’s: grootte van het team, hoe belangrijk het systeem is voor de organisatie en prioriteiten binnen het project. In het begin bepaald met eerst het belang van het systeem. Crystal hanteert 4 niveaus: Comfort ( C ), Discretionary Money ( D ), Essential Money ( E ) en Life ( L ).

Het maximum aantal mensen wat betrokken wordt bij het project is afhankelijk van het belang en grootte van het project, daartoe hanteert men groepsgrootte van 1 t/m 6, 6 t/m 20 etc. etc. personen. Het belangrijkste om hiervan te begrijpen is dat het aantal verschillende rollen in het project afhankelijk is van de projectgrootte. De kernwoorden bij deze methode zijn: interactie, mensen, community, vaardigheden, communicatie en talent.

Chrystal wordt vaak gezien als een ‘lichte methode’ binnen de agile methodes. Dit komt door het uitgangspunt dat elk project uniek is en om andere technieken, processen en werkpraktijken vraagt.

2.6 Kanban

Kanban is een veel gebruikte methode. Ontwikkelt als een planinstrument voor lean productie bij Toyota. Kanban sluit heel goed aan bij Lean, maar het is tegelijkertijd ook een zeer agile methode. Veel meer agile dan de meeste mensen denken.

Kanban is veruit het meest bekend vanuit het just in time (JIT) productie. Het faciliteert dan ook productie en controle op voorraden. Kanban is een zeer krachtige methode om verbeteringen te bewerkstelligen in totale productie systemen. Het belangrijkste om nu te delen is dat deze methode zich richt op het beperken van de hoeveelheid onderhanden werk. Werk wat niet is afgerond, zorgt voor haperingen in de productieketen. Kanban helpt met het verkrijgen van strakke productieprocessen.

Organisaties die de Kanban methode gebruiken richten zich op Continued Delivery. Kanban gaat uit van 3 principes:

Visualiseer wat je doet, alle items staan met elkaar in verband.
Beperk de hoeveelheid werk in uitvoering (WIP=Work in Progress), er is sprake van een ‘flow-based’ benadering. Focus je op de flow, doe dus niet alles tegelijkertijd.
Verbeter de flow: zodra een taak klaar is start je de volgende die als hoogste op de Backlog staat.

De Kanban methode staat voor continue samenwerking van team met de klant. Continue leren en verbeteringen doorvoeren om de beste workflow voor het team mogelijk te maken.

Voor het volledige verhaal: Wat is Kanban?

2.7 Lean

Over lean bestaan veel misverstanden. Om deze meteen maar duidelijk te maken:

Lean is agile, maar agile is geen lean. Huh? Net als scrum is agile, maar agile is geen scrum. Wat ik daarmee wil zeggen is dat ze veel overeenkomsten hebben en dat lean onder de agile paraplu valt.

Lean staat voor Lean manufactoring. Dit is een set van management principes om waarde en efficiency in productieprocessen te waarborgen. Lean is in de 50-er jaren ontstaan. Ver voordat het agile manifesto werd geschreven (2001).

Oorspronkelijk bestond lean uit 5 principes: Identify Value, Value Stream Mapping, Create Continious Workflow, Create a Pull System en Continuous Improvement.

Dit is door agile software developers aangepast en deze systematiek heet tegenwoordig Lean Software Development. Binnen Lean Software Development hanteert men de principes: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect for people and optimize the whole.

Maar er zijn ook al weer varianten als Lean, Six Sigma and Lean Six Sigma.

Lean denken moedigt organisaties aan om alle praktijken die vooruitgang belemmeren te verwijderen en een strategie te ontwikkelen voor elk vraagstuk.

Lean is een belangrijke methode en het totaalproces is beschreven in het artikel Lean.

2.8 Scaling

Voor Scaling zijn meerdere mogelijkheden. Scrum Nexus , Scaled Agile Framework- SAFe zijn beschreven. Binnenkort volgt: FAST.

3. Wat is de beste agile methodologie?

Nu vraag je vast af: wat is nu de beste agile methode? Daar is geen standaard antwoord op te geven. Elke agile methode bedient een deel van de verschillende vraagstukken. De keuze die je maakt is volstrekt afhankelijk van je huidige organisatie cultuur en de visie die je hebt op de toekomst. Wat wel duidelijk is dat het hanteren van een agile methode nieuwe niveaus van flexibiliteit en productiviteit mogelijk maakt.

4. Metrics

Metrics ondersteunen agile werken. Meer weten over metrics?

5. Boek reviews

6. Modellen

Het bericht Agile verscheen eerst op agile4all.

Lean

Peter — Thu, 06 Dec 2018 07:56:01 +0000

Leestijd: 12 min.

Lean, Six Sigma en Lean Six Sigma zijn agile methodes om verbeteringen in een organisatie te bewerkstelligen.

Dit artikel biedt een totaaloverzicht van Lean. In een eenvoudige schrijfstijl probeer ik dit complexe onderwerp volledig te beschrijven. Ik schrijf vanuit een breed perspectief naar steeds meer detail informatie. Het is een heel lang artikel. Het is bedoeld als vertrekpunt van een mooie reis, met als doel: de agile werkmethode Lean Six Sigma beter te begrijpen.

Heb je weinig tijd en wil je binnen een paar minuten een korte samenvatting lezen? Ik heb ook een artikel: lean in 3 minuten. Wil je heel gestructureerd lean beter willen begrijpen? Lees dan verder, want deze tekst zit vol met verwijzingen/links naar specifieke onderdelen van Lean en andere methodieken. Neem je tijd, een Black Belt gecertificeerde volgde eerst een aantal andere trainingen voordat hij/zij een full time black belt training van ruim 2 weken krijgt en dan een zwaar examen doet.

Noot voor de lezer

Dit artikel is ‘under construction’ Ik heb mijn best gedaan om alvast een stevige basis te leggen, maar dit artikel is helaas nog niet compleet. Op termijn staat het volledige lean six sigma verhaal in dit artikel. Ik zal dan voorbeelden, plaatjes en allerlei links aanbrengen. Ik heb besloten om mijn concept toch te publiceren. Alvast bedankt voor je begrip.

1. Lean

Door het ruime aantal synoniemen voor deze methode, zoals Lean, Lean management, Lean manufacturing. Lean methode, Lean filosofie etc. kan dit best verwarrend overkomen.

Ik start dan ook met het uitleggen van de 3 meest gebruikte beschrijvingen: Lean, Six Sigma en Lean Six Sigma.

1.1 Lean

Lean is een agile werkmethode. Lean richt zich primair op de werkwijze om een soepele proces doorvoer in een organisatie te bewerkstelligen. Het bestaat uit een verzameling van bewezen standaard werkwijzen en bewezen oplossingen.

De focus van Lean ligt op het beheersen van doorlooptijden en het verbeteren van efficiency. Zoals het reduceren van menskracht, optimaliseren van rendementen van machines, beoordeling van de bezettingsgraad, eliminatie van niet aan winst bijdragende activiteiten en reductie van belegd kapitaal in voorraden. Door deze ‘harde’ benadering ontstond al snel ‘lean is mean’.

Door het management werd lean vertaald als ‘winst’, terwijl het soms als ‘mean’ werd ervaren door de medewerkers. Eigenlijk komt dit doordat het management Lean als strategie inzette i.p.v. methodologie. Strategie, omdat men zich alleen richtte op het resultaat en de mens als minder belangrijk beschouwde. Terwijl de mens de verbetervoorstellen moet aandragen en met de doorgevoerde verandering gaat werken.

In het artikel de 5 principes van Lean beschrijf ik op eenvoudige wijze waar Lean op gebaseerd is.

Men kwam tot de ontdekking dat Lean te beperkend is, omdat de focus van lean ligt op standaard verbetermogelijkheden in de procesdoorvoering. De mogelijkheden van lean om te analyseren en een goede diagnose te stellen schieten te kort. Want als het echte probleem niet in de procesdoorvoering ligt, wordt de procesdoorvoer wellicht verbeterd, maar worden mogelijk grotere problemen niet (h)erkent.

1.2 Six Sigma

Six Sigma is een raamwerk om continue verbetering (continues improvement) in een organisatie tot stand te brengen. Six Sigma bestaat uit twee delen: systematische vernieuwing en het verbeteren van routines. Dit gebeurt door het creëren van een organisatiestructuur en managementmodel, waarin verbeteren een systematische routine wordt.

In tegenstelling tot Lean is Six Sigma een methode waar wel een organisatie brede diagnose kan worden gesteld. Het is een methode waarin prestatie indicatoren worden gezocht en bepaald, waarop volgens een op data gebaseerde conclusie volgt. De daarop volgende stap is een diagnose (gebaseerd op data) waarin de mogelijkheden om te verbeteren worden bedacht. Deze verbetermogelijkheden worden in de praktijk getoetst en indien ze bijdragen in de lijn gebracht.

Six Sigma maakt gebruikt van veel statische technieken uit de industrie en kwaliteitsleer. In het artikel: Wat is de Six Sigma methodiek? lees je meer.

1.3 Lean Six Sigma

De bewoording zegt het al, het is een integratie van Lean en Six Sigma.

Six Sigma brengt de analyse-, diagnose methodieken en organisatiestructuur aan. Lean wordt gebruikt om procesdoorvoer te verbeteren, wanneer dit het belangrijkste probleem is. Voor de meeste andere problemen wordt Six Sigma gehanteerd. Kortom, het beste van beide werelden.

Lean Six Sigma hoeft zich inmiddels niet meer te bewijzen als belangrijke methode. Inmiddels hebben duizenden organisaties door het inzetten van Lean Six Sigma verbeterslagen doorgevoerd en zijn ze er krachtiger door geworden. Dat deze methode zo succesvol is komt met name doordat bewezen economie, statistiek, kwaliteits- en organisatieleer en onderzoekmethodes de grondslag vormen.

2. Waarom kiest management voor LSS?

Eigenlijk weet je dat wel. Door het toepassen van LSS zijn de productiekosten lager. LSS levert ook goede producten tegen een lage prijs! Kortom, het toepassen van LSS leidt tot lagere kosten. Wil je als organisatie overleven moet ook jouw proces lean zijn. Uiteindelijk zullen vrijwel alle spelers in een markt mee gaan doen, daarmee leiden de lagere kosten veelal tot een lagere prijs voor de eindconsument.

Kortom, je hebt als organisatie niet echt een keus om door te gaan met processen die niet soepel lopen. Anders loop je achter met Operational Excellence en loop je een serieus risico op een concurrentienadeel. De Lean-adepten zeggen dat LSS de enige juiste keuze is, dat is natuurlijk flauwekul. Elke situatie is uniek, elke keuze voor een methodiek moet gefundeerd zijn op onderzoek en aansluiten bij de mogelijkheden van en voor de organisatie. De wijze waarop Lean Six Sigma omgaat met het verbeteren van de effectiviteit en efficiency van processen is echter een bewezen methodiek.

Gaat het dan vanzelf? Natuurlijk niet! Met het benoemen van LSS projecten ben je er niet. De projecten moeten geïntegreerd worden in een strategie. En binnen de strategie moeten focuspunten zijn. Lean vraagt net als alle andere agile methodieken om leiderschap. Want dat is LSS namelijk ook, de bijdrage van de medewerkers bepaald in hoge mate het resultaat.

3. De verander uitdaging

Elke organisatie verkrijgt zijn bestaansrecht door te weten wat klanten willen, hiertoe de technische vaardigheden te hebben en de benodigde processen te kunnen managen.

Een veranderproject komt vaak niet goed tot stand. Daar zijn een aantal redenen voor te benoemen:

De projectleiders zijn niet vaardig genoeg, omdat ze teveel detailkennis beschikken of juist te weinig contextkennis.
De focus ligt niet op de juiste problemen, redenen hiervoor zijn wisselend. Voorbeelden: stokpaardjes, niet helder, onoplosbaar, denken te weten wat goed is voor de organisatie.
De hiërarchie, bastions, koninkrijken en/of persoonlijke agenda’s.
Mijn persoonlijke ervaring is dat vaak de visie of het toekomstbeeld te ver weg ligt. Of wel de te volgen stappen op weg naar het toekomstbeeld zijn niet duidelijk verteld. Medewerkers herkennen dan vaak alleen de bedreiging op korte termijn en niet de kansen op lange termijn. Waardoor medewerkers zich vastbijten in de bedreigingen i.p.v. de kansen.

Bovenstaande redenen zijn min of meer universeel voor veranderprojecten en niet specifiek voor LSS. Het inrichten van een LSS organisatie beschrijf ik in het volgende hoofdstuk.

4. LSS organisatie

4.1 De introductie van Lean Six Sigma in de organisatie.

Topmanagement en programmamanagement hebben beide een rol in het uitdragen van LSS als de gewone manier van werken.

Heldere visie en betrokkenheid van topmanagement
Lean Six Sigma organisatie programmamanagement
Training en projectondersteuning
Aanpassing HR-beleid
Integratie in ‘alles wat we doen’
Informatietechnologie
Start van de eerste training.

Na training zal een ander taal gehanteerd gaan worden: ‘de verborgen fabriek’ , SPC, Waste, DMAIC, Data. Dit zijn echter randvoorwaarden, het gaat erom dat de organisatie echt kantelt naar een LSS organisatie. Waar teams gaan voor continue verbetering.

Bovenstaande zijn management stappen die moeten plaatsvinden. Moet gebeuren, maar essentieel is hoe je de medewerkers meeneemt in dit proces.

4.2 Effect op de medewerkers

Voor het management is het belangrijk om zich niet alleen te richten op de directe voordelen van LSS (effectiviteit en efficiency). Het gaat ook hier om mensen die het proces laten draaien. Het gaat dus om competenties en bekwaamheden. Van iedereen in de organisatie.

Voor LSS wordt een groot deel van de medewerkers getraind om de vaardigheden van effectief creëren en kennis te benutten. Elke medewerker heeft detailkennis van het proces. Vaak is er ook sprake van veel verborgen kennis. Bijvoorbeeld hoe dingen echt werken. Deze specifieke kennis vraagt om beslissingen die zo laag mogelijk in de organisatie liggen. (herken je de agile methodiek?)

Medewerkers leren data te verzamelen, te analyseren en op basis daarvan een beslissing te nemen. Dit herken je gegarandeerd als agile werken: teams bereiken samen doelen. Het grote voordeel is dat je als medewerker weer in staat bent om een echte bijdrage te leveren. Daardoor willen ze werk goed doen en willen ze zichzelf en het proces steeds verbeteren.

Dat leidt voor de organisatie vaak tot een Structural Competitive Advantage, een duurzaam concurrentie voordeel. Maar ja, in een snel veranderende wereld is weinig structureel, zeker niet als iedereen zich voortdurend aanpast.

Medewerkers kunnen LSS alleen optimaal toepassen als de organisatiestructuur LSS en agile werken ondersteunt. Dat de lijnmedewerkers vanaf het eerste moment betrokken zijn is vanzelfsprekend, zij weten ook alle kleine belangrijke details en moeten uiteindelijk met de oplossing gaan werken na acceptie van het opgeleverde.

4.3 Prioriteit van projecten en betrokkenen

De volgorde van LSS projecten:

Projecten worden voorgesteld door mensen met projectkennis.
Projectvoorstel wordt geratificeerd door Champions die de voordelen kunnen beoordelen binnen het grote geheel.
Projecten worden uitgevoerd door mensen die de bijzonderheden kennen.
De voortgang wordt bewaakt door de Champion in de vorm van periodieke beoordelingen (reviews).

De Champion is iemand uit het senior management die het grote geheel overziet. De Champion bepaald WAT verbetert moet worden en de Green en Black belts houden zich bezig met HOE ze dat doen.

4.4 Who is afraid of yellow, green and black belts?

Als je het hebt over LSS is een vaak gestelde vraag: welke belt heb je? Daarom leg ik uit wat de kleur van de belt (band) zegt over de vaardigheden van project betrokkenen. Dat brengt mij bij de kleur van de ‘belts’: Yellow, Green en Black.

Lean komt oorsponkelijk uit de Toyota fabriek in Japan. Japan is de bakermat van een aantal vechtsporten, bij vechtsporten duidt de kleur van een band een bepaald niveau aan. Even off topic. Het bijzondere is dat men in Japan jaren trainde om van een witte band naar een bruine band te gaan, er werden niet allerlei tussenniveau kleurtjes gehanteerd. Dat is een westerse uitvinding, omdat westerlingen niet jaren willen trainen zonder tussentijdse vooruitgang aan anderen te tonen. Weer on topic.

Het niveau per kleur:

Master Black Belts: programma management. (ervaren BB’s)

Black Belt: project management en uitvoering. (Academisch-/HBO–niveau)

Green Belt: projectondersteuning, projectmanagement en uitvoering (MBO-niveau)

Yellow Belt: projectondersteuning. Vaak de overige deelnemers binnen de organisatie.

4.5 Competenties black belt

Wanneer heb je de juiste competenties? Als je dan kijkt naar personeelsadvertenties wordt het interessant, de advertenties kunnen onderling behoorlijk verschillen in bewoording. Maar duidelijk is dat men zoekt naar het schaap met de bekende 5 poten. De black belt is een theoreticus, scepticus, creatieveling, onderzoeker en doener.

Feitelijk zegt men: beschik jij over bovenstaande competenties? Dat is voor ons een eis. Maar wat er vaak niet letterlijk staat is : ‘ik ben op zoek naar iemand die weet dat theorieën niet in steen gebeiteld staan en bereid is deze te toetsen en indien nodig aan te passen aan onze unieke situatie.’

Als je dat als Black Belt kunt:

Dan heb je het juiste niveau van training en ervaring opgebouwd
Begrijp je jouw rol
Beschik je over de gereedschapskist met de juiste tools.

De basisbegrippen van LSS

In dit hoofdstuk start ik voorzichtig met de basisbegrippen van LSS. Ik beschrijf de verborgen fabriek, kosten en baten en kwaliteit.

5.1 Verborgen fabriek

In de lean methodiek komt het begrip: ‘de verborgen fabriek’ regelmatig terug. verborgen fabriek: alles in de operatie van een organisatie wat niet in één keer goed gaat.

In de verborgen fabriek vindt je kosten en baten. Alles wat niet in één keer goed gaat levert extra kosten en/of minder baten. Dat is ‘waste’ en eerder in dit artikel heb ik aangegeven dat LSS zich met name richt op het voorkomen van ‘waste’.

Nu zal ik de kosten en baten verder toelichten.

5.2 Kosten

In kwaliteitsmanagement noemt men dit kosten van slechte kwaliteit. Jawel, het zijn substantiële kosten. Doordat veel producten steeds gecompliceerder worden neemt het aantal processtappen toe, hierdoor kunnen kosten snel oplopen.

Hiermee wordt ook bedoeld dat een (productie)manager van een proces zich focust op in de invoer, het uitvoeren van de processtap en het verschepen naar de klant ziet als het volledige bedrijfsproces. De verborgen fabriek staat dan bijvoorbeeld voor uitval (waste), verspilde grondstoffen, extra mankracht, extra klachtenafhandeling etc.

De oplossing is dat je de verborgen fabriek aanpakt door te investeren in mankracht en middelen. Dat lijkt te leiden tot nog meer kosten, maar het verdient zich terug. Want waar zijn de baten?

5.3 Baten

Veel processen bestaan uit opeenvolgende routines, zoals productie, administratie, sales etc. LSS heeft tot doel deze routines te verbeteren. Het doel is probleemloze processen.

Iedereen herkent het ‘brandjes blussen’. Het toepassen van ad-hoc oplossingen voor herhaalde problemen. Vaak ontstaan deze problemen doordat er in het verleden toevoegingen op het proces zijn geweest. Het huidige productieproces is dan een opstapeling van voorgaande toevoegingen. Een doorlichting van het proces is een zoektocht naar optimalisering, elimineren van verspillingen en een juist aantal FTE. Veelal leidt een zorgvuldige gestructureerd onderzoek naar een substantiële reductie van kosten.

Dat binnen de interne organisatie gezocht wordt naar kostenbesparingen spreekt voor zich. Maar baten komen ook uit klanttevredenheid. Een beter product met minder fouten leidt mogelijkerwijs tot een groter marktaandeel, inkomsten of premium pricing.

LSS kijkt ook naar sales, marketing, financiën, HR etc. Overal waar routineprocessen zijn, kan LSS een bijdrage leveren.

Samenvattend: de directe baten van LSS zijn klanttevredenheid en kostenreductie.

5.4 Wat is kwaliteit?

Er zijn veel definities van kwaliteit, maar laat ik het simpel stellen: voldoen aan de behoeften van de klant. Kwaliteit bereik je door het hele huis op orde te krijgen. Volgens de leer van LSS staat vast wat dan goed ingeregeld moet worden. Dit zijn kwaliteitsplanning, kwaliteitsbeheersing en kwaliteitsverbetering.

5.4.1 Kwaliteitsplanning

Kwaliteitsplanning is het voldoen aan de behoeften van de klant, door producten en processen te ontwikkelen die aan deze behoeften voldoen. Deze opdracht wordt belegd bij een gespecialiseerde afdelingen die Design for Six Sigma hanteert. E.g. marketing, product- en procesontwikkeling.

Bij veel bedrijven spreken ze over kwaliteitsverbetering terwijl ze eigenlijk bezig zijn met kwaliteitsbeheersing. Hoewel dit veel lijkt op een semantische discussie is dit verschil binnen LSS van extreem groot belang. Bij kwaliteit zie je namelijk twee verschillende type problemen terug: sporadische en chronische problemen. Deze problemen dienen op verschillende manieren benaderd te worden. Om dit onderscheid heel duidelijk te maken zijn hieronder de verschillen toegelicht.

5.4.2 Kwaliteitsbeheersing

Bij kwaliteitsbeheersing richt men zich op ‘nu’, het oplossen en voorkomen van sporadische problemen.

Bij sporadische problemen nemen de uitvoerende mensen het voortouw. De instrumenten hiervoor zijn statistische procesbeheersing, meet- en regeltechniek en inspectieschema’s. Vaak wordt er reactief op een procesafwijking gereageerd en deze moet direct worden opgelost. Voorbeeld: machine loopt vast, oorzaak wordt weggehaald en het productieproces gaat weer door.

En dan herken je dus meteen het ‘brandjes blussen’ bij veel organisaties. Door toepassing van juiste werkwijze en technieken wordt gestuurd op het zo min mogelijk laten voorkomen van brandjes. Maar beheersing is een opportunistische en reactieve methode.

5.4.3 Kwaliteitsverbetering

Bij kwalititeitsverbetering richt men zich op ‘binnenkort’. Hier focussed men zich op het oplossen van chronische problemen Voorbeeld: hoge uitvalpercentages. Chronische problemen worden opgelost door een project te starten. Een project is namelijk een belangrijk onderdeel van de georganiseerde en systematische LSS benadering.

Het doel is dat het project het chronische probleem voor altijd oplost.

Bij kwaliteitsverbetering horen ‘uitdagende’ technieken waar je van de woorden al kriebels kan krijgen, zoals procesoptimalisatie door statistische trajecten, Business Process Reengeneering (BPR) en DMAIC.

DMAIC is de kern van de LSS methode. Waarover later meer.

5.4.4 samenvatting kwaliteit

Zoals voorgaand beschreven richt LSS zich op kwaliteit en dan vooral op kwaliteitsverbetering. Het continue verbeteren (continues improvement) is waar LSS de meeste voordelen weet te behalen. Dan kiest LSS voor een organisatie structuur waar met projectmatig werkt aan de verbeterprojecten. Dit betekent dat een project moet bestaan uit mensen met: voldoende context kennis, procesgevoel en het te onderhanden nemende probleem. En dat zijn ook de lijnmedewerkers met ondersteuning van lean specialisten.

6. De basisprincipes van de Lean Six Sigma Methodologie

De basis van LSS is een diepgaand onderzoek naar het onderliggende probleem. Het doel van elk project is de prestatie van een proces substantieel te verbeteren. Er wordt gekeken naar zoveel mogelijk dimensies, passend bij het onderwerp, waarop de kwaliteit van een product of dienst kan worden verbetert.

6.1 CTQ

De dimensies waarop het succes van het project wordt gemeten heet ‘critical to quality’ of te wel CTQ. Deze CTQ moet gemeten worden, dus moet je vertellen:

Hoe is deze CTQ gedefinieerd?
Welke factoren spelen een rol?
Wat is de huidige waarde.
Wat is de gewenste waarde?
Welke factoren zijn verbeterbaar?

Dat wordt in LSS beschreven als Y= f(X1, X2, ….Xn). Waarbij Y het gedrag is van het systeem de X-en de oorzaken.

In de loop der tijd zijn meerdere varianten op CTQ bedacht, zoals CTD=critical to delivery, CTC=critical to cost etc.

6.2 Toelichting CTQ

Wat er bij CTQ in simpele taal gebeurt is: een analyse van data, gevolgd door een diagnose. Er wordt o.b.v. de diagnose een hypothese bedacht. Daarna volgt een test van deze hypothese in de praktijk, nog voordat deze wordt voorgelegd als verbetervoorstel.

Maar dan kom je bij vaardigheden van de ‘onderzoeker’ uit. Uit bovenstaande blijkt dat het juist vertalen en inzichtelijk krijgen van de juiste oorzaken vraagt om speciale competenties. Een goed onderzoeker worden lukt je alleen met een goede theoretische basis, daarom zijn de voornoemde Belts in het leven geroepen. Zij hanteren een gereedschapskist met statistische, lean en tientallen andere technieken om dit onderzoek op de juiste manier te doen.

Empirisch onderzoek helpt te zoeken naar onderliggende factoren die van invloed zijn bij een probleem. Alleen door het begrijpen en doorzien van invloedfactoren kan je met goede oplossingen komen. Om de CTQ te beheersen heb je alle onderliggende factoren nodig en de oorzaken van getoond gedrag. Hiertoe hanteert LSS de DMAIC methode. Dit staat voor Define, Measure, Analyze, Improve en Control, het LSS gaat uit van deze 5 fasen van een project. De DMAIC methode is de kern van LSS.

7. De DMAIC-methode in vogelvlucht

Tot nu toe heb ik veel geschreven over het hoe en waarom LSS wordt toegepast.

Ben je er klaar voor? Dan gaan we nu de diepte in. Laat je niet afschrikken door moeilijke woorden, begrippen of werkwijzen. De aanhouder wint!

DMAIC bestaat uit 5 fasen en de acht stappen. Deze staan hieronder beschreven.

7.1 De 5 DMAIC fasen

Define: een project, bijbehorend proces en projectleider worden geselecteerd. In de project-charter worden de organisatorische afspraken vastgelegd.
Measure: Een of meerdere CTQ’s (Critical To Quality) worden geselecteerd. Deze CTQ’s worden gespecificeerd, meetbaar gemaakt en de betrouwbaarheid van de meting is te controleren
Analyze: Het huidige gedrag van de CTQ meten we, o.b.v. hiervan worden de invloedsfactoren bepaald.
Improve: welke invloedsfactoren zijn de belangrijkste, deze onderzoek je verder en hun effecten op de CTQ modelleer je. Daarna volgen de verbeteracties.
Control: Het kwaliteitsverbetering wordt kwaliteitsbeheersing overeenkomstig de nieuwe inzichten. Project wordt afgesloten als alles afgerond is.

7.2 De acht DMAIC stappen

Definieer de CTQ’s.
Valideer de meetmethode.
Beoordeel het huidige proces.
Identificeer mogelijke invloedsfactoren.
Stel het effect van invloedsfactoren af,
Ontwerp verbeteracties.
Pas het procesbeheersingssysteem aan.
Sluit het project af.

Later volgt meer.

Ik heb een overzicht van wat je in hoofdlijnen mag verwachten hiervoor heb ik een schema van de roadmap gezocht.

https://leansixsigmabelgium.com/wp-content/uploads/2014/03/DMAIC-Lean-Six-Sigma-Belgium-.jpg

Een leuk artikel is: Wat is het Kano model?

De SCAMPER methode is een techniek die je zou kunnen toepassen in de verbeterfase.

Verspillingen? Lees: De 3 m’s van Lean: Muda, Mura en Muri

Wat is 5S in Lean?

Het bericht Lean verscheen eerst op agile4all.

Scrum Framework

Peter — Wed, 05 Dec 2018 14:00:01 +0000

Leestijd: 7 min.

In dit artikel wordt het Scrum Framework beschreven. Dit artikel is een totaaloverzicht van het Scrum proces. Mijn advies is om eerst dit artikel volledig te lezen om de samenhang te begrijpen. Ik heb veel doorklik mogelijkheden die je helpen met meer informatie over specifieke onderwerpen. Heb je op dit moment weinig tijd dan kan je het beste starten met Scrum in 3 minuten.

Voor deze introductie tot Scrum heb ik onder andere gebruik gemaakt van de Scrum Guide van Ken Schwaber en Jeff Sutherland. De Scrum Guide is verkrijgbaar op scrum.org. Scrum is een Engelstalige studie, er is echter ook een Nederlandse vertaling van de Scrum Guide beschikbaar. Regelmatig zal ik engelse woorden gebruiken, want alle termen vertalen naar het Nederlands is onhandig. Dit geeft je ook een achterstand bij eventuele Scrum-examens. Examens zijn namelijk in het Engels!

Scrum is één van de bekendste Agile methodes en ook Scrum is gebaseerd op het Agile Manifest. Er is ook een interessante oefening beschikbaar: Oefenen met de 12 principes van het Agile Manifest.

Ik zal dit artikel regelmatig aanpassen en uitbreiden.

Scrum

Scrum is het meest gebruikte agile framework en wordt gebruikt om producten en dienstverlening continu te verbeteren. In de jaren ’90 kwamen Ken Schwaber en Jeff Sutherland met Scrum, het is een proces framework dat ingezet wordt om complexe producten en software te ontwikkelen in een continue veranderende omgeving.

Definition of Scrum

Scrum: a framework within which people can adress complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

Lightweight
Simple to understand
Difficult to master

Scrum framework

Het Scrum framework bestaat uit scrum teams, roles, events, artifacts en rules.

Oftewel: rollen, events, artifacts zijn verbonden door regels. Daarnaast zijn er toppings en tools,

3 roles: Scrum Master, Product Owner en Development Team (vormen samen het Scrum Team).
5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective.
3 artifacts: Product Backlog, Sprint Backlog en Increment.
rules: de verbinding tussen de rollen, events en artifacts.
daarnaast zijn er extra’s, deze worden toppings of tools genoemd. Dit zijn hulpmiddelen en/of mensen die bijdragen aan het proces.

De verbinding binnen het Scrum framework

Het volledige Scrum framework is gebaseerd op teamwork. Het Scrum Team is gezamenlijk verantwoordelijk voor het realiseren van werkende producten en software die voldoen aan de wensen van de klant. Eerst zorgt het team een Definition of Done (DoD) om de kwaliteit van de producten en software te borgen. Het team beschrijft de eisen waaraan producten en software moeten voldoen voordat ze in gebruik kunnen worden genomen.

Het zelf-organiserende Scrum Team levert volgens een vast ritme, de Sprint, een werkend product en/of werkende software op. De sprint kent een vaste afgesproken periode en mag maximaal 4 weken of 1 maand duren. De empirische uitgangspunten: Transparancy, Adaption en Inspection vormen tijdens de sprint de kern van het agile werken voor het team.

Binnen Agile werken zijn de Scrum Values erg belangrijk. De Scrum Values zijn: commitment, courage, focus, openess en respect gelden altijd voor ALLE betrokkenen.

Het belang van deze values is beschreven in Scrum Values wat heb ik eraan? Voor meer informatie over een specifieke Scrum Value: Commitment, Courage, Openness, Focus en Respect.

De waarde van het Scrum framework komt uit de combinatie van empirische uitgangspunten, Scrum Values en het hieronder beschreven proces.

Rollen binnen het Scrum framework

Om het overzicht te behouden heb ik aparte artikelen gemaakt voor de rollen binnen Scrum, evenals de Scrum Values en de empirische uitgangspunten.

De rollen zijn elders uitgebreid uitgeschreven, voor dit artikel is het van belang dat:

Het Development Team is cross-functioneel , iedereen is gelijk en brengt zijn/haar expertise in, er zijn geen subteams en het hele team is accountable.
De Product Owner is verantwoordelijk voor het inventariseren en prioriteren van de te realiseren producten en wijzigingen.
De Scrum Master ondersteunt de Product Owner in zijn rol en is verantwoordelijk voor het wegnemen van issues en het ondersteunen en coachen van het team.

Ik verwijs je naar andere artikelen als je meer wilt weten van de rollen:

Hoe herken je professionaliteit?, Development Team, Product Owner, Scrum Master.

In de volgende alinea’s ga ik verder met het beschrijven van het proces.

Vaste volgorde events!

Het Scrum framework bestaat uit een aantal events in een vastgestelde volgorde binnen een sprint.

1. Sprint

De ‘container’, het totaal van start tot oplevering van een increment.
Voor de eerste sprint moet er een Product Backlog (= artifact) zijn.
Een sprint is een continue proces, met opeenvolgende sprints. Sprints gaan onafgebroken (oneindig) door.
Is op zichzelf ook een event!
Heeft een vooraf vastgestelde tijdperiode.
Het risico van het werken aan het verkeerde wordt kleiner door de korte doorlooptijd.
Bestaat uit onderstaande events en toppings.
Tijdsduur: 1 tot en met 4 weken. Nooit korter dan 1 week en niet langer dan 4 weken (soms maand). Altijd volgens de gemaakte afspraak.

2. Sprint Planning

In de Sprint Planning stelt het team een doel vast. Het sprintdoel.
De basis hiertoe is de Product Backlog (= artifact).
Wordt bepaald wat het team gaat oppakken in de komende sprint, dus ook hoeveel werk het team meeneemt in deze sprint.
Hoe worden de wijzigingen opgepakt in de komende sprint. Dus plannen van concrete taken.
De uitkomst van dit deel is de Sprint Backlog (= artifact).
- een Sprint Backlog: een korte lijst met wijzigingen en taken gerangschikt op prioriteit.
- het team start met de realisatie van producten en wijzigingen.
Output van de Sprint Planning is dus: Sprintdoel, Sprint Backlog en welke items gerealiseerd gaan worden en hoe het werk gerealiseerd gaat worden.
Ter verduidelijking: de Product Backlog is van de Product Owner, de Sprint Backlog is eigendom van het Development Team en kan niet gewijzigd worden door de Product Owner.
Tijdsduur: maximaal 8 uur voor een sprint van 4 weken/1 maand. Voor kortere sprints is de tijdsduur veelal korter.

3. Daily Scrum / (Daily) Stand Up

Gedurende de sprint wordt dagelijks de voortgang besproken in een Daily Scrum ook wel (Daily) Stand Up aan de hand van drie vragen:

Wat heb je gisteren gedaan?
Wat ga je vandaag doen?
Welke issues/belemmeringen zijn er?

Dit is wellicht het meest herkenbare element van Scrum, want de status van de sprint zie je terug op een scrum bord. Als er ergens in jouw organisatie scrum wordt toegepast, dan zie je vrijwel altijd een scrum bord.

Deze vragen zijn niet alleen bedoelt als een opsomming van de activiteiten. Het biedt het team mogelijkheden om elkaar te begeleiden, advies te geven en/of separate afspraken te maken om dieper op de materie in te gaan. De issues/belemmeringen dienen te worden opgepakt door de Scrum Master.

Tijdsduur: maximaal 15 minuten (en uiterlijk de volgende binnen 24 uur, op werkdagen)

4. Sprint Review

Wordt ook wel ‘end of sprint’ of ‘demo’ genoemd.

Aan het eind van elke sprint worden tijdens de Sprint Review de producten en wijzigingen getoond aan de klant, stakeholders en eindgebruikers. Het opgeleverde product heet het increment (= artifact), de optelling van alle eerdere opleveringen.

In tegenstelling tot wat velen denken is dit géén formele bijeenkomst. Deze gedachte wordt gevoed door dat de Product Owner accepteert wat er is bereikt. Het is ‘ouderwets denken’ dat dit moment van ‘acceptatie’ een formeel moment is. Als het teamproces goed verloopt is de Product Owner tijdens de gehele sprint op de hoogte van de status en weet zij/hij wat er wordt opgeleverd.

Het is een informele bijeenkomst waar het team laat zien wat ze hebben bereikt. De Sprint Review is vooral een sessie om samen te werken, vanzelfsprekend wordt e.e.a. gepresenteerd, vertelt en/of getoond wat er is bereikt. Maar het gaat vooral om de vragen, feedback en discussie. Want de verkregen input wordt mede gebruikt voor de planning van de volgende sprint.

Tijdsduur: maximaal 4 uur voor een sprint van 4 weken/1 maand. Voor kortere sprints is de tijdsduur veelal korter.

5. Sprint Retrospective

De sprint wordt afgesloten met een Sprint Retrospective. In dit overleg wordt de sprint door het team geëvalueerd en worden verbeterpunten benoemd die worden meegenomen in de volgende sprint. In dit overleg zijn de teamleden aanwezig. Op deze wijze kan het team zich continu verbeteren.

Gemakshalve geef ik hier vooralsnog aan dat het om 2 kernvragen gaat:

wat ging er goed?
wat kan er beter?

In werkelijkheid zal dit event veel omvattender qua inhoud zijn. Het uitgebreide artikel over de Sprint Retrospective.

Dit kan een ‘spannend’ moment van een Sprint zijn. Vooral als de Sprint niet lekker is verlopen, bijvoorbeeld als de doelen niet zijn gehaald of teamleden het volstrekt met elkaar oneens zijn. Dit kan leiden tot (stevige) meningsverschillen, waar de Scrum Master of Agile Coach al zijn vaardigheden zal moeten inzetten om dit goed te begeleiden.

De bevindingen tijdens de sprint bepalen vaak de tijdsduur van dit event, maar volgens de theorie:

Tijdsduur: maximaal 3 uur voor een sprint van 4 weken/1 maand.

Extra’s, need to know:

Artifacts

Ze staan hier boven al bij het juiste event, maar voor de helderheid nog even in een rijtje:

Product Backlog: input voor Sprint Planning met uitleg van Product Owner. Ongoing process.
Sprint Back log: output van Sprint Planning, soort ’to do’ list.
Increment: output van Sprint. In de Sprint Review, is de oplevering van het al gedane werk.

The development work

Volgens de Scrum theorie is het ‘onderhanden werk’ geen event, rol of artifact. Alle zaken m.b.t. het werk wordt besproken in de bovenstaande events. Vanzelfsprekend is het wel datgene waar het in de Sprint om gaat. Het onderhanden werk leidt uiteindelijk tot een oplevering (Increment) aan het einde van de sprint.

Een Increment is een toevoeging aan de reeds bestaande functionaliteiten van de software en/of product. Zonder Increment is er geen goede afsluiting van de sprint, er zijn immers afspraken gemaakt over het Sprintdoel. En elk Sprintdoel is pas compleet als er een op te leveren goal (w.o. Increment) is benoemd.

Toppings & tools

Rare benaming eigenlijk toppings en tools. Toch noem ik ze zo, omdat ’toppings’ het chocola op het ijsje is en de tools staat voor de benodigde gereedschappen. De hantering van toppings en tools staan vaak beschreven. Toppings en tools worden in de praktijk als termen door elkaar gebruikt. Het gaat er echter om dat je begrijpt wat het is en je ze op de juiste tijd en juiste manier toepast.

De toppings/tools ga ik later verder uitwerken in aparte artikelen. Als ze beschikbaar zijn, kan je erop klikken.

Epics & User Stories
Planning Poker
Scrum Board
Burndown Chart
Definition of Ready
Definition of Done
Refining / grooming
Belanghebbenden:
- Stakeholders
- Agile Coach
- etc.
Velocity
Metrics
etc.

Alvast een korte noodzakelijke toelichting van refining /grooming: Tijdens de sprint mag maximaal 10% van de beschikbare tijd besteed worden aan het verduidelijken van de Product Backlog voor komende sprints.

Samenvatting

Je mag pas spreken van Scrum als je alle rollen, events, artifacts en regels juist gebruikt. Vanzelfsprekend in combinatie met empirisme en Scrum Values. Kortom, Scrum is het correct gebruiken van het hele Scrum Framework!

In sommige organisaties worden bepaalde stappen overgeslagen of niet toegepast. Dan is het vermoedelijk geen Scrum meer. Agile denken biedt de mogelijkheid om (deels) af te wijken, als iets voor een team echt niet werkt. Dit dient echter aangetoond te worden in meerdere sprints en daadwerkelijk objectief vastgesteld worden dat er een beter alternatief mogelijk is. Veelal is het overslaan van activiteiten een bypass om issues niet te hoeven bespreken. Voor mij is het een belangrijk signaal, want het staat veelal voor (verborgen) issues. Zoals hiërarchische-, technische-, commerciële-, team problemen en nog veel meer.

Aan de andere kant: pas op voor de ‘scrum-politie’. Dat zijn de personen die procedures en vastgestelde stappen belangrijker vinden dan de oplevering van het juiste product die voldoet aan de huidige klantbehoefte.

Scrum Nexus

Voor het scalen van Scrum, van ca. 3 tot 9 teams, is het Scrum Nexus Framework bedacht. Lees hier meer over in het artikel: Wat is Scrum Nexus?

FAQ:

Is het toevoegen van ‘extra’ tijd binnen een Sprint mogelijk?

Nee, dat kan niet. Vooraf is de timebox voor de Sprint afgesproken, deze kan niet veranderd worden.

Er is ook geen tijd, ruimte of tussenpauze tussen de opeenvolgende sprints. Events mogen korter zijn dan de tijd die hiervoor staat, maar de maximale toegestane tijd mag niet worden overschreden.

Kan een sprint tussentijds beëindigd worden?

Ja, dat kan. Maar alleen bij zeer grote uitzondering en dat is een apart artikel waard. De impact van voortijdige beëindiging op het team en organisatie is namelijk zeer groot.

Dit heb ik beschreven in het artikel: Is tussentijds stoppen met een Sprint gelijk aan een hartstilstand?

Het bericht Scrum Framework verscheen eerst op agile4all.