Scrum is hot. Niet alleen als trend. Het is heftig voor iedereen. Intensief. En continue blijven leren. Zo heb ik sinds gisteren ook weer veel geleerd en inzichten erbij.
Gisteren een NL Scrum meeting bijgewoond. Onderwerp dit keer was UX en scrum (een zogenaamde agile ontwikkelmethode). Erg interessant. Veel typische misstanden kwamen naar boven (volgens mij ook niet onbekend bij bij traditionelere ontwikkelmethoden): De business mensen zitten wel aan tafel als stakeholder, maar de eindgebruikers zijn voor de bouwers vaak onzichtbaar. Gelukkig kost testen weinig tijd en daarom is tijd ook geen excuus om niet met gebruikers te testen (tot zover de samenvatting van Joris Ketelaar’s presentatie van UserIntelligence).
Naast testen met gebruikers is ontwerp voor gebruikers natuurlijk belangrijk. Doe je dat vooraf (soms is design gewoon een eindproduct), in een design sprint voor de productie sprint, of als übersscrum; tegelijkertijd? (een belangrijk thema in het verhaal van Patrick, Fabrique). Bij überscrum is het het doel om het voorwerk (de overhead), wat in zich redelijk draaiende projecten toch nog 10% tot 20% van de effort beslaat, laten convergeren richting 0. Zorg voor een Definition of Ready (“snappen de ontwikkelaars wat er gebouwd moet worden? kan het ingeschat worden?”) die echt net voldoende is. En dan moet je ook dingen durven weg te gooien (incrementeel vs iteratief) als het op een gegeven moment toch niet zo goed blijkt te zijn. Een optie is ook om designers en productie mensen te laten samenwerken op hetzelfde bord, maar aan andere type stories, met eventueel afwijkende Definitions of Done.
Hoewel ik er nooit zo strict over nagedacht had doen we intern toch wel uberscrum, zo goed als kwaad als het kan (het is heet in de keuken!). En zo kwam ik op een probleem waar we toch eigenlijk wel mee zaten, maar nog niet goed kon uitleggen: hoe definieer je ‘bugs’ als je met gebruikers test. Immers, als de definition of ready zeer minimaal is, is het ook lastig om strikt te beoordelen of het voldoet aan de definition of done, zeker wanneer deze gebruiksvriendelijk als criterium had en zo ging ik als host van m’n eigen open sessie met de billen bloot: ‘wat te doen met gebruikersbugs’.
Op zich was de vraag wat te doen met gebruikersbugs al snel beantwoord. Bugs zijn fouten, en dat hangt af van je definition of done. Veelal kom je daar zelf wel uit. Wees gewoon kritisch, is dit conform wat er is besteld is, of niet. Features dus niet te snel als ‘bugs’ beschouwen. Dit laatste kwam misschien ook wel om dat ik als ‘handige’ proxy product owner soms te snel features er nog even zelf doorheen ‘drukte’ om mijn eigen idee van hoge kwaliteit te bereiken. Dom natuurlijk om meerdere, te voor de hand liggende redenen, en wat ik nu weet is dat je je daar tegen moet wapenen: maak minimaal inzichtelijk, richting teammembers en maar ook naar alle stakeholders, waar je mee bezig bent.
Het half uur was nog niet vol en zo ging de discussie over het wel of niet houden van retrospectives. Dit doen we niet gestructureerd, zo moest ik toegeven. Met de billen bloot gaan kan nuttig zijn. Met schaamte moest ik bekennen dat we nog wel het nodige kunnen verbeteren aan ons proces. Ik neem me voor:
Te overwegen valt, zoals Patrick uitlegde, om de rol van Scrum Master te hebben als designer. Maar voor mij is dat nog onduidelijk of dit een oplossing is. Juist de verantwoordelijkheid van procesbeheersing bij een ander neer te leggen, vind ik fijn. Ideeën, als designer ben je toch vooral van de ideeën en richting, kunnen dan vrijer van de praktische bezwaren (niet te snel convergeren) ontwikkeld worden. Conclusie: misschien is dat juist wat er de afgelopen tijd heeft ontbroken, een scrummaster die goed waakt over het wel of niet doorschieten van de PO. Of ik ben te eigengereid. Pets. Au.
Vond je dit leuk, volg me op Mastodon, voeg die RSS, euh ATOM feed toe aan je feedreader, of schrijf je hieronder in op mijn nieuwsbrief.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .