Scrum Scaled for Large Projects and Organizational Initiatives

Ken Schwaber’s point of view on scaling Scrum. With a smile I’ve read Ken’s comment: “Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling.”

Growing concern, I must concur. As well, I experience how organisations are struggling and seeking how to scale scrum. Recently, Gunther presented the issue at #atbru (Agile tour Brussels) in his talk “Empirical management explored”.

My observations:
* Organisations not yet able to decently organize Scrum at team level, should not embark on a journey to scale Scrum beyond that team level.
* If such organisations do attempt to scale Scrum, they will scale dysfunctions.
* Organisations still stuck in the classic management paradigm are steer-less seeking to get product creation organised in an incremental and iterative way, still mixing it with many waterfall practices (predictive long-term project planning, absurd guesstimates, lack of transparency, …). On the way, they end up with a self-defined framework; mixing it all up.

The bottom line is:
* Invest wisely to get organized to transform your teams to Scrum
* Invest wisely to maximize Scrum at team level, and next with multiple teams, and next with multiple products > this subsequent growing approach is the sound approach to scale
* Live and breathe the Scrum Stance and agile values
> Invest in people and teams
> Manage and plan based upon real metrics and evidence
> Focus on business value

Scrum Scaled for Large Projects and Organizational Initiatives

Wat voornamelijk niet doen bij het vergroten van agile teams

How NOT to scale agile

“Scaling” agile betreft het schalen van agile groter dan het team niveau.

Tiago Garcez @tcgarcez gaf hierover een interessante sessie op #atbru 2014. Slides: “How NOT to scale agile”. Deze post is gebaseerd op zijn sessie.

Er werden redenen aangehaald dat agile niet zomaar geschaald hoeft te worden; en dat een aantal  praktijken in organisaties haaks staan op agile waarden.

1. Projecten

Projecten zijn per definitie eindig. Echter, verandering en transformatie naar een agile manier van denken en werken is niet eindig.

2. Resource planning

Resource planning optimaliseert het gebruik van resources. Typisch in een organisatie betekent dit dat mensen verschillende activiteiten uitvoeren voor meerdere projecten. Individuen worden ook vaak opnieuw ingepland op andere projecten, en in andere teams ondergebracht. Dit is nefast voor de productiviteit en de samenhorigheid van een team. Een medewerker in deze omstandigheden heeft last van context-switching en ziet niet het resultaat van zijn werk.

Bottom-line: investeer in teams en hou goed werkende teams stabiel.

3. Focus niet op efficiëntie

Maar focus op effectiviteit. Efficiëntie betekent optimalisatie (van resources). “Een resource die niet werkt is niet efficiënt“. Wat we nodig hebben zijn individuen die effectief zijn in hun activiteiten. Het over focussen op efficiëntie leidt in middelgrote tot grote organisaties tot nefaste effecten waarbij medewerkers niet de kans/tijd krijgen om zichzelf te ontplooien of om goede werkrelaties op te bouwen met collega’s.

4. Focus op de eindgebruiker

Vaak zien we projecten heel sterk focussen op de (interne) klant, en vergeet men wie de feitelijke eindgebruiker is. Met een juiste aanpak (lean UX, incrementele persona’s, herhaalde testing met eindgebruikers, …) en technieken kunnen we meer zeker zijn dat hetgeen wat we bouwen effectief nuttig zal zijn voor de eindgebruiker van het product (en niet enkel de interne klant: bv. het marketing departement, …).

5. Schaal geen incompetenties

De basis is belangrijk: get the basics right. Slechts als een team agile ademt, kan je bekijken hoe je kan uitvergroten over meerdere teams heen. Alle agile waarden zijn belangrijk, en niet enkel dat. Denk niet dat goede engineering praktijken er niet meer toe te doen. Expertise, vakmanschap en een agile samenwerking zijn de basis voor productiviteit en resultaat. Als je dit bereikt hebt in meerdere teams, kan je kijken hoe je dit kan schalen over de teams heen.

6. Geen traditionele carrière paden

Organisaties focussen heel erg op een carrière pad dat start bij een beginnende functie en vervolgens het individu promoveert tot een ‘hogere’ functie. Vb. van junior ontwikkelaar, naar senior ontwikkelaar, naar team manager, naar project manager. Of van business analist, naar manager. Van junior associate, naar senior associate, naar partner. What’s in a name?

Laat mensen doen waar ze goed in zijn. Verplicht hen niet om een bepaald carrière pad te bewandelen indien met ‘hogerop’ wil geraken zowel qua verloning als aanzien bij een hogere anciënniteit. Een ontwikkelaar die zijn werk met passie en expertise doet, kan dit met passie zijn hele carrière beoefenen – en waardeer hem daarvoor met een gepaste remuneratie. Idem dito voor alle andere rollen. Hou een carrière pad gezond en op maat van het individu.

Persoonlijk hou ik niet van senior functies. Senior kan duiden op de leeftijd, maar het gaat hem voornamelijk om de ervaring, kennis en aanpak.

7. Schaal geen processen

Schaal geen processen op een blindelingse manier. Het op grote schaal toepassen van een proces (zoals Scrum) zonder de agile waarden zal leiden tot een heel mechanische manier van werken. Investeer eerst in de teams, hun cultuur, hun doelstelling en het onderling vertrouwen.

8. Schaal niet indien niet nodig

Bekijk of dat het toepassen van agile op grote schaal onontbeerlijk is. Hebben we meerdere agile teams die succesvol en correct werken? Wat is de huidige norm van agile projecten? Kunnen we succesvol zijn in het realiseren van meerdere agile teams? Is het überhaupt nodig voor ons om teams te schalen?

9. Stop outsourcing omwille van foute redenen

Mijn suggestie: stop outsourcing omwille van foute redenen. Organisaties gaan vaak de mist in als men al hun activiteiten wilt outsourcen. Mijn inziens het pijnlijkste voorbeeld hiervan in het outsourcen van research. Een organisatie heeft er alle baat bij om research intern te verwezenlijken: behoud de kennis, train mensen in de technieken en stop niet met het (markt)onderzoek na oplevering van de studie.

Do not outsourch your research.

Scrum en scaling

Opinies verschillen. Huidig is over het scalen van Scrum volgende gedefinieerd:

  • Scrum.org: Scaling Scrum
  • SAFe (Scaled Agile Framework)
  • LeSS (Large-Scale Scrum)
  • Andere frameworks…?