Onlangs heeft Outsystems een blog gepost waarin werd ingegaan op een aantal wijzigingen van de Scrum richtlijnen 2020, die zorgt dat Scrum minder beperkend wordt. Interessant, want Pivoton heeft de afgelopen jaren ook veel ervaring opgedaan met Scrum en sinds ruim een jaar tevens met Scrum@Scale.
Enkele punten die naar voren komen vinden wij als Software Product leverancier ook erg belangrijk.
Scrum is niet alleen voor software development afdelingen, maar zou door de hele organisatie gebruikt kunnen worden. Pivoton is ruim een jaar geleden ook gestart om haar organisatie te transformeren naar Agile, in ons geval Scrum@Scale. De Agile teams zijn bij Pivoton in de basis zogenaamde ScrumBan teams, waarin we gebruik maken van zowel Scrum als Kanban best practices. Op deze manier committeren we aan onze release doelstelling en zijn we flexibel genoeg om aanpassingen te maken in de sprints. Hiermee verhogen we de waarde per release (voor onszelf en onze klanten), werken we efficiënter en zijn we nog sneller in staat om in te spelen op veranderingen in de nabije toekomst.
Eenvoudige methodiek
Naast deze Scrum opschaal methodiek zijn er uiteraard ook andere smaken zoals Less en Scrum Nexus, maar wij hebben gekozen voor Scrum@Scale. Deze methodiek is relatief eenvoudig in opzet voor onze organisatie en sluit beter aan onze wensen. Denk hierbij aan minder voorschrijvend, minder rollen en platter in organisatie.
JanEeuwe Broos
Met Scrum@Scale verhogen we de waarde per release (voor onszelf en onze klanten), werken we efficiënter en zijn we nog sneller in staat om in te spelen op veranderingen in de nabije toekomst.
JanEeuwe Broos
De nieuwe Scrum richtlijnen maken deze overstap ook makkelijker en werken in het voordeel van andere type afdelingen dan software development afdelingen zelf. Bijvoorbeeld in de nieuwe Scrum 2020 richtlijnen wordt er minder gesproken over product development specifieke zaken en meer over het creëren van incrementele waarde. Dit zou niet-software development teams beter kunnen aanspreken en kan daarom breder te interpreteren zijn.
Behalve dat de Scrum richtlijnen eenvoudiger zijn gemaakt, en overigens ook in de samenvatting van Scrum Alliance staan vermeld, zijn er bijvoorbeeld ook richtlijnen gewijzigd voor het Scrum team zelf.
Het team, met daarin de Product Owner, Development Team en Scrum Master zijn nu samen verantwoordelijk voor het creëren van waarde en verschilt daarin met de 2017 versie. Het team heeft een ‘doel’ waar ze samen de verantwoordelijkheid voor nemen en waarvoor ze keuzes maken ‘wat’, ‘hoe’ en ‘wie’ wat doet. Uiteraard blijft de Backlog een verantwoordelijkheid van de Product Owner, en de teamprestatie die van de Scrum Master. Wel heeft de Scrum Master een verlengstuk gekregen naar de organisatie. Dit lijkt ook overeen te komen met wanneer je opschaalt met Scrum@Scale.
Gezamenlijk teamdoel
Ook bij Pivoton hebben we gezien dat dit concept, een gezamenlijk teamdoel, beter werkt dan wanneer de Product Owner verantwoordelijk is voor het ‘wat’ en het development team voor het ‘hoe’ en ‘wie’. In het verleden hadden we meer een scheiding tussen de releases van onze verschillende software, nu hebben we 1 release, 1 metascrum en daarmee 1 gezamenlijk speerpunt. Daardoor zijn we in staat om beter en eerder keuzes te maken voordat het in de ontwikkelteams komt en daarmee verhogen we onze productiviteit.
Wat Scrum Alliance ook aangeeft; dat het een “us vs. them” cultuur kunnen voorkomen.
JanEeuwe Broos
In het verleden hadden we meer een scheiding tussen de releases van onze verschillende software, nu hebben we 1 release, 1 metascrum en daarmee 1 gezamenlijk speerpunt. Daardoor zijn we in staat om beter en eerder keuzes te maken voordat het in de ontwikkelteams komt en daarmee verhogen we onze productiviteit.
JanEeuwe Broos
Product goal
Verder blijven de Scrum ceremonies en artefacten in stand. Wat dus wel is toegevoegd is het ‘product goal’. Voor Pivoton is dit ook heel belangrijk, omdat we te maken hebben met wensen van onze klanten (korte- en middellange termijn) tegelijk met onze eigen roadmap (middellange- en lange termijn). En daarmee extra waarde blijven toevoegen voor onze klanten bovenop de realisatie van de lange termijn doelstellingen. Wij proberen dit zo helder mogelijk te krijgen en houden, zowel voor de korte termijn zoals in de sprints, als voor de midden en lange termijn middels releases en onze Metascrum. Dit laatste, de Metascrum, is voor ons de manier, en ook een artefact van de Scrum@Scale, om onze product doelen op de juiste manier in beeld te houden.
Volgens mij is deze versimpeling van de richtlijnen een goede toevoeging in de nieuwe versie van de Scrum richtlijnen 2020.
Jan Eeuwe Broos
Agile leader @ Pivoton
