Grootschalig Scrum

Zodra meerdere Scrum teams moeten samenwerken aan een gemeenschappelijk product ontstaat de noodzaak tot coördinatie. Het is een kwestie van vertrouwen in de teams, de Scrum masters en de product owners of daarvoor extra rollen moeten worden gecreëerd of bestaande gehandhaafd.

---

Het SAFe framework

klik op het plaatje voor een grote afbeelding

Zie dit webinar met Dean Leffingwell and Drew Jemilo voor een toelichting. Het Scaled Agile Framework is een product dat moet worden geimplementeerd. In feite wordt de organisatie opnieuw ingericht. Dat kan een langduring proces zijn dat goed moet worden begeleid door gecertificeerde consultants. Agile puristen hebben kritiek op deze aanpak. Zie de video "Is SAFe Evil?" van Lars Roost & Henrik Kniberg voor een nuchtere kijk op dit onderwerp.

Wat opvalt is dat SAFe aansluit op wat in staande organisatie gebruikelijk is: budgetrondes op portfolio niveau, prioriteitstelling op programma niveau en tenslotte de backlogs voor de teams. Managers zorgen voor de coördinatie tussen deze werelden.

Het LeSS framework

klik op het plaatje voor een grote afbeelding

Large-scale Scrum as Scrum is een set van aanvullende regels en een verzameling van tips die hun waarde hebben bewezen in grote multi-team, multisite, en offshore agile ontwikkel initiativen. Deze tips zijn experimenten om te proberen in de context van het klassieke Scrum framework.

In tegenstelling tot SAFe kent LeSS maar één backlog per product waarbij dit begrip ruim moet worden opgevat. Dus, voor een bank, één backlog voor alle spaarproducten. LeSS drijft op het vertrouwen dat de teams die aan een product werken zelf voor de ondelinge afstemming zorgen. Hiervoor zijn geen andere rollen nodig dan die van team, Scrum master, product owner en bij LeSS huge, de area product owner. De rol van het management bestaat bij LeSS uit:

Managers’ role is to improve the product development system by practicing Go See, encouraging Stop and Fix, and “experiments over conformance”.

Ook interessant om te lezen is deze blog: Managers doen precies waarvoor zij niet zijn aangenomen.

De Spotify ontwikkelcultuur

klik op het plaatje voor een grote afbeelding

Henrik Kniberg geeft in twee video's inzicht in de ontwikkelcultuur bij Spotify. In de eerste video beschrijft hij de uitdagingen waar Spotify voor staat en hoe de ontwikkelcultuur hier op inspeelt. De tweede video start met de wijze waarop Spotify omgaat met fouten. Hier geen extra controlemaatregelen en rapportageverplichtingen. Wel een fout-vriendelijke omgeving waar snel geleerd wordt maar ook de impact van fouten zijn geminimaliseerd. Dit is geen framework maar eerder een bron voor inspiratie. Zie ook dit artikel van Jasper Verdooren.

Onderzoek naar succes- en faalfactoren

Het onderzoek Challenges and success factors for large-scale agile transformations: A systematic literature review heeft 52 grootschalige agile transformaties in de jaren 2004 t/m 2009 bestudeerd. Het betreft ondernemingen als Amazon, BMC software, Yahoo!, Nokia Siemens Networks, Unisys Cloud Engineering, BBC iPlayer, Salesforce.com, MyBoeingfleet.com, Ericsson Nederland, British Telecom, Softwarepeople, Nokia, Microsoft IT, Healthwise, Borland, Siemens Medical Solutions US, Nyx, Verisign Enterprise Security, Primavera Systems, SAP AG, KeyCorp, Capital One, Cisco Voice Technology Group, Qwest communications Pegasystems en anderen.

De antwoorden op de twee belangrijkste vragen luiden:

As an answer to RQ1: “What challenges have been reported for large-scale agile transformations?”, we identified 35 challenges grouped into nine categories, summarized in Table 11. The challenge categories that received the most mentions were: 1) Agile difficult to implement (mentioned by 48% of the cases), 2) Integrating non-development functions (43%), 3–4) Change resistance (38%) and Requirements engineering challenges (38%). From individual challenges the most mentions received: Other functions unwilling to change (31%) and Lack of guidance from literature (21%).

en

To answer RQ2: “What success factors have been reported for large-scale agile transformations?” we identified 29 success factors grouped into eleven categories, as presented in Table 12. The success factor categories that stand out are: 1) Choosing and customizing the agile approach (50%), 2–3) Management support (40%) and Mindset and Alignment (40%), and 4) Training and coaching (38%). From individual success factors the most often mentioned were: Ensure management support (29%), Coach teams as they learn by doing (29%), Customize the agile approach carefully (26%) and Start with a pilot to gain acceptance.

Ten slotte

SAFe en LeSS zijn beide bij Nokia ontstaan. Ari Tikka constateert in deze vergelijking dat LeSS het lerend vermogen van de organisatie veel beter ondersteunt dan SAFe. Uiteindelijk is het een strategische keuze waarvoor de onderneming gaat. Kiezen voor LeSS is wel ingrijpender en vereist meer moed.

Peter Stevens heeft in dit artikel SAFe, DAD en LeSS vergeleken. LeSS komt er het beste uit. Zie ook dit artikel in het Nederlandstalige Managers-online.

Dit artikel met de titel "Frameworks for Scaling Agility; A Cautionary Tale" waarschuwt voor het feit dat nog weinig onderzoek is gedaan naar de effectiviteit van genoemde frameworks. Wel blijkt het volgende:

• An understanding that the biggest challenges are likely to be around people, perceptions and concepts rather than technical
• A willingness to iteratively experiment and to learn
• A culture that engages and empowers both employees and customers to be part of the experiment and learn cycle
• Transparency in everything, including things which don’t work
• Patience; being willing to start small, measure and build on small improvements in customer value, and employee satisfaction