comments 3

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…?
Advertisements

3 Comments

  1. Willem-Jan Ageling

    Heel vaak weten grote (traditionele) bedrijven zich de echte Agile denkwijze niet eigen te maken. Heel tragisch. Ik denk dat dit een signaal is dat deze bedrijven zich niet kunnen aanpassen aan de huidige tijd van grote veranderingen. Gevolg: ze gaan ten onder.

    Goed verhaal!

    • frederik

      Dag Willem-Jan, bedankt voor je reactie!

      Momenteel werk ik in een grote Belgische bank, ik kan je verzekeren: het is een moeilijke opdracht om de traditionele manier van werken en denken om te vormen tot agile.

      De punten in het artikel beschreven ervaar ik in de praktijk:

      1. Men denkt enkel in termen van projecten en releases (niet in termen van een continue ‘value stream’). Met de traditionele problemen: backward planning, releases dates die niet gehaald worden. De uitdaging is om dit “program/project management’ vehikel om te vormen naar een portfolio management met agile inschattingen en planning. Elke release zijn er problemen, delays, en het is telkens opnieuw alle hens aan dek om de release te verzekeren. Zolang men de huidige project activiteiten in waterval modus niet kan afsluiten, is het moeilijk om over te gaan naar agile.

      2. Resources zitten nog steeds verankerd in de verschillende entiteiten in de hiërarchische organisatie structuur (elk met hun ‘line’ manager). Een cross-functioneel team samenstellen is niet mogelijk op een korte termijn. Het zou veel interessanter zijn indien men agile teams zou kunnen samenstellen uit een gezamenlijke ‘resource’ pool. En wanneer teams goed functionerend zijn: deze samenhouden. Het beleid m.b.t externen is ook nefast om lange termijn relaties te onderhouden. Traditionele rollen zoals een ‘project manager’ of ‘IT delivery manager’ blijven behouden, naast het agile team en de scrum master…

      3. De basis agile principes en waarden zijn bijlange nog niet doorgedrongen in de organisatie of specifiek het programma waar ik op werk. Het vergt een ongelofelijke verandering in denken, aanpak en “mindset” om agile te zijn. Langzaamaan leren we mensen agile en scrum (wat voor velen nieuw is of men heeft er een verkeerd beeld van, of vooroordelen …). Nu, deze organisatie betreft een bank, sommigen werken 10tallen jaren in een zelfde positie of zelfs hun hele leven in de bank… de boodschap is met geduld en op een diplomatische manier de “nieuwe manier” van werken toelichten en continue begeleiding van het nieuwe agile team.

      Zolang men er niet in slaagt om basis agile teams te organiseren en performant te laten functioneren, heeft het weinig tot geen zin om agile toe te passen op grote schaal (zoals het volledige programma).

      4. De organisatie is nog ver van een correcte implementatie van Scrum, getuige daarvan:
      > Niet 1 product owner, maar zowel een business vertegenwoordiger die de rol van product owner opneemt (voorheen de business analist) en een product manager/owner van marketing
      > Een scrum master en een project manager, en delivery manager. De project manager creëert een planning (op voorhand) voor de sprints. De delivery manager is de tussenpersoon met de partner voor de software ontwikkeling.
      > Geen effectieve prioritisatie top-down van items in een product backlog
      > etc.

      • Willem-Jan Ageling

        Frederik ik herken veel van je ervaring. Zelf heb ik ook jarenlang bij grote banken gewerkt met wisselende ervaringen. Waar ik zelf het meest trots op ben dat we eind jaren negentig de volgende werkwijze hadden:

        – Maak een lijst met items die we willen implementeren in onze software
        – Prioriseer deze lijst regelmatig aan de hand van nieuwe informatie (nieuwe items, vervallen items, nieuwe omstandigheden),
        – Stel elke twee maanden een set van items samen die we gaan oppakken in een nieuw increment.

        Veel aspecten die Scrum-like zijn. Natuurlijk veel ook niet, want de periodes waren langer en ieder teamlid had zijn eigen gescheiden taak (analyse, programmeren, testen).

        Later is hier van afgestapt en kwam er een verdeling tussen projectorganisatie en maintenance organisatie. Dit zorgde helaas voor veel extra overhead en veel problemen die jij ook benoemt.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s