Finalist zet graag in op innovatie en daaronder valt ook onze projectmethodiek. Hoe fijn Scrum/Agile ook werkt, mijn ervaring is dat het soms niet “past”. Dus hoe weet je nu of Scrum voor jou is?

Scrum? Beetje eng!

To Scrum or not to Scrum? De keus is een belangrijke, aan het begin van het project. Vaak is het voor het eerst in de bestaansgeschiedenis van het bedrijf dat Scrum ter sprake komt. Prince2 en RUP zijn vertrouwde namen, waaraan iedereen gewend is. En waarom zou je het extra risico van een onbekende werkwijze toepassen op IT projecten die doorgaans toch al zo risicovol zijn? Er zijn voor Scrumbeginners weinig waarschuwingen. “Spring maar in het diepe”…

De voordelen van Scrum/Agile staan op elke fanpagina erover, maar risico’s, daar hebben we het minder over. Toch kan Scrum ook een verkeerde keuze zijn, heb ik geleerd. Er is geen checklist “Is Scrum de beste manier voor het project?”. Dus die heb ik gemaakt. Vele pijnlijke lessen zijn erin verwerkt.

Let op: Al deze checkpunten gaan over de organisatie van de opdrachtgever en het team medewerkers dat het Scrum project aanstuurt. Het gaat dus niet over developers.

De checklist

Hoe meer vinkjes je zet, hoe groter de kans dat Scrum je uitstekend bevalt. Bijna geen enkele organisatie scoort 100%, dat lukt meestal pas na meer ervaring met Scrum.

De hoofdaanname: Enthousiasme

Je beschikt over een team van 2 à 5 vrijwilligers die staan te popelen om dit project vorm te geven.

Elke methodiek faalt onder tegenzin van degenen die het trekken, maar Scrum vraagt extra inzet van de Product Owner. Die extra energie betaalt zich overigens dubbel en dwars terug in het eindresultaat.

Pluspunten

1. Heeft het team een gepassioneerde leider? Kent hij/zij het domein en mag hij/zij knopen doorhakken? (De product owner)

Scrum geeft meer resultaat als je fout beslist dan als je de beslissing uitstelt. Iemand moet de knoop doorhakken en die moet niet teruggefloten kunnen worden.

2. Zijn de teamleden bereid 2 dagen per week te investeren?

Scrum kost tijd, veel tijd. Een Prince2-papier-project kun je “ernaast doen”, in de avonduurtjes. Scrum richt op direct persoonlijk contact. Scrum kost tijd van je werkdag.

3. Passen alle stakeholders aan dezelfde vergadertafel? Zijn hun onderlinge relaties goed?

Oud zeer en getrapte communicatie vertragen beslissingen, eindeloos. Intussen zit een Scrum team te wachten, ze kunnen niet verder.

4. Bewijzen alle betrokkenen hun enthousiasme tot nu toe door aanwezigheid, actieve deelname en constructieve acties?

Als het project eenmaal loopt is er geen tijd om ego’s te strelen of cynici te enthousiasmeren. Het doel, werkende software, moet voor alle deelnemers ruim voldoende motivatie zijn.

5. Zijn alle stakeholders vertegenwoordigd en mag de Product Owner beslissen namens hen die niet aan tafel zitten?

Tegenvallers in het product zijn beter te verkroppen als een collega uitlegt hoe het compromis het minste van twee kwaden is geworden. Ingebruikname verloopt zo een stuk vloeiender.

6. Is het probleem een investering waard? Welke meerwaarde levert de te bouwen software?

RUP schotelt je stapels elegante ontwerpdocumenten voor: “Dat moet het geld wel waard zijn, toch?” Scrum/Agile levert de software die je vraagt. Je oogst meteen de meerwaarde, als die er is tenminste.

7. Heeft de Product Owner sparringpartners en een sterk netwerk? Bijvoorbeeld ervaringsdeskundige software-ontwikkeling?

Niemand is alwetend. Software-ontwikkeling sturen is een tikje anders dan je normale werk. Hulp is dan welkom.

8. Hebben betrokkenen (nog) niet emotioneel geïnvesteerd in lijvige ontwerpdocumenten over het product?

Strikte, op elke pagina gaparafeerde afspraken over wat je wèl en wat je niet gaat krijgen, hebben niks te maken met Scrum/Agile. Beman het team desnoods met ‘blanco’ mensen.

9. Kan het team inhoudelijke vragen (”hoe werkt dit…, hoe doen jullie dit..”) binnen een paar uur (max. 2 dagen) beantwoorden?

Als het team voor alles ‘de organisatie in moet’ zitten de verkeerde mensen in het team.

10. Kan het project rekenen op medewerking van benodigde derden? Denk aan collega’s, dienstverlener/productleverancier, juridische dienst, afdeling communicatie

Software raakt iedereen in de organisatie en dus ook andermans verantwoordelijkheden. Scrum gaat de confrontaties aan en snel. Gaat de rest improviseren of dwarsliggen?

11. Staan alle betrokkenen voor een pragmatische aanpak? Gebruikt men de 80/20 regel: “durven schrappen”

Scrum betekent: Budget is begrensd. Tijd is beperkt. Maar: Wensen blijven altijd onbeperkt. Scrum trekt constant een grens. Dat is schrikken als je de roze wolken van RUP specificaties gewend bent: Daarin staan vooral ook alle fantasie-functies, die nooit gebouwd worden.

12. Durven alle stakeholders ‘Ja’ te zeggen tegen een visie, zonder gespecificeerde details, vertrouwend op elkaars voortschrijdend inzicht?

Want morgen weet iedereen altijd nog nauwkeuriger wat hij wil. Afspraken ‘in steen’ geven alleen rust aan mensen die niet dagelijks betrokken willen zijn. Die heb je dus niet nodig.

13. Zou er zoiets kunnen bestaan als een ‘minimale versie’ van het product, zonder poespas?

Een mini-resultaat dat al vanaf dag 10 bruikbaar is en telkens verfijnd wordt maakt teamleden trots. En terecht.

14. Kan het product binnen enkele maanden goedgekeurd worden, gegeven de doorlooptijd van toepasselijke toetsingsprotocollen?

Denk aan domeinen met geheimhouding en/of fysiek gevaar. Een Scrum team is een geoliede machine, een eenheid. Maar prestaties dalen zienderogen als je een team ‘in de wacht’ zet of tijdelijk de capaciteit terugschaalt.

Scrum past soms verrassend goed

Als je de nadruk op snelheid en besluitvaardigheid opmerkt in de checklist, zou je misschien niet verwachten dat wij met Scrum meerdere keren succes hebben behaald bij de overheid, in verschillende gemeenten. Zo blijkt maar weer dat je de checklist niet moet invullen op basis van vooroordelen!

Mis je iets?

Deze checklist is geboren uit mijn persoonlijke ervaringen en verwoord in mijn eigen stijl. Het kan zijn dat je er iets aan wilt toevoegen. Ga je gang in de comments.