Je bent bekend met Scrum, toch? Ik denk van wel, gezien het feit dat The Scrum Alliance meer dan 400.000 leden heeft, en de meeste daarvan gebruiken het met succes in hun organisaties.
Maar het is niet de enige manier om software op een agile manier te bouwen - serieus! Heb je gehoord van Kanban?
Voor een beetje achtergrondinformatie werd het oorspronkelijk toegepast op lean manufacturing als een manier om de invoer en uitvoer van werk te visualiseren terwijl het door een fabriek stroomde. Deze visualisatie werd gepresenteerd op een bord dat bekend staat als een - wacht erop - Kanban. Meer recent en relevanter voor u, is het aangenomen als een methode voor het beheren van software-ontwikkeling.
Voor het eerst beschreven door neuroloog David J. Anderson, is het een manier om softwareontwikkeling en -planning te organiseren waarmee u procesproblemen kunt ontdekken en consistent waardevolle verbeteringen in uw product kunt aanbrengen - wat ik weet, klinkt ideaal. Simpel gezegd, op elk moment in de tijd, kunt u zien waar werk (voorgesteld door kaarten) zich in het ontwikkelingsproces bevindt.
Hoe het werkt
Het standaard Kanban-bord gebruikt zes kolommen die laten zien waar elk werkstuk zich bevindt in de productontwikkelingscyclus. Een ruw voorbeeld van hoe het eruit ziet is hieronder.
Bekijk dit Kanban-bordvoorbeeld op Trello.
Kolom 1: Achterstand
De kolom Backlog moet een lijst met prioriteiten bevatten met ideeën, bugs of zakelijke behoeften. De kaart hoeft nog niet veel details te bevatten, maar hij moet voldoende informatie bevatten zodat uw teamleden begrijpen waarom het belangrijk is.
Kolom 2: Planning
In deze kolom vult een productmanager een specificatie voor de functie in door stakeholders, ingenieurs en ontwerpers uit het bedrijfsleven te ontmoeten. Wanneer het klaar is, verplaatst hij het naar de kolom "Klaar voor engineering".
Kolom 3: Klaar voor engineering
In dit stadium moeten alle kaarten gedetailleerde specificaties hebben. Hoewel u mogelijk nog vragen hebt over technische details, moeten de zakelijke vereisten duidelijk zijn.
Kolom 4: In uitvoering
U kunt op elk gewenst moment een kaart verplaatsen naar 'In uitvoering'. Dit zelfgestuurde 'pull'-systeem bouwt een cultuur op van persoonlijke verantwoordelijkheid en nieuwsgierigheid.
Kolom 5: testen
Wanneer u het werk aan de kaart hebt voltooid, verplaatst u deze naar "Testen" waar een andere technicus (of iemand van het QA-team) deze ophaalt.
Kolom 6: geïmplementeerd
Een ander bepalend kenmerk is dat werk continu moet worden geleverd aan een staging- of productieomgeving. In deze kolom kan iedereen in het team zien welk werk recent is vrijgegeven.
De voordelen en afwegingen
Houd rekening met deze voordelen en uitdagingen wanneer u kiest tussen Kanban en een meer algemene methode zoals Scrum of Waterfall.
Voordeel: verbetert de samenwerking
In sommige ontwikkelingsteams waarmee ik heb samengewerkt, waren ingenieurs specialisten. Elk team zou een paar frontend-ingenieurs en back-end-ingenieurs hebben. Dit betekende dat het werk vaak werd geblokkeerd omdat een ingenieur bezig was met iets anders.
Kanban daarentegen beperkt het lopende werk en ontmoedigt blokkades. Elk teamlid kan slechts aan één item tegelijk werken en iedereen die het niet druk heeft, kan werk bovenaan de kolom “Ready for Engineering” halen. Dit stimuleert technische generalisten en samenwerking tussen teamleden.
Vergroot het voordeel: laat dingen niet voorbijgaan voordat ze klaar zijn
Kanban werkt alleen als je wacht om kaarten naar de volgende kolom te verplaatsen totdat ze helemaal klaar zijn. (Bonus: dit minimaliseert defecten aanzienlijk.)
Uitdaging: ontmoedigt tijd om na te denken
Standaard zijn er geen time-boxed sprints met duidelijke doelen, datumdoelen en releasecycli. Beschouw in plaats daarvan elke kaart als een onafhankelijk werk dat op elk gewenst moment kan worden voltooid en vrijgegeven.
Met deze continue werkstroom is er geen optie 'wachten tot de volgende sprint'. Je moet het bord continu controleren, het volgende item trekken en voltooide items stroomafwaarts verplaatsen. Tenzij je op tijd bouwt voor retrospectieven en standups, is het misschien moeilijk voor teamleden om bij te houden hoe ze het doen.
Get Around It: Borrow What Works From Scrum
Ik heb dagelijkse standups en retrospectieven met Kanban gebruikt en vond dat ze waarde toevoegen. Als er regelmatige vergaderingen of patronen zijn die voor uw team werken, verander deze dan niet om dogmatisch aan Kanban te voldoen. Neem tijd om te praten over de prioriteiten en hoe deze zijn gewijzigd, zodat iedereen weet wat er gebeurt in de productontwikkelingscyclus.
Voordeel: verhoogt de transparantie
Elke ontwikkelaar moet het initiatief nemen om een kaart naar de kolom 'Bezig' te verplaatsen. Dit betekent dat de manager van het team op elk gewenst moment kan bekijken wie bezig is, wie niet bezig is, en hoe lang elk werk nog bezig is.
Wanneer de productie vertraagt of stopt, kunt u met Kanban precies zien waarom. Of het nu is omdat het zakelijke team geen prioriteit heeft gegeven aan items in de achterstand, het productteam niet is gespecificeerd, het dev-team langzamer beweegt dan verwacht, of het QA-team iets niet heeft kunnen testen; de knelpunten zijn duidelijk.
Vergroot het voordeel: laat vooruitgang openbaar worden
Een van de voordelen is dat Kanban erg visueel is. Zelfs niet-technische teamleden kunnen naar een Kanban-bord kijken en vertellen waar werkstukken zich bevinden. Gebruik dit in je voordeel en laat de prestaties van het team schitteren door je board op een openbare plaats te plaatsen.
Uitdaging: houdt geen langetermijnplanning in
Je zorgen maken over deadlines en schattingen is niet het meest productieve gebruik van je tijd, dus je zult begrijpen dat Kanban meer over de dagelijkse output gaat. Dat gezegd hebbende, biedt het alleen geen systeem voor het opstellen van een langetermijnplan. Dit kan ertoe leiden dat u sporadisch aan projecten werkt in plaats van lange tijd op één ding te focussen. Het is moeilijk om een dag aan Project A door te brengen, daarna een dag aan Project B en dan terug te schakelen naar Project A.
Ga er omheen: gebruik het wanneer uw prioriteiten waarschijnlijk zullen veranderen
Elke kolom in je board is onafhankelijk van de andere, zodat teamleden dingen op elk moment kunnen verplaatsen. Dit kan ontwikkelaars ergeren in een Scrum-instelling (waarbij vooraf schattingen voor de sprint worden gemaakt), maar Kanban gedijt in dit soort snel veranderende omgeving.
Iedereen wil productiever zijn, maar het kan moeilijk zijn om iets nieuws te proberen als je niet eens zeker weet waar je moet beginnen. Ik heb Kanban als nuttig ervaren en hoop dat je het ook nuttig zult vinden voor je persoonlijke workflow (of zelfs voor je hele team!).
Tweet me als je besluit om het eens te proberen!
