Even een situatieschets. Er was een periode in het begin van dit jaar dat de software elk weekend werd gereleased. Door allerlei redenen kwam het regelmatig voor dat een release niet stabiel was en essentiële fouten live werden gezet. Nadat de gebruikers begonnen te klagen dat de software toch echt moet werken en niet mag omvallen moest er iets gebeuren. De automatische reflex van de verantwoordelijke managers was: meer en strakkere procedures. Voor elke change is nu een functioneel en technisch ontwerp nodig en alles moet door de gebruikers worden getest in een UAT. Om dit mogelijk te maken is er een geplande release cycle van 6 weken. (In vakantie tijd kan dit oplopen tot 8.)
Hoewel ik deze reflex begrijp, werkt het naar mijn idee niet. Nu valt nog steeds de applicatie om en is herstellen is moeilijker, omdat iedereen ondertussen met andere zaken bezig is dan de sectie waar de fout is ontstaan. (Enige voordeel is dat dit nu minder frequent gebeurt.) Verder is de UAT een papieren werkelijkheid. De gebruikers testen alleen de happy flow en worden nauwelijks begeleid hoe ze zouden moeten testen. Nu hebben we naast de omvallende software een aantal nieuwe problemen. Allereerst staat er nu veel meer druk om op de deadline alle functionaliteit af te hebben. Anders duurt het namelijk 6 weken langer om die functionaliteit beschikbaar te krijgen.
Mijns inziens is de langere cycle time niet de oplossing. De kwaliteit van de software is nu nauwelijks beter en dezelfde problemen blijven de kop op steken. Nu wordt bij IT gewezen naar de business dat ze de requirements maar beter hadden moeten samenstellen, als bij de UAT blijkt dat het niet volgens verwachting is. Ondertussen klagen de gebruikers dat IT altijd voor vertraging zorgt, zodat zij hun werk niet kunnen doen. Het wij/zij spelletje is begonnen en ik denk niet dat iemand er blij van wordt. Beide kampen hebben natuurlijk een punt, maar dit lost de problemen niet op.
Kwaliteit is het probleem van IT niet van de gebruikers. Als het niet mogelijk is om de benodigde kwaliteit te leveren in de huidige release cyclus dan gaat dat ook niet lukken in een langere. Vakmanschap is het enige dat de kwaliteit kan verhogen.
3 responses to “6 weken is echt te lang”
[…] Dit blogartikel was vermeld op Twitter door Mvvenrooij, Mvvenrooij. Mvvenrooij heeft gezegd: Schrijft: 6 weken is echt te lang http://bit.ly/gp24OK […]
Het uitstellen van releases en het verlengen van een iteratie-cyclus is een gebruikelijke reactie in de door jou geschetste situatie. Wat mensen zich vaak alleen niet realiseren is dat de daadwerkelijke problemen (jij noemt hier een gebrek aan vakmanschap als voorbeeld), die zichtbaar worden door een korte cyclus, niet worden opgelost.
In softwareontwikkeling geldt dezelfde regel als in de sport of ieder ander vakgebied: als je ergens beter in wilt worden, dan moet je het vaker doen. Wanneer je problemen hebt met het uitbrengen van stabiele releases, dan worden de problemen nog beter zichtbaar als je de cyclus waarin dit gebeurt verkort.
Helemaal mee eens Arne