Geen van de zes schuiven vraagt naar IT

Waar het woord IT vandaan komt

Dit gilde neemt alleen opdrachten aan binnen IT-levering. Dat staat op de toetredingspagina, en het staat daar los van het criterium waarmee het gilde een leveringsvorm kiest: bij hoge onzekerheid werkt iteratief bouwen beter, bij routinewerk is PRINCE2 het betere antwoord. In dat criterium komt het woord IT niet voor. Het is ook na te kijken, want het staat in lesmateriaal dat gewoon te lezen is.

Dit artikel doet dat nakijkwerk. De vraag die er meteen achter opdoemt, of agile buiten IT werkt, blijft hier onbeantwoord; de laatste sectie zegt waarom dat een keuze is.

Wat het instrument wel vraagt

Deel 16 van de cursus projectmanagement beschrijft de Agilometer als een diagnose-instrument met zes schuiven, elk gescoord van ongeschikt tot zeer geschikt. Ze staan er voluit: flexibiliteit ten aanzien van wat wordt opgeleverd, mate van samenwerking, gemak van communicatie, vermogen om iteratief en incrementeel te werken, gunstige omgevingsfactoren zoals co-locatie en beschikbare tools, en acceptatie van agile werken binnen de organisatie. Geen van die zes vraagt of het om software gaat. Ze vragen naar de opgave en naar de omgeving eromheen.

Cynefin doet in dezelfde paragrafenreeks het andere werk. Het onderscheidt vier domeinen op één as, namelijk hoe de relatie tussen oorzaak en gevolg eruitziet: bekend, met expertise te achterhalen, pas achteraf te begrijpen, of helemaal niet te analyseren omdat er geen tijd is. Ook daar komt geen vakgebied in voor.

Het examen van dezelfde cursus vraagt naar hetzelfde. Op de vraag wat de Agilometer meet, is het goede antwoord dat hij via zes schuiven de geschiktheid van de projectomgeving voor een agile aanpak meet. De docentenhandleiding zet de reikwijdte erbij: de keuze hoort per project, of zelfs per werkpakket, te worden gemaakt, gebaseerd op de aard van dát werk.

Een tweede criterium dat naar hetzelfde kijkt

De cursus businessanalyse komt er langs een andere weg uit. Paragraaf 4.4 van deel 4 zet voorspellend en adaptief werken als twee uitersten neer en noemt vijf situationele factoren die de keuze zouden moeten sturen: hoe goed de behoefte al bekend is, hoe stabiel de context is, hoe duur het is om achteraf bij te sturen, hoe beschikbaar belanghebbenden gedurende het traject zijn, en wat in deze organisatie gebruikelijk en haalbaar is. De voorbeelden die erbij staan gaan over een fysiek systeem en een wettelijke deadline aan de ene kant, en over een nieuwe dienst waarvan niemand nog weet hoe gebruikers hem zullen gebruiken aan de andere. Software komt er niet in voor.

Deel 2 van diezelfde cursus formuleert het nog ruimer voor het denkraam waar die factoren onder hangen: één denkraam dat overal toepasbaar is, bij een pensioenprogramma net zo goed als bij een fusie, een wetswijziging of een verbouwing.

De vijf factoren en de zes schuiven vormen samen geen methode; ze delen geen enkele term. Wie ze naast elkaar legt ziet gelijkenis. Beschikbaarheid van belanghebbenden lijkt op de schuif voor samenwerking, en wat gebruikelijk is in de organisatie lijkt op de schuif voor acceptatie, terwijl geen van beide lijsten naar de andere verwijst. Ze hebben wel iets gemeen. Twee cursussen die niets van elkaar overnemen, komen allebei uit op een keuzecriterium waarin geen vak wordt genoemd.

Waar het materiaal zelf de overstap maakt

Deel 1 van niveau 1 van de cursus projectmanagement gaat een stap verder, en dat deel gaat niet over agile. Het opent met de post-mortem van een mislukt IT-project en destilleert daar zeven bevindingen uit. De eerste opdracht legt zeven situatiebeschrijvingen uit andere organisaties voor, die cursisten elk aan een bevinding moeten koppelen. Drie daarvan zijn geen IT: een marketingproject waarvan de beloofde omzetstijging nooit is nagemeten, een reorganisatieproject waarvan de risico's op een lijst stonden terwijl niemand ze zag aankomen, en de verbouwing van een kantoorpand die doorloopt zonder tussentijds beslismoment.

De antwoordsleutel behandelt ze volstrekt gelijkwaardig. Het marketingproject krijgt bevinding zeven, het reorganisatieproject bevinding zes en de verbouwing bevinding drie, precies zoals het IT-voorbeeld bevinding vijf krijgt. Bevindingen die uit een softwaredossier zijn afgeleid, worden hier zonder voorbehoud op drie andere soorten werk toegepast.

Wat dat aantoont is begrensd. Het gaat om projectbesturing en niet om een leveringsvorm: een levende business case, toleranties, eigenaarschap van risico's, zicht op baten. Dat het lesmateriaal de overstap naar andere vakgebieden hier zonder aarzeling maakt, zegt iets over hoe domeinvrij het zichzelf opvat. Over agile zegt het op deze plaats niets.

De andere helft van hetzelfde instrument

Aan een criterium dat geen vakgebied noemt zit een keerzijde, en die hoort er in dezelfde adem bij. De vierde schuif vraagt naar het vermogen om iteratief en incrementeel te werken, en dat vermogen zit in het werk zelf. Werk dat pas iets oplevert wanneer het in zijn geheel af is, scoort daar laag, ongeacht wie het uitvoert.

De cursus risicomanagement laat zien hoe dat uitpakt. Deel 17 beschrijft vijf projecten binnen één programma, waarvan het ene volledig agile werkt met tweewekelijkse sprints en het andere gefaseerd, vanwege de aard van het werk: grondige, sequentiële opschoning laat zich moeilijk in korte sprints opdelen. Beide projecten horen bij hetzelfde IT-programma. Het verschil komt uit de vierde schuif en niet uit het vak waarin gewerkt wordt.

Daarbij hoort de regel uit deel 16 die bij de Agilometer het zwaarst weegt: neem nooit het gemiddelde van de zes scores. Eén lage score wijst op een specifiek risico dat aandacht verdient, en een hoog gemiddelde met daaronder één laagste score verbergt precies wat het instrument moet blootleggen. Wie een opgave beoordeelt waarin het werk zich niet laat opdelen, mag die ene score dus niet wegstrepen tegen vijf gunstige.

De verwachting dat werk buiten IT vaker laag uitkomt op deze schuif is een redenering en geen bevinding uit het materiaal. Het lesmateriaal koppelt lage scores op deze schuif nergens aan een vakgebied.

Het begrippenpaar dat hier niet werkt

De voor de hand liggende manier om dit op te schrijven is Business Agility tegenover IT-agility. Dat paar houdt op dit materiaal geen stand.

Deel 1 van de SAFe-cursus belooft het breed: Business Agility is het vermogen van de hele onderneming, niet alleen de IT-afdeling, om te reageren op marktkansen en bedreigingen. Deel 2 maakt dat concreter door Lean te beschrijven als iets dat gaat over de stroom van waarde door de hele organisatie, inclusief onderdelen die niets met softwareontwikkeling te maken hebben, zoals inkoop, compliance of HR.

Deel 3 zet de zeven kerncompetenties in een tabel, met per competentie een kernvraag en de plaats in de cursus. Bij Organizational Agility staat als kernvraag hoe wendbaar de bredere organisatie is, niet alleen IT. In de kolom ernaast staat niveau 2-3. In de tachtig bestanden van niveau 2 en niveau 3 samen komt de term geen enkele keer voor. De enige plek waar de reader hem concreet maakt, is de vaststelling dat de post-mortem van een IT-project tekortkomingen liet zien in leiderschap en in Organizational Agility.

De enige oefening in de hele cursus die buiten IT kijkt, staat in het werkboek van datzelfde deel 3. Een compliance-afdeling buiten IT werkt nog volledig volgens jaarplanningen en kan niet snel meebewegen met een bijgestelde ART-prioriteit. Het modelantwoord luidt in zijn geheel: Organizational Agility. Over hoe die afdeling dan wel zou moeten werken staat er niets, hier niet en verderop ook niet.

Dat is een uitspraak over dit lesmateriaal en niet over SAFe. Een raamwerk wordt niet weerlegd doordat een cursus over de eerste niveaus ervan zwijgt. Wat het wel betekent is dat een standpunt dat op dit begrippenpaar rust hier geen grond onder zich heeft, want de plaats waar het concreet zou worden is een doorverwijzing naar niveaus waarin de term niet meer voorkomt.

Waarom de grens van het gilde toch bij IT ligt

Tot zover het instrument. De grens van dit gilde is een andere zaak, en hij volgt niet uit het voorgaande.

Dit gilde neemt alleen opdrachten aan binnen IT-levering. De reden zit in de leden. Daar hebben zij hun vakmanschap opgebouwd en daar is hun oordeel door vakgenoten na te rekenen. Buiten dat gebied is er niemand in de groep die dat kan doen. Toelating rust op aantoonbare ervaring, en ervaring die geen van de leden kan toetsen draagt die toelating niet.

Dat is een bekwaamheidsgrens. Het is geen uitspraak over waar agile werkt, want zo'n uitspraak zou bewijs veronderstellen dat hier niet ligt. Het onderscheid is de moeite van het uitspreken waard, omdat de twee in een gesprek makkelijk in elkaar schuiven: wie zegt dat hij alleen binnen IT werkt, wordt gehoord als iemand die vindt dat het daarbuiten niet werkt, en dit artikel houdt die twee daarom uit elkaar.

Twee bezwaren die blijven staan

Het eerste bezwaar is dat een domeinvrij criterium en een domeingebonden praktijk niet bij elkaar passen. Wie daaruit opmaakt dat de grens willekeurig is, of commercieel, heeft een punt dat met dit materiaal niet te weerleggen is. Er is geen vakinhoudelijke redenering die zegt dat de grens bij IT hoort te liggen. Er is een groep mensen met een eigen geschiedenis, en daarop rust de keuze. Dat bezwaar valt hier niet te beslechten, en het staat er daarom zonder weerwoord.

Het tweede bezwaar treft het instrument zelf. De Agilometer is een instrument voor projecten en werkpakketten, en deel 16 spreekt nergens over iets anders. Veel werk buiten IT is doorlopend werk in een lijnfunctie, en daarover zegt het instrument niets. Het criterium is domeinvrij binnen een vorm, en wie het naar lijnwerk wil uitbreiden doet dat zonder dekking uit deze bron.

Wat hier open blijft

De vraag of agile buiten IT werkt blijft onbeantwoord, en dat is geen nalatigheid van dit stuk. In het geraadpleegde materiaal staat geen casus waarin buiten IT iteratief wordt geleverd, en er staat evenmin een opdracht waaruit dat te putten valt. Een voorbeeld van buiten binnenhalen en het opvoeren alsof het bewijs was, is precies wat op deze site eerder is afgewezen.

Dezelfde leegte geldt de andere kant op. Er staat ook geen casus waarin buiten IT voorspellend wordt geleverd en dat achteraf het betere antwoord bleek. Dat een cursus over iets zwijgt, levert geen bevinding op over de wereld buiten die cursus.

De voorwaarde waaronder de grens van het gilde zou verschuiven is wel te noemen: een lid dat dit werk buiten IT heeft gedaan en van wie het oordeel binnen de groep door vakgenoten te toetsen is. Zolang dat lid er niet is, verschuift er niets, en wanneer het zover zou zijn valt hier niet te voorspellen.

Het onderwerp bij dit artikel staat open voor wie zo'n geval kent.