In het verleden werden applicaties vaak als één groot monoliet systeem gebouwd. Doordat deze applicaties in grote mate geïsoleerd van de omgeving opereerden, konden ze ook in grote mate geïsoleerd van de omgeving ontwikkeld worden. Tegenwoordig zijn het echter complexe ketens, bestaande uit meerdere applicaties. Hierbij wordt maatwerk software geïntegreerd met standaardpakketten. Informatie legt daarbij een reis af door deze keten en wordt op verschillende plaatsen verrijkt, geconverteerd, berekend, vastgelegd en doorgestuurd.
Wanneer er een nieuw product gerealiseerd wordt, moet er vaak op meerdere plekken in de keten aanpassingen worden gedaan. Ontwikkeling is daarmee complexer, maar ook meer gefragmenteerd. Dit heeft als voordeel dat er met verschillende teams parallel aan dezelfde functionaliteit gewerkt kan worden.
Dit artikel beschrijft een aantal ervaringen en handreikingen bij het opzetten van een Agile/Scrum-project met meerdere teams.
Meer betrokkenheid
Agile ontwikkeling in een Scrum-team zorgt voor meer betrokkenheid van de business en vroegtijdige bijsturing van het project. Hiermee is de quality-to-market geborgd. Maar Scrum schrijft relatief kleine teams voor. Daarmee rijst de vraag hoe je bij grotere projecten toch ook een acceptabele time-to-market kunt halen. Een mogelijke oplossing hiervoor is het inrichten van meerdere teams, die parallel aan hetzelfde project werken. Een uitdaging daarbij is om de teams efficiënt te laten werken zonder sturing over het geheel te verliezen.
Wat zijn nu de randvoorwaarden voor een succesvol project met meerdere Agile-teams? Hoe kun je teams geïsoleerd van elkaar laten werken aan een brug, zodat de twee helften van de brug ook bij elkaar uit komen?
- Teams dienen onafhankelijk van elkaar en van de (technische) omgeving te kunnen werken.
- Teams dienen zo min mogelijk last van elkaars impedements (belemmeringen) te ondervinden;
- Er moet één ‘product owner’ zijn voor de verschillende teams. Eén kapitein die de prioriteit en richting bepaalt en daarnaast ook budgethouder is. Dit voorkomt dat er voor het ene team de keuze wordt gemaakt functionaliteit A te realiseren en in het tweede team functionaliteit B;
- Zorg voor afstemming tussen teams door de Scrum-masters van de verschillende teams te laten overleggen;
- Doe een gezamenlijke ‘backlog grooming sessie’ met de product owner en de Scrum-masters om een heldere product backlog te realiseren als input voor de pokersessies;
- Houd bij het plannen van de te realiseren functionaliteit ook rekening met onderlinge afhankelijkheid. Laat verschillende teams niet tijdens een sprint aan dezelfde functionaliteit werken of afhankelijk zijn van elkaars sprintresultaat, maar plan dit over verschillende sprints. Hierdoor voorkom je dat, wanneer de functionaliteit onverhoopt uit de sprint valt bij team 1, de overige teams stil komen te vallen en geen werkende functionaliteit op kunnen leveren aan het einde van de sprint.
- In Scrum is er een hoge mate van autonomie van de teamleden in de keuze voor de manier waarop het resultaat bereikt wordt. Bij een multi-scrum-team-project is het voor een goede afstemming tussen de teams wel van belang dat een aantal standaarden afgesproken worden met betrekking tot documentatie en codeerstandaarden.
Conclusie
Scrum is dus ook werkbaar in grotere projecten, met meerdere teams, parallel. De product owner krijgt het wel druk: Meerdere teams en daarom meerdere sprint reviews, retrospectives en een hogere doorloopsnelheid van userstories en dus afstemming met de business. De teams dienen daarbij onafhankelijk te kunnen werken; maar wel met de neuzen in dezelfde richting.
Rein Hochstenbach, testconsultant bij Bartosz
Ik denk dat niet de kapitein, maar de architect(uur) de koers bepaalt van grote scrumprojecten.
Met name het 6e punt (onderlinge afhankelijkheid) wordt gedreven vanuit architectuurtechnische keuzes, niet vanuit de gekozen ontwikkelmethodiek.
Je kunt wel onafhankelijke teams maken, maar als de onderlinge verwevenheid op architectuurniveau te groot en te complex is, kunnen ze niet onafhankelijk van elkaar opereren.
@PaVaKe Eens, daar zat ik ook al aan te denken, er kan alleen sprake van onafhankelijkheid zijn als er ook echt technische onafhankelijkheid is. Moet ook denken aan dat je leest dat bij uitbestedingen van ICT projecten van de overheid dat men verplicht is om het in kavels te verdelen, dus delen naar een andere aanbieder. Dat is ook alleen maar zinvol als het echt technische onafhankelijke onderdelen zijn. Anders is het een garantie voor gesteggel. Ongetwijfeld zal de kapitein daar rekening mee houden.
Wat hier beschreven wordt lijkt wel heel veel op het scaled agile framework (zie http://www.scaledagileframework.com/).
Dit is een opschaling van de agile methode om met meerdere teams te werken. Een groot voordeel vind ik dat vanuit de business/architectuur wordt gewerkt met epics en features waardoor het overzicht geborgt wordt, maar dat de teams en P.O.’s de uiteindelijke stories bepalen en implementeren. Het geeft goed en duidelijk overzicht op business niveau, terwijl de teams zelf invloed hebben op het hoe (de opslitsing in stories). Daarnaast geven de epics en featuers de ontwikkelteams veel inzicht in het waarom en de te behalen doelen.
Er zal nog steeds een ‘kapitein’ nodig zijn, maar dit kan dan gewoon de product manager zijn die prioriteitsbeslissingen neemt. De business analisten en architecten geven de features vorm, de teams de uiteindelijk te realiseren stories.
Het idee achter agile (en vooral niet zo agile) gaat er vanuit dat elke deelnemer aan het team over ongeveer het zelfde kennis niveau beschikt.
Zodra er in een team een significant veelheid aan vaardigheden die niet zomaar op afroep beschikbaar zijn gevraagd wordt blijkt ineens dat het hele concept niet meer zo geweldig werkt.
Ook merk ik dat het inovatie gebasseerd op eigen initiatieven volkomen in de kiem smoort.
@Rein
Binnen een organisatie is een projectmanager hoogstens de stuurman, de kapitein is namelijk dus iemand of iets in C-level management. Ik zeg iets omdat verantwoordelijkheid steeds vaker uitbesteed lijkt te zijn als ik kijk naar stroperige besluitvorming aangaande de bijsturing van projecten. En de methodiek van agile gaat hier dus NIETS aan veranderen als ik overweeg dat het toch vooral een methodiek van een zandbak vol kleuters is, lees wat dat betreft even rustig herziene declaratie aangaande manifesto door want de wereld is veranderd:
“Where original manifesto focused on software development, a term which too many people have understood to mean only software development, we suggest that it should focus on solution delivery. Where the original focused on customers, a word that for too many people appears to imply only the end users, we suggest that it focus on the full range of stakeholders instead. Where the original manifesto focused on development teams, we suggest that the overall IT ecosystem and its improvement be taken into consideration. Where the original manifesto focused on the understanding of, and observations about, software development at the time there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written). We believe that the Agile Manifesto can benefit from lean principles.”
Scrum werkt trouwens ook alleen maar in een opzet waar afhankelijkheden beperkt zijn, lees wat dat betreft alle wetenschappelijke verhandelingen terug aangaande het idee van de ‘kanban’ binnen complexe logistieke processen. Hele opsomming is dan ook als de uitleg van de kapitein op de Costa Concordia, grote onzin als we ervan uitgaan dat oplossingen niet ‘stand-alone’ geleverd worden binnen een ‘connected world’ waar zich dus meer onder dan boven de zeespiegel bevindt. Als ik me niet vergis is DevOps met het idee van Continuous Integration dan ook een poging om deze uitdaging op te lossen, iets wat redelijk goed werkt binnen een architectuur met allemaal silo’s maar wat dus al snel voor problemen zorgt als deze op één of andere manier afhankelijkheden hebben.
Daarmee kom ik op begrip architectuur, veelal niet meer dan een verzameling knikkers door alle ongedocumenteerde workarounds die gemaakt zijn om de levering van functionaliteit maar volgens schema te laten verlopen. De kapitein van het project blijkt net als Francesco Schettino vooral een spelenvarende kleuter te zijn en iets in C-level management vond het allemaal best want het zou zijn of haar tijd wel duren. Wat je beschrijft is namelijk een model dat gehanteerd werd binnen de financiële sector en wat dus voor een stroom aan producten zorgde die de markt vergiftigd hebben. Sorry Rein, maar tussen werkbaar en (onder)houdbaar zit nog een gapend gat als ik even kijk naar de problemen die ik tegenkom in de praktijk want alle neuzen dezelfde richting op krijgen vraagt geen kapitein maar een bootsman.
@Ewout ik ben blij als een kind (als een kleuter zo je wilt) te zien dat ik niet de enige ben die zijn twijfels heeft over allerlij hippe methodieken die er vooral opgericht zijn om mensen zonder kennis van zaken (op zowel productie als op management niveau) bezig te kunnen houden.
Precies de afhankelijkheden die jij aanhaalt leiden in dit concept bij mij tot behoorlijke ergernis.
Ik lees het epistel en vraag me af waarom ik een nieuw trucje zou moeten leren terwijl alle tools en elementen er al lang zijn en nog lang niet zijn uitgenut.
Het lastige bij iets als scrum blijft dat men weer wielen opnieuw probeert uit te vinden die er allang zijn. Waar ligt het lampje dan? Kun je je beter afvragen.
Dat lampje licht bij mij in het gegeven dat elke IT professional weet waar zijn positie is in het lineaire proces en oog heeft voor aangesloten discplines en aangesloten processen. U weet wel, gewoon, oog hebben om grey areas uit te sluiten en niet aan te nemen dat iets wel of niet zo is maar altijd even te verifiëren.
In grotere projecten en trajecten? Acteren teams, altijd binnen eigen discipline maar hebben standaard ook voor de opvolgende discipline. Dat zou, dat is het namelijk ooit wel eens een basiskennis geweest. Dat je namelijk weet dat als je iets ontwerpt, je betrokken blijft bij ontwikkeling. Dat ontwikkeling betrokken blijft bij testfase en dat testfase weet wat de klant verwacht en wil om op elk gewenst en zo snel mogelijk weer terug te kunnen naar de discipline die op dat moment in het traject is gewenst.
Laat je teams in grote trajecten lekker hun gang gaan? Dan krijg je situties zoals je momenteel bij overheden ziet.
Stuurlui
Vind het een onzinnige en onzalig begrip. Je hebt IT project managers die kennis hebben van de materie die die teams aansturen en een stapje hoger overleg hebben met elkaar. Daar heb je weer geen agile voor nodig. Wel kennis van zaken in IT en de betreffende discipline en communicatieve vaardigheden. Die ‘kapitein’ daarboven, is ook een IT manager die wat verder gegroeit is en op programma niveau kan acteren.
Naar beneden toe weet iedereen eenduidig wat er van diegen word verwacht. Laten we wel zijn, dat is veel meer dan alleen maar die discipline waar je je in bevind of waar je ziel en zaligheid ligt. Let wel, zeg het nog maar een keertje, die professional weet natuurlijk ook basaal iets van IT processen en security…. en zo…..
Heel sec, Ik heb nog steeds niemand gehoord of gezien die zei… “ITIL? Zou je dat nou eigenlijk wel doen jongen….?” Dus waarom iets nieuws telkens als het vorige helemaal niet eens is uitgenut?
Numo Quest vat goed samen waarom het gaat:
“kennis van zaken in IT, in de betreffende discipline en communicatieve vaardigheden”.
Ook ik geloof allang niet meer in de vele “moderne” methodieken die in de loop van de jaren afwisselend het modebeeld bepaald hebben (SDM1, SDM2, ITIL, Scrum/Agile – en wat ik nog vergeten ben).
Wanneer we er van uit gaan dat IT niet zo zeer om de techniek als wel om de mensen gaat, dan kunnen we konkluderen dat IT dichter bij een biologisch model ligt als bij een technisch model.
Kombineer dat met het model uit de systeemtheorie:
– veel entiteiten en weinig noviteiten
versus
-minder entiteiten en veel noviteiten met grotere komplexiteit
Dan verklaart dat waarom IT-projekten die klein beginnen met iets werkends en dan groeien, wel succes hebben.
Dat lukt alleen met een projektleider die:
“kennis van zaken in IT, in de betreffende discipline en communicatieve vaardigheden heeft”.
Welke hulpmiddelen die gebruikt is om het even.
ja numo, een nieuw truukje leren zit er bij jou zowiezo niet meer in. Maar ook bij de anderen weinig enthousiaste reacties. Toch doen we straks allemaal scrum voor de snelle lean agile time to market tbv bigdata oplossingen in de cloud whatever, zoals de de klant dat wenst. We moeten tenslotte toch vreten, nietwaar. Die waarheid hoeft Maslov niet uit te leggen.
@pavake
De architect wordt op afroep betrokken, dus alleen wanneer het nodig is om architectuur aan te passen of te definiëren en om bruggen te slaan tussen de verschillende teams.
De autonomie van het team en het doel van de scrum staat voorop en de product owner neemt de besluiten, maar kan ook de architect oproepen.