Het is half vier ‘s middags als mijn vliegtuig in een zachte motregen landt op het vliegveld van Seattle Tacoma. Omdat ik deel uitmaak van de Visual Studio Advisory Board ben ik op weg naar de campus van Microsoft in Redmond, het overbekende slaperige voorstadje van Seattle. Maar behalve dat Seattle de reuzen Microsoft en Boeing huisvest, kent ook koffieconcern Starbucks zijn oorsprong in het centrum van de stad, nabij Pike Place Market. Nu drink ik graag koffie, en dus sluit ik nog niet lang na de landing aan in een rij in een van de ruim honderd Starbucks winkeltjes in het centrum van de stad.
Starbucks is een fenomeen. Nog altijd ben ik er niet uit of ik hun koffie lekker vindt of gewoon een warme bak troost. Maar wat me altijd opvalt als ik in een van hun winkels ben, is de bijzondere werkwijze die men hanteert wanneer ik een simpele beker koffie bestel. Degene die de bestelling opneemt, roept deze door naar een collega, die een beker klaarzet en daar iets opschrijft met een zwarte marker. Een andere collega pakt de beker op en vult die met koffie. Dan wordt de beker opgepakt door weer een andere medewerker, en voor mijn neus neergezet. Zo zijn er drie a vier Starbucks-medewerkers nodig om één beker koffie te maken. Knappe samenwerking. Of ik nu in Seattle, Zurich, Honolulu, Amsterdam, Sydney of Kuala Lumpur ben. De werkwijze is identiek. Onwillekeurig denk ik aan die oude mop over hoeveel Belgen er nodig zijn om een gloeilamp in te draaien. Dat moet efficiënter kunnen.
Hok
Helaas zijn wij in ons vakgebied nu niet bepaald een toonbeeld van efficiëntie en samenwerking. Ter lering en vermaak een paar voorbeelden. Ooit maakte ik frameworks voor PowerBuilder. Typisch client server. Totdat we besloten een model view controller te implementeren en zo het opzetten van een laag voor bedrijfslogica te faciliteren. Om dit fraaie stukje technologie te ontwikkelen sloten mijn collega Wim en ik onszelf op in een hok met twee whiteboards en een laptop. Toen we na een week of vier het hok weer uitkwamen waren de whiteboards vol en hadden we een prachtige meerlagenarchitectuur aan ons framework toegevoegd. Jammer alleen dat de ontwikkelaars in de projecten hun werkwijze niet veranderden en ons fraaie werkstuk nooit gebruikt hebben. Ach, we hadden ons in elk geval vermaakt.
Handen geven
Een paar jaar en een werkgever later werd ik gevraagd een audit te doen in een project bij een grote financiële instelling. Ik was dus gewaarschuwd. Nu was dit project zo’n beetje het eerste dat daar met Java werd uitgevoerd. Om een lang verhaal kort te maken: het project telde zo’n honderd medewerkers. Twintig analisten, twintig ontwerpers en natuurlijk ook twintig Java ontwikkelaars. En de nodige overhead: managers, secretaresses, projectbureau, en o ja, niet te vergeten de WebSphere beheerder.
De ontwikkelaars hadden het niet erg druk. Eigenlijk hadden ze niets te doen. Er was namelijk nog geen ontwerp. Maar omdat Java ontwikkelaars extreem schaars waren in die tijd – halverwege de jaren negentig – had de financiële instelling ze maar alvast ingehuurd. Stel je voor dat er geen ontwikkelaars zijn op het moment dat er software gebouwd moet worden. Maar ook de ontwerpers hadden een probleem. De analyses die werden opgeleverd door de analisten waren door de ontwerpers maar moeilijk interpreteerbaar. Geschreven in een taal die ze niet beheersten. En de analisten? Die konden niet anders. Ze hadden het nu eenmaal zo geleerd. En dus werd er in het project geen software opgeleverd. Nog geen regel.
Als advies stelde ik de manager van het project voor in iteraties – van zes weken – te werken waarin kleine brokken van de functionaliteit zouden worden geanalyseerd, ontworpen en gebouwd. Inderdaad. Tegenwoordig noemen we dat agile software development, en doen we dat in iteraties van twee weken. Maar voor een grote financiële instelling halverwege de jaren negentig was dit niet heel erg gebruikelijk. En nog steeds niet, als ik kijk naar de projecten die grote financiële instellingen ruim tien jaar later uitvoeren. Maar goed. Terug naar het project. We besloten om workshops te organiseren. Multidisciplinaire. Terwijl ik het brown paper het schilderstape aan de muur hang voor de eerste, druppelen de deelnemers binnen. Twee analisten, twee ontwerpers, en een ontwikkelaar. Opvallend genoeg geven ze elkaar een hand. “Dat is een goede gewoonte,” zeg ik glimlachend en naïef. “Doen jullie dat hier iedere dag?” De analisten en de ontwerpers kijken mij verbaasd aan en daarna elkaar. “Nee hoor,” zegt een van de analisten dan. “Dat doen we alleen maar omdat we elkaar nog niet kennen.” Het project liep al ruim een jaar en kostte ruim honderdduizend gulden per dag.
Nodeloos toe te voegen dat tijdens dit project nooit software is opgeleverd. Tijdens de eerste iteraties proberen we twee schermen te ontwikkelen – ja, u leest het goed: twee schermen, in zes weken, met twintig ontwikkelaars. Tevergeefs.
Fooien
Kan het nog erger? Ach. Er is altijd een overtreffende trap. Nog niet zo lang geleden kreeg ik van een vriend via de mail een document toegestuurd. Een use case. Van ruim zestig pagina’s. Nu is dat wat veel voor een enkele use case. Ik blader door het document en worstel door tientallen scenario’s. En een dozijn schermen. Dat wordt weer een feest voor de ontwikkelaars. Gelukkig bevinden die zich in India. Anders dan in het vorige voorbeeld is tijdens dit project al wel software geproduceerd. Er zijn ongeveer tien schermen gereed. Maar ja, het project loopt ook pas een jaar. Kosten? Anderhalf miljoen euro per scherm.
Dus wie ben ik om Starbucks te bekritiseren over hun werkwijze? Ik pak mijn koffie van de toonbank en verlaat de winkel. Happy end? Nee, helaas. Het verhaal heeft een staartje. In dezelfde week dat ik in Seattle ben, word bekend dat managers van het koffieconcern in Californië meedeelden in de fooienpot. En dat vond een rechter niet goed. Nu moet Starbucks maar liefst honderd miljoen dollar aan fooien herverdelen. Zo erg is het in ons vak dus nog niet.