Voor het implementeren van software zijn verschillende methodes. Voor elke methode is wat te zeggen, maar binnen CE-iT hebben wij toch wel zo onze voorkeuren. Dat is niet een strak omlijnd iets, maar een mix van Agile, Scrum en Kanban met een sterke nadruk op Kanban.
Traditioneel werd voor het implementeren van software vaak gebruik gemaakt van de waterval methode. Bij deze methode wordt eerst alles in detail werd uitgewerkt en dat werd vervolgens geïmplementeerd. Als de klant vervolgens gaat testen dan blijkt vaak dat wat er is gebouwd (deels) de aansluiting mist bij de praktijk. Deze methode is dus vrij statisch. Onze ervaring is dat bij deze aanpak bij complexere projecten al snel kan leiden tot vertraging en extra kosten.
Bij een Agile aanpak kan er uiteraard ook vertraging ontstaan, maar is het makkelijker om tussentijds bij te sturen. Dit wordt hierna verder toegelicht en ook waarom bij binnen het Agile veld een voorkeur hebben voor Kanban.
Agile en Scrum
Een populair alternatief voor de waterval methode is Agile, waarbij Scrum de meest bekende stroming is. Hierbij wordt gewerkt met korte sprints, 2 – 4 weken, waarin elke keer een aantal requirements worden gerealiseerd. Er wordt gewerkt met een vast team (developers, gebruikers, etc.) die samen de wensen uitwerken, ontwikkelen en testen. Het is een flexibele aanpak die altijd gericht is op het opleveren van bruikbare software die aansluit bij de eisen en wensen van de gebruikers. Hierbij geldt de product back log als een lijst van te implementeren functionaliteiten op basis. Deze functionaliteiten worden geprioriteerd door de Product Owner.
De Product Owner is in een sleutelpersoon die bepaalt welke requirements er wanneer opgepakt worden. Dat klinkt heel simpel, maar in de praktijk komt hier best wat bij kijken. Als Product Owner moet je namelijk goed wensen kunnen vertalen naar kleine en concrete requirements. Kennis van de software en ontwikkeling van de software is daarbij bijna onmisbaar. De Product Owner wordt doorgaans door de klant geleverd. In de praktijk vinden veel klanten dat lastig vinden en vervult iemand van CE-iT die rol vaak samen met de klant.
Waarom echt Scrum voor CE-iT vaak maar beperkt werkt
Bij CE-iT zijn wij zelf enkele jaren geleden overgestapt op Agile, waarbij ook wij Scrum zijn gaan gebruiken. Over de methode zijn wij enthousiast, maar in de praktijk zijn er ook nadelen. Bij Scrum moet je als team namelijk een “ritme” voor de sprints vinden. Het duurt vaak enkele sprints voor het ritme is gevonden, maar omdat veel van onze projecten bij klanten vaak korter dan 6 maanden zijn werkt dat niet optimaal. Tegen de tijd dat het ritme gevonden is, loopt het project namelijk al op haar einde en zal het team uit elkaar gaan.
Naast bovenstaande valt vaak nog een voordeel van Scrum weg, en dat is dat elke sprint direct naar productie kan om op die manier gefaseerd een systeem op te bouwen. In de praktijk blijken veel van onze klanten een voorkeur te hebben om het project in één of twee releases live te brengen. Hiermee vervalt een mooi punt van Scrum.
Kanban
Ondanks bovengenoemde bezwaren zien wij wel de voordelen van een Agile aanpak. In de praktijk leidt het namelijk vaak tot de meest tevreden klanten en gebruikers. Dat komt omdat het de mogelijkheid biedt om gedurende het project requirements te prioriteren en in te spelen op voortschrijdend inzicht. Wij zijn daarom verder gaan kijken naar andere methodes en uitgekomen bij Kanban.
Kanban lijkt veel op Scrum, maar verschilt op een aantal punten. De belangrijkste verschillen en voordelen voor ons zijn:
- Kanban is gericht op doorlopende ontwikkeling in plaats van korte sprints. Er wordt nog steeds gewerkt met work items, maar de stap naar productie vindt niet per sprint plaats maar wordt door de klant bepaald en gepland.
- Door niet met korte sprints te werken, hoeft er niet elke 2 – 3 weken een toch vaak tijdsintensieve planningssessie plaats te vinden.
- Net als in Scrum wordt er binnen Kanban met een backlog en een board gewerkt. Het board heeft echter een andere indeling. De analyse fase is daardoor meer in beeld. Het is voor de project manager ook beter zichtbaar waar work items zich bevinden of welke items “stokken”.
De fases binnen Kanban
Bij Kanban doorloopt elk work item de volgende fases:
- Backlog: ieder work item wordt op de backlog geplaatst. Dit is een verzameling van alle wensen die nog niet zijn uitgevoerd.
- Specify: hier worden de requirements op een gespecificeerd in één of meerdere user stories.
- Development: de gespecificeerde requirements worden ingericht in de applicatie.
- Validate: de requirements worden getest.
- Done: zodra een work item is goedgekeurd dan wordt deze bestempeld als “done”.
Op het moment dat een work item deze stappen heeft doorlopen dan is het in principe gereed om mee te gaan in de eerst volgende release. Dat is dus anders dan bij Scrum. Daar worden de work items van een afgeronde sprint vaak direct overgezet worden naar productie.
Bij Kanban wordt voorafgaand aan het project een inschatting gemaakt van het tempo van de langzaamste fase in de ontwikkeling. Dit kan bijvoorbeeld het ontwikkelen zijn. Het tempo van deze fase bepaalt dan het aantal work items dat er maximaal in een fase mag zitten. Op die manier wordt “filevorming” voorkomen en is het mogelijk om snel op nieuwe prioriteringen in te spelen. Dit zorgt ook voor de “doorlopende ontwikkeling” die centraal staat bij Kanban.
Werkt Kanban altijd?
Kanban is net als Scrum niet de heilige graal. Een methode is deels afhankelijk van persoonlijke voorkeuren, maar is ook afhankelijk van het type project en de organisatie. Eric Brechner van Microsoft legt in het volgende filmpje uit hoe Kanban binnen het Xbox team wordt toegepast.
Microsoft past Kanban anders toe dan dat wij dat doen. Het is belangrijk om te kijken wat het beste past bij de situatie waar je in werkt en daar een methode bij uit te kiezen. En misschien nog wel belangrijker: een methode is niet heilig. Kijk wat werkt en pas dat toe.