Gedistribueerde scrum op papier

6.2.1 Gedistribueerde software ontwikkeling

De afgelopen jaren zien we in de software industrie een snelle toename van bedrijven die ofwel soft-wareprojecten volledig uitbesteden aan een andere organisatie ofwel hun eigen ontwikkelcentrum starten op een andere locatie. Er zijn allerlei ontwikkelingen gaande die maken dat gedistribueerde software ontwikkeling meer en meer normaal wordt (Herbsleb en Moitra, 2001). Denk hierbij aan het kostenperspectief, de noodzaak van het vinden van gekwalificeerd, hooggeschoold personeel, de veranderende markt, en overnames en fusies (Damian en Moitra, 2006; Herbsleb, 2007).

Diverse onderzoeken en praktijkervaringen wijzen uit dat gedistribueerde software ontwikkeling, ook wel aangeduid als 'global software development' (GSD), specifieke complexiteit en uitdagingen kent. Software ontwikkeling is een sterk onderling afhankelijke en onzekere taak, waarbij veel informele communicatie en coördinatie nodig is. Teamleden moeten maanden aan een code werken die uitein-delijk perfect moet passen. Het volledig specificeren van ontwerpen is bij aanvang niet mogelijk. Er zullen altijd onverwachte beslissingen genomen moeten worden, details nader ingevuld moeten wor-den. De kans op onverwachte problemen is groot en die problemen moeten vervolgens snel opgelost kunnen worden. Het is onvermijdelijk dat er werk opduikt dat niet van tevoren was in te plannen of vast te leggen (Herbsleb en Grinter, 1999).

Software ontwikkelen vraagt dus veel ad hoc, informele communicatie en informatie uitwisseling. De behoefte daaraan neemt toe als de omvang en complexiteit (bijvoorbeeld als gevolg van distributie) van een project toeneemt (Herbsleb en Moitra, 2001). Het fundamentele probleem van GSD is dat de mechanismen die helpend zijn in de coördinatie, bij gedistribueerd ontwikkelen afwezig zijn of ver-stoord raken. Het gaat dan om de volgende elementen:

de hoeveelheid communicatie en de effectiviteit ervan is minder groot (minder communicatie en minder effectieve communicatie),

het gebrek aan contextuele informatie van de andere locatie creëert een gebrek aan bewustzijn van de andere locatie,

en de locaties verschillen vaak in ontwikkeltools, werkprocessen en manieren van aanpak die (mogelijk) niet verenigbaar zijn (Herbsleb, 2007).

In een aantal onderzoeken komt kennisoverdracht als belangrijkste uitdaging naar voren in gedis-tribueerde software ontwikkeling (Kristjansson e.a., 2012). Holmström e.a. (2006) en Ägerfalk e.a. (2005) spreken van afstand en onderscheiden drie dimensies: een tijdsafstand, een geografische af-stand en een sociaal culturele afaf-stand. Op drie gebieden zien zij kansen en bedreigingen: (1) op het vlak van communicatie, (2) op het vlak van coördinatie en (3) op het vlak van controle. Door deze ge-bieden af te zetten tegen de drie afstandsdimensies ontstaat een matrix (Impacts of three Distance Dimensions on GSD processes), waarin elke plus (+) een kans weergeeft en elke min (-) een uitdaging. (zie de onderstaande matrix).

Impacts of three Distance Dimensions on GSD Processes

Distance Dimension

Temporal Distance Geographic Distance Sociocultural Distance

Im p ac t o n G SD p ro ce ss C o mmu n ic at io n + Improved record of communications

+ Potential for closer proximity to market and utilization of remote skilled workforces

+ Potential for stimulating innovation and sharing best practices

- Reduced opportunities for synchronous communication

- Increased cost and logistics of holding face-to-face meetings - Risk for misunderstandings C o o rd in ati o n + Decreased coordination needs due to division of labor

+ Increase in size and skills of labor pool can offer more flexible

coordination planning

+ Access to rich skill set and various practices

- Increased coordination costs

- Reduced informal contact can lead to lack of task awareness

- Inconsistency in work practices can impinge on effective coordination as can reduced cooperation through misunderstandings C o n tr o l

+ Opportunities for round-the-clock development

+ Communication channels often leave an audit trail

+ Access to rich skill set and authority - Management of project

artifacts may be subject to delays

- Difficult to convey vision and strategy

- Difficult perceptions of authority, hierarchy can undermine morale

6.2.1.2 Technische oplossingen versus de sociale componenten

Traditioneel heeft veel onderzoek in de wereld van de informatica zich gericht op technische aspec-ten om de uitdagingen aan te pakken, zoals bijvoorbeeld modulair bouwen of het werken met inte-gratieplannen. Ook het gebruik van ontwikkelomgevingen en de inzet van hulpmiddelen voor gedis-tribueerde softwareteams (zoals bijvoorbeeld chat tools en awareness tools) om coördinatie en com-municatie te realiseren zijn ruimschoots onderzocht (Herbsleb, 2007). Gelet op de discipline, ICT, is dat niet verwonderlijk. Een toelichting op deze uitgebreide hoeveelheid onderzoeken is hier niet op zijn plaats.

Samenwerken is naar mijn overtuiging primair een menselijke activiteit. Oplossingen moeten dus ook in de sociale wereld gezocht worden. Mijn zoektocht richt zich dan ook op de menselijke en sociale aspecten die bij de gedistribueerde ontwikkeling van software om de hoek komen kijken. Literatuur over de impact van specifiek sociale factoren op succesvolle samenwerking in een software omgeving is beperkt, maar aanwezig. Kotlarsky en Oshri (2005) geven aan dat het belang van sociale aspecten binnen de informaticaliteratuur lang genegeerd is. Als er al aandacht aan besteed wordt, dan is het volgens hen met name gericht op co-located software ontwikkeling. In het licht van mijn zoektocht is hun onderzoek interessant en relevant. Ze laten aan de hand van twee casussen het belang zien van menselijke aspecten. In het bijzonder ‘het hebben van een sociale band’ en activiteiten rondom ken-nisdeling zijn in hun ogen van belang voor succesvolle samenwerking. Zij pleiten ervoor dat organisa-ties mechanismen ontwikkelen die ruimte bieden voor deze sociale component.

6.2.2 Gedistribueerde scrum

Ten tijde van de opkomst van agile software ontwikkeling was het niet gewoon om software te ont-wikkelen in gedistribueerde teams. In recente jaren is, zoals eerder geschetst, gedistribueerd soft-ware ontwikkelen meer normaal geworden. In het kielzog van deze ontwikkelingen is ook de inte-resse gegroeid voor de mogelijkheden en onmogelijkheden van agile ontwikkelmethodieken binnen gedistribueerde software. Hossain e.a. (2009) geven in hun overzichtsartikel een weergave van twin-tig papers over scrum binnen global software development. Ze constateren een groeiende interesse in het gebruik van scrum binnen gedistribueerde ontwikkelprojecten en concluderen ook dat er suc-cessen gerapporteerd worden. De mechanismen die ten grondslag liggen aan deze sucsuc-cessen worden echter nog onvoldoende begrepen.

Uit hun bevindingen blijkt ook dat voor gedistribueerde scrumteams enkel het raamwerk van scrum onvoldoende is en dat aanvullende strategieën nodig zijn. Ze maken melding van zeven factoren waar rekening mee gehouden moet worden bij het gebruik van scrum binnen de context van global software development:

Het synchroniseren van de communicatie wat vooral speelt in projecten waarbij sprake is van een groot tijdsverschil tussen de verschillende locaties.

Samenwerkingsprocessen die bemoeilijkt worden door de ‘socio-culturele’ afstand. Strategieën die genoemd worden om deze problemen te overbruggen zijn onder andere het samen op één locatie werken gedurende een aantal sprints, regelmatige bezoeken over en weer, frequente informele bijeenkomsten naast de formele bijeenkomsten, documenteren, het bijhouden van documentatie, verplichte deelname door bijvoorbeeld presentaties en tot slot de overgang van co-located naar gedistribueerd werken geleidelijk laten verlopen.

Verschillende mogelijkheden en middelen die men ter beschikking heeft om te communiceren. Hulpmiddelen om samen te werken zoals bijvoorbeeld wiki's, blogs, elektronische white boards. De teamgrootte.

De werkruimte. Om te zorgen voor betere communicatie en samenwerking krijgen sommige teams een eigen ruimte, soms krijgen teams ook een eigen meeting room toegewezen. De hoeveelheid locaties (sites) waarover het team verdeeld is.

Mike Cohn (2009) besteedt in zijn praktijkboek 'Succeeding with agile'een hoofdstuk aan scrum in gedistribueerde teams. Ook hij maakt melding van aanvullende strategieën die nodig zijn om gedistri-bueerde scrum succesvol te laten zijn. Hij baseert zijn schrijven op praktijkervaringen van verschillen-de mensen. De belangrijkste uitdaging is in zijn optiek het 'bij elkaar blijven' van het team. Een be-langrijke rol om ‘bij elkaar te blijven’ ziet hij daarbij weggelegd voor de product-owner, die kan zor-gen voor een duidelijke productvisie en roadmap. Het onderzoek van Hoda e.a. (2011) bevestigt dit. In dit onderzoek wordt ook geconcludeerd dat onvoldoende klantbetrokkenheid negatieve impact heeft op de zelfsturende agile teams.