Nieuwe leden in een Scrum team binnen een traditionele organisatie

Hoewel onze teams door de afgelopen jaren heen redelijk stabiel zijn gebleven, staan we nu voor de uitdaging om één van de teamleden te vervangen door een nieuw teamlid. Wij werken als Scrum teams binnen een traditionele organisatie waar het “officiële” selectieproces nog van kracht is. Dit houdt in dat een vacature wordt opgesteld, sollicitanten worden gescreend, uitgenodigd voor een eerste en tweede gesprek en op basis van, voornamelijk, skills aangenomen.

Doordat wij binnen de Scrum teams, over het algemeen al jaren samen werken, hebben we elkaar goed leren kennen. We kennen elkaars sterke maar ook zwakke punten. Hierdoor zijn we in staat om elke sprint weer waarde toe te voegen aan onze opleveringen door elkaar te helpen om onze sprintdoelen af te ronden. We hebben met elkaar de taken en verantwoordelijkheden van de verschillende rollen binnen onze teams vastgesteld, we spreken ons uit richting elkaar, kritiek wordt niet gezien als persoonlijke aanval maar als constructief en taakgericht en we voelen ons als teams verantwoordelijk voor het halen van onze doelen. En hoewel in mijn opinie de fases niet zo rechtlijnig lopen als Tuckman beschrijft maar meer cyclisch, denk ik dat wij de meeste tijd in de Performing stadium doorbrengen.

Tuckman; vijf fasen van groepsontwikkeling

Doordat wij de rollen en verantwoordelijkheden, de manier waarop en hoe wij willen werken in onze teams uitgebreid hebben besproken en blijven bespreken, proberen we de kwaliteit in onze teams hoog te houden.

Als Scrum-teams willen wij echter ook een stem hebben in wie wordt toegevoegd aan ons team. Want voor ons is het niet alleen belangrijk dat iemand de juiste skills set meeneemt maar ook dat diegene als persoon binnen het team past. Wij hebben daar de volgende oplossing voor bedacht.

Het eerste gesprek vindt plaats met mij in mijn rol van Scrum Master, samen met één van de teamleden (meestal iemand die een soortgelijke rol vervult). Indien wij de sollicitant een goede fit vinden, vindt een tweede gesprek plaats met de manager van de afdeling met, meestal zijn leidinggevende of iemand van P&O (het “traditionele” gesprek). Na een positief advies, doen wij dan een introductieronde in het team waarbij het aspirant teamlid een opdracht krijgt om uit te werken. Hiervoor wordt hij (of zij) een paar uur uitgenodigd om deel te nemen aan het team. Op die manier zien wij enerzijds wat zijn expertise is maar zien wij ook hoe diegene deel neemt binnen het team. Wordt er interactie opgezocht, neemt diegene deel aan de discussies en hoe laat hij zich horen. Uiteindelijk geeft ieder teamlid zijn “oordeel” in een persoonlijke terugkoppeling door aan mij. Persoonlijk omdat dan de teamleden niet gehinderd worden door de mening van één van de andere teamleden. Op deze manier proberen wij het zelf-organiserend vermogen van ons team en het opnemen van nieuwe teamleden binnen een traditionele organisatie op een goede manier vorm te geven. En proberen we, ook na het wijzigen van het team, weer zo snel mogelijk in onze performing stadium terug te komen. Ik ben benieuwd hoe jullie dit doen.

intrinsic motivation Thomas de Graaf

Intrinsically motivating environments

Some time ago I said to someone that I want to create an environment in which people become intrinsically motivated. He replied to me “But intrinsically motivated people are already motivated themselves!”.

In the world of IT, with more ideas than successful implementations, we continue to seek for new buzzwords to help us out. Everything-as-a-service, full-stack t-shaped unicorns, high performing teams and intrinsically motivated people, who would dare to say ‘no’ to these? Although there is a truth in these buzzwords, misunderstanding them can have devastating results. Those buzzwords might distract us from what really makes the biggest impact on the productivity of teams, defining the environment in which people work.

We like to put people into ‘boxes’ to understand them better and within IT that would preferably be binary. Within complex environments such as human behaviour, that is however not applicable. Let me prove this to you. For those who see themselves as intrinsically motivated, who needs his salary to pay the monthly bills or maintain his/hers standard of living? Who is saving up for a nice new car, bathroom, kitchen or house? Or are you looking forward to buy that new gadget or piece of clothing from the next salary? For those who see themselves as extrinsically motivated, did you ever leave the office with the feeling that you accomplished something great that day even though your payment didn’t change because of it? Did you ever feel challenged on your work, because someone gave you a challenge and you resolved it? Did you ever feel appreciated at work because someone said thank you when you helped them out?

Hopefully I just proved there is a lot of grey area here and people are generally both intrinsically and extrinsically motivated. But that is not where it stops, it gets even better! Motivation is not static, we can influence it! Imagine you are a predominantly intrinsically motivated cartoon artist. You make awesome cartoons, appreciated by millions of viewers worldwide. One day a new chief editor is assigned who reviews your creations and every single time he says they are not good enough. Without elaborating why, he puts all of your work in the paper shredder right in front of you. Would you remain intrinsically motivated? What if he also decides to cut your salary or stop paying at all? And what if this cartoon artist would be a software developer instead, would this still apply?

Now the other way around, can we make a predominantly extrinsically motivated individual more intrinsically motivated? As a manager, try telling your team that you didn’t just hire them for their capabilities, but also want them to develop themselves in areas they are interested in, so they remain motivated and committed for a longer period of time. Give them the opportunity to explore new challenges, accept failure and let them learn by trying. Ask them if they are happy with their work and seek new opportunities together if the current work is not giving any satisfaction. In fact, anyone can help creating an intrinsically motivating environment. Try giving a colleague a compliment, let someone pick up a story for whom it is a challenge rather than a walk in the park. Give your colleague a compliment or thank them if they did something for you, it’s also the little things. Don’t forget to have some fun too, it might make you more intrinsically motivated as well.

Therefore, let’s stop talking about intrinsic motivated people and start talking about intrinsically motivating environments. Examples anyone?

Opsplitsen van een Scrum team

Andre Heijstek, directeur bij Valueminds:

De Scrum-guide geeft, mijns inziens terecht, aan dat een Scrum-team tussen de 3 en 9 man groot moet zijn.

Het team dat ik op dit moment begeleid groeide naar 11 man,dus het werd tijd om te splitsen. Dat deden we overigens niet omdat het moet van de Scrum-guide. Zo scrumdamentalistisch zit ons team niet in elkaar.Wel omdat we last kregen van de grootte:

  • allereerst heel praktisch, de ruimte waar we zaten als team werd gewoon te klein om er te kunnen zitten met 11 man;
  • we merkten ook dat meetings steeds langer werden doordat in een grote groep iedereen toch zijn zegje moet doen;
  • en als belangrijkste, het werd vaak onrustig. Te veel interactie tussen teamleden is niet goed. Iedereen luistert toch even met een half oor mee als twee mensen met elkaar in gesprek gaan, als er een gebruiker langs komt met vragen, een stakeholder met wensen, etc.

Na de splitsing merkte we een enorm verschil in de rust rondom het team. Zeker in het kleinere team (4 man) dat in een kleiner, separate kamer ging zitten.

We hebben goed nagedacht over hoe we het team zouden splitsen. We zagen 3 snijvlakken:

  1. development versus maintenance, met andere woorden, bouw van nieuwe features versus vernieuwbouw van bestaande features
  2. functioneel beheer versus development; het team had 5 ontwikkelaars, 2 testers, 2 functioneel beheerders, 1 scrum master/tester en een product owner. Een optie was om de functioneel beheerders en de PO in een ‘ready-team’ te zetten, naast het development team
  3. een splitsing langs technische of functionele onderdelen van ons systeem

Optie 1 was aantrekkelijk en aanvankelijk de voorkeur vanuit de stuurgroep. Het team wordt behoorlijk geremd in de gewenste velocity voornieuwbouw doordat er continu bugs en kleine praktische verbeterwensen uit de organisatie komen. Nieuwbouw krijgt daardoor niet de rust die nodig is om snelheid te maken.

Het nadeel van optie 1 is echter dat het een perverse mentaliteit oproept. Het nieuwbouw-team mag rommel afleveren omdat het maintenance-team het later wel zal oplossen. Natuurlijk zal niemand dat bewust zo aanpakken. Maar onbewust kan dit gevoel wel ontstaan. Een aanpak waarbij ‘de vervuiler betaalt’, degene die de bugs maakt ze ook moet oplossen leek ons beter.

Optie 2 had ook een paar voordelen. Het is (nog steeds) hard nodig in dit team dat er meer structuur komt in de backlog. We zitten nog in een fase die door Henrik Kniberg ‘spoon-feeding the team’ genoemd wordt, de PO kijkt maar 1 sprint vooruit. Aan de andere kant: de functioneel beheerders hebben veel domein-kennis die bij de developers veel beperkter is. Veel interactie tussen functioneel beheer en development om slimme, werkbare oplossingen te bouwen is noodzakelijk.

We hebben daarom gekozen voor optie 3. Het ene team pakt alle financiële onderdelen op van het systeem en imports van data van nieuwe klanten. Het andere team richt zich meer op documenten en workflows binnen het systeem. Ieder team heeft 1 functioneel beheerder die de PO ondersteunt in het refinen van de user stories.

Deze indeling is in feite een vertical slice. Vergelijkbaar met de manier waarop user stories geplitst moeten worden.

Volgorde van de backlog

André Heijstek, directeur van Valueminds:

‘De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder. De regel die het meest wordt gebruikt is dat de items op volgorde van waarde staan. Naar mijn mening is dat echter te beperkt. In mijn ideale situatie bepaalt een mix van de volgende factoren de volgorde van de backlog:

  • Technische afhankelijkheden. Er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
  • Waarde. Spannende stories waar mogelijk ellende in zit moet relatief hoog op de lijst staan: fail fast is beter dan fail late.
  • Risico. De waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de Product Owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig).

Naast deze drie aspecten, komt er in de keuzes voor de komende sprint nog en aspect bij: wanneer de items waaraan in een sprint wordt gewerkt aan elkaar gerelateerd zijn, werkt dit veel prettiger. Dan krijg je zoiets als: ‘In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken.’ Wil je dat het team meer focus krijgt en meer gaat samenwerken tijdens sprint? Stel dan een sprint goal!’

Story points aanpassen voor een nieuwe developer?

André Heijstek, directeur van Valueminds:

‘Op dit moment coach ik een team dat sinds drie sprints aan het schatten is in story points. Op basis van de afgeronde stories hebben we van de laatste sprints een story point liniaal gemaakt, zodat we een goede referentie hebben. We houden nieuwe stories tegen deze liniaal aan: Lijkt het op de andere drietjes? Dan is het ook een drie.

Een tijdje geleden kregen we er een nieuw teamlid bij. Dit was een ervaren ontwikkelaar, maar nieuw in ons team en dus niet bekend met ons business domein en met de opzet van onze code. Het is logisch dat hij er voorlopig wat langer over doet dan anderen om een story af te ronden. Maar hoe gaan we hiermee om met de schattingen? Moet je de stories die hij gaat doen meer punten geven?

NEE! Dat gaan we zeker niet doen. Dat helpt het hele mechanisme om zeep.

Daarnaast kan het ook helemaal niet, we weten namelijk vooraf niet precies wie aan welke story gaat werken. We werken met zoveel mensen als zinvol mogelijk is aan de eerste story en starten dan pas met story 2. Wie wat gaat doen wordt daardoor pas heel kort van te voren duidelijk.

Ook zo zo’n aanpassing aan een nieuwe programmeur het hele idee van story points om zeep helpen. De story points geven aan hoe groot een story is voor het hele team. Het schatten van stories blijft hetzelfde: met de story point liniaal. Als deze story lijkt op de drieën van onze liniaal dan krijgt hij drie punten.

Op het moment dat er een nieuw teamlid bij komt verandert het team, en daarmee ook de velocity. Een nieuw teamlid haalt in de meeste gevallen eerst de velocity omlaag. Hij levert zelf nog niet veel output op en met al z’n vragen houdt hij ook nog eens de ervaren teamleden van het werk. Hopelijk stijgt de velocity later wel, als hij meer zelfstandig z’n taken gaat oppakken. Hiermee is de velocity een eerlijk maat van de output van het team.’