Scrum in een niet-IT-team team (Valueminds met backlog in Trello)

Werken met Scrum in een niet-IT-team, kan dat ?

Werken met Scrum in een niet-IT-team, zonder samen te komen op een fysieke locatie. Kan dat ? Uit eigen ervaring kunnen we stellen: Jazeker!

In deze en komende blogposts nemen we jullie mee in onze eigen ervaring in het werken vanuit Scrum in een niet-IT-team. Het eerste deel gaat over de aanleiding, opzet en eerste resultaten van onze Sprint.

Hoe zijn we hier gekomen ?

Sinds het uitbreken van de Corona-epidemie eind maart, is helaas van enkele Valueminds-collega’s het inhuurcontract vanuit de opdrachtgever stopgezet. Jammer, maar wel begrijpelijk. Op dit moment lijken veel organisaties te kiezen voor stabiliteit, beperkt investeren en vooral ‘roeien met de riemen die je hebt’. Ook al denken wij dat juist in deze tijd je moet blijven investeren, hoe moeilijk het ook is. Deze tijd vraagt nog sterker om het flexibel kunnen omgaan met veel en krachtige veranderingen, om nieuwe ideeen, anders en vooral ‘beter’ met elkaar samenwerken.

Nu zou je kunnen denken, prima toch ? Zijn we een soort van ‘vrij’ en in de tussentijd zoeken we naar nieuwe opdrachten. Echter, zo zitten we bij Valueminds niet in elkaar. De gedachte om de tijd die we nu beschikbaar hebben zinvol in te zetten, was bij alle collega’s vanzelfsprekend. Want of je nu leert, constant verbeterd en zinvolle resultaten boekt met je collega’s of met een Scrum-team bij een opdrachtgever, het doel blijft hetzelfde!

Leren en resultaten boeken met je collega’s is net zo leuk als met een Scrum-team bij een klant!

Over doel gesproken: als team helpt het als je een duidelijke richting hebt. Oftewel: waarom werk je met elkaar samen ? In ons geval hebben we gelukkig een gezamelijk belang, namelijk: “Hoe kom ik en mijn collega’s op een ‘duurzame’ manier aan een mooie nieuwe opdracht?” (over ‘duurzaam’ in latere blogposts meer). Dit is dan ook ons ultieme einddoel geworden.

Vanuit die gedachte zijn we vrij snel gestart met de eerste Sprint van ons eigen team, genaamd ‘de Bankheersers’. De keuze om met Scrum aan de gang te gaan, leek eigenlijk vanzelfsprekend. Vanuit huis, garage of balkon, met onze Agile values en Scrum-ervaring, begon Sprint 1.

Doel van Sprint  #1

Over het algemeen wordt Scrum ingezet bij software development teams. Hierbij leidt de iteratieve, multi-disciplinaire aanpak meestal (gelukkig!) tot een bruikbaar nieuw of aangepast onderdeel (increment) van een digitaal product. Echter, in ons geval zijn we geen software development team en waren we vooralsnog ook niet van plan te gaan  ontwikkelen in C# of Ruby.

Wat we wel wisten is dat we, bij voorkeur binnen enkele maanden, alle collega’s weer aan het werk wilden hebben. Hoe we dit doel gingen bereiken, waarmee en met wie was nog niet duidelijk. Er zijn tenslotte vele mogelijkheden: contacten uit ons netwerk benutten, nieuwe producten of diensten ontwikkelen, specifieke markten onderzoeken, jobportals afstruinen, je kan zelfs als frontend developer of hovenier aan de slag gaan…

Kortom, net als bij een team dat software ontwikkeld, hadden we complexiteit, onzekerheid en veel verandering om ons heen.

Bij een niet-IT-team is het product vaak minder ‘tastbaar’

Een van de mogelijkheden om het einddoel te bereiken is het organiseren van Agile meetups. Nu organiseerden we dergelijke meetups zoals Agile Meetup Breda en Agile Meetup Rotterdam al langer, alleen niet in ‘Corona-tijd’ waarbij fysiek bijeenkomen niet mogelijk is. Het organiseren van een online versie van de meetup versie leek ons een mooi experiment.

Samen met onze Product Owner Andre (zie onder) kwamen we met het onderstaande sprint doel:

Als Valueminds directeur
Wil ik de Agile Meetup Breda online organiseren 
Zodat we
- zichtbaar blijven bij onze community
- ervaring op doen met online workshops trainingen, zodat we dat mogelijk kunnen uitbouwen tot training componenten

De Scrum Masters en Agile Coaches in (en onder) ons zullen nu misschien denken: dat is toch geen sprint doel ?!? Wat is ‘zichtbaar blijven’ en hoe meet je ‘ervaring op doen’ ? Zeker, dit sprint doel kan scherper en korter. Maar, belangrijker is: het is gezamenlijk opgesteld, geeft focus en zorgt voor feedback. En, last but not least, de Scrum Guide zegt het volgende:

“The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint”

Het geeft het team de flexibilteit om Sprint Backlog-items toe te voegen of te verwijderen om het Sprint-doel te kunnen behalen.En dat is precies wat we nodig hebben!

Rollen

Product Owner – André Heijstek

Onze keuze voor Product Owner was vanzelfsprekend – André is onze manager en directeur van Valueminds. Hij heeft heel veel ervaring in onze ‘markt’ en is eerste contactpersoon voor onze cliënten. We vertrouwen hem allemaal met beslissingen over de volgorde van de product backlog. Normaalgesproken zouden we niet hebben gekozen voor iemand met lijn verantwoordelijkheden, maar omdat we allemaal midlance werken was er weinig conflict te verwachten. Wat ook helpt is dat hij letterlijk de ondernemer van het product. En toch heel goed weet wanneer een beslissing nodig is of wanneer er overlegd moet worden met het team: hij is comfortabel met wanneer hij iets weet en wanneer hij het moet vragen.

Scrum Master – Rutger van Dijk

Aangezien we allemaal bekwaam en ervaren zijn met Scrum, was de keuze voor Scrum Master een luxeprobleem: iedereen kan het, wie wil het doen? We zijn blij dat Rutger de rol op zich nam en de ‘dienende leider’ van ons team wil zijn. Hij zorgt dat we niet vergeten ‘inspect – adapt’ toe te passen en creëert de ruimte voor de rest om te werken. In zo’n ervaren team is het moeilijker dan je zou denken – we hebben nogal de neiging om gezellig in gesprek te gaan en alle time-boxes en events te vergeten. Dan is het fijn dat iemand zich opoffert om zijn oog op de klok te houden en om ons te herinneren aan de verplichtingen die we met elkaar aan zijn gegaan.

Development Team – Dennis Mansell, Reinoud van Oirschot, Michelle Kuiper

Met de overige drie collega’s zijn we hard bezig geweest om de Sprint doelen te halen. Maar Rutger en André (deels) werken ook mee in het Development Team. We hadden nog nooit samengewerkt als team en we kende elkaar alleen van een paar maandelijkse ‘gilde’ meetups. Toch was er weinig nodig om te ontdekken wie er wat doet en wanneer mensen beschikbaar zijn. Zo is het voor Michelle goed om ‘s middags even te sporten, Dennis werkt het liefst na half elf ‘s ochtends om eerst de kinderen te hebben gedaan en heeft Reinoud ook verplichtingen als vader en als persoonlijke coach. Door daar transparant over te zijn, was het relatief makkelijk om af te spreken wanneer we samenwerken en kregen we ook veel gedaan. We hoefde ook geen ‘corvee schema’ of ‘werkafspraken’ te maken. Wel waren we wat laks in het maken van een Definition of Done – die is er pas sinds deze sprint – maar door te vertrouwen in elkaars goede intenties leidde dat niet to onnodige conflicten.

Scrum Artefacts

We houden een Product Backlog bij in Trello. De backlog is langzaam gegroeid – we hebben nu 67 items in backlog. Met onze velocity van ongeveer 32 items per sprint, is dat twee sprints aan werk als we niets nieuws bedenken (en dat doen we juist altijd).

We onderscheiden vier soorten werk:

Commercie – dingen die direct iemand aan het werk zetten, bijvoorbeeld een CV plaatsen bij een opdracht, social media reacties en reclame maken. In een IT team zou dit het doorlopende ‘Ops’ werk zijn.

Product Development – dingen die niet direct omzet zullen opleveren maar verbeteringen zijn in een product die we later denken nodig te hebben. In een IT team zou dit het ‘boyscouting’ of ‘refactoring’ werk zijn.

Projecten – dingen die optellen tot een stuk waarde. Zo hebben wij:

  • Scrum Studio – een nieuwe organisatievorm – Scrum Team As A Service. Telkens hebben we gewerkt naar een ‘potentieel leverbaar’ product. We doen bijvoorbeeld een design studio workshop voor VOKK en User Story Mapping voor een startup.

  • Agileminds Meetups – waaronder de Agile Meetup Rotterdam en Breda. Daar hebben we tot nu toe een gratis facilitatiegids en templates gemaakt voor User Story Mapping

  • Voorbereiding van agile transities.

Continuous Improvement – bij elke retrospective identiceren we één of een paar verbeteringen aan onszelf, ons proces, die we backloggen.

Onze Sprint Backlog is een tweede kolom in Trello. We houden ons aan Sprint doelen – een concrete statement over wat we willen bereiken in de twee weken. Er worden   geen user stories gebruikt, geen story points en er wordt regelmatig werk verschoven uit de Sprint Backlog. Op onze backlog zijn er twee kolommen voor Work In Progress: Doing en On Hold.

Increment: we zorgen dat er minimaal eens per sprint iets opgeleverd wordt waar iemand iets aan heeft. We hebben bijvoorbeeld twee iteraties gedaan van online user story mapping – een voor Agile Meetup Breda en een voor Agile Meetup Rotterdam. Onze Definition of Done houdt in dat we deze sessies doen maar ook delen, documenteren en evalueren. ‘Done’ items krijgen een eigen kolom in Trello, per Sprint.

Scrum Events

We hebben elke dag om 10:30 onze Daily Scrum, dat kwam het beste uit – je hoeft dus niet altijd de Daily Scrum aan het begin van de dag te hebben. Omdat we online werken hebben we onszelf toegelaten dat het een halfuur duurt. Het eerste deel is een check-in, in het tweede deel kijken we naar onze voortgang naar het Sprint doel.

Elke Sprint begint met Sprint Planning en eindigt met een Sprint Review. Dit is nog de lastigste om te plannen:  onze sprints duren twee weken, van donderdag tot woensdag. Helaas lukt het niet altijd om al onze stakeholders precies op woensdagmiddag om feedback te vragen. Soms bewegen we mee met andermans agenda.

Verrassend genoeg hebben we nog de meeste moeite met de Retrospective. Gezien de grote hoeveelheid Scrum Master vlieguren in ons team, zou je verwachten dat we dit event nooit zouden laten gaan maar toch zitten we in onze zesde sprint en hebben we maar vier Retrospectives gehad. Mischien een goed punt voor onze volgende Retrospective…

Scrum and Yacht Racing – Roles

This is a cross-post from my own blog, I hope you find value in it!

Watching the development of yacht sailing teams during a campaign, I have always been struck by the similarities between an effective team on a boat and an effective Scrum team.

If we take an X-35 team, it has 7 to 9 members.  Each member of the team has a very specific set of skills and a role. A team has a build-up to a race or a series of races in a campaign.  Usually there is a main goal – a certain race that stands out like a world cup – combined with a series of smaller events.

Roles

To get an idea of a typical modern sailing team, it is handy to understand what everyone does.  Beginning at the back of the boat:

The Tactician can be equated to Product Owner.  He or she does not actually do any of the physical work but rather decides where the boat should go.  A good tactician knows when to consult with his team and when to make a decision.  Depending on what the tactician decides, the necessary manoeuvres become evident.  The tactician is responsible for where the boat goes, but not how it gets there.

Next up is the Helmsman, or ‘Driver’.  In waterfall methods, just as in old-fashioned skipper-led sailing, this would be the project leader.  However, in modern sailing, the helmsman is simply a part of the crew.  Like a designer, he has a lot of influence on the progress of the team, but he is still a developer and part of the development team.

Then come the trimmers, they set the sails up to give maximum power.  Especially when heading upwind, they will often be doing their own thing without involving the rest of the team too much.  They are responsible for keeping the boat power optimal – in a car they would be the engine.

In the front of the boat there are the bowman or the bow crew.  They have very specific tasks, that affect the handling of the boat: hoisting and dropping sails, tripping shackles, holding and moving gear.  They have to work independently yet also together with the rest of the team – in a car they would be the gearbox.  In a Scrum team you could compare the trimmers and bow crew to front- and back-end developers.

One team member or otherwise an outsider often takes the role of the trainer – that is what a Scrum Master is supposed to be after all.  In fact, I like the fact that not all sailing teams feel the need to appoint a trainer – a really experienced Scrum team should be able to keep to the principles of Scrum without the need for a Scrum Master in the same way.

Self Organising Teams

When I join a boat for the first time as a trainer and I detect that the owner, driver or tactician have an hierarchical view of the roles on board, I often tell them about my experiences as a bowman.  As a student, I started yacht racing aboard a boat where the owner was the helmsman (the driver) as well as being the tactician and the brains, if not the hands, of all the trimmers and bow crew.  A standard race would consist of this gentleman shouting a series of commands at his crew, whilst he steered the boat and decided where to go.  This meant he was effectively deciding everything on board: steering, sail trim, boat handling, tactics and strategy – it was all up to him.  In times of stress, he would sometimes leave the helm to do someone else’s task if their performance was not to his liking.

When I first started to sail on board of the boat, the results were actually pretty good – the boat achieved good results in the local competition and did fairly well in national events too.  However, after a couple of years, I decided it was time to leave.  The team kept changing, people would leave, usually after having been shouted at for not following instructions correctly.  In the incident that had triggered my leaving, we had run aground because the spinnaker had not come down on time.  According to the skipper this was because of my actions as a bowman, according to me it was because he had been shouting at me so much, he had simply forgotten to steer the boat.  Whatever the reason in this case, our competition was clearly getting better – we were winning less and less races.

At this time, in the mid 90’s, the idea of a self-organising team was becoming a more popular style of leadership on many yachts.  The idea being that if each team-member knew his own role and it was up to him to act, the amount of knowledge being used was greater than if it all had to trickle down from the back of the boat.  Modern boats were also harder to drive, meaning that a helmsman would sacrifice the quality of their own work if they started involving themselves with what someone else was doing.  The trimmers and bow crew communicated with each other instead of via the skipper, losing less time and information in communication.

This method developed – in the team I had joined, we determined who would initiate action for all of the standard manoeuvres that the boat would do.  The team that I sail with nowadays has handling-sheets for 16 standard situations, only four of which are initiated by the driver.  This is not to say that there is no hierarchy on board – if a snap decision has to be made, the tactician makes the call, but in all other circumstances each position decides on their own actions.

These new methods resulted in the old-fashioned way of doing things, let’s call it the skipper-driven (waterfall?) method, being less effective than the new, self-organising method.  And that’s the nice thing about formal competition – it doesn’t get much more empirical than the results in a race.

10 Microsoft Teams Tips for working from home

Microsoft Teams comes with most Office 365 accounts, but it is also available for free with limited features. Due to the outbreak of the Covid-19 Microsoft decided to expand the free features. Teams has the potential to replace Outlook for all internal communication in your organization. The basic features are explained well in the videos of Microsoft.

In addition, I’ve collected 10 tips and tricks primarily for Scrum software development teams. Other teams might benefit from this too.

1. Extra chat options

In both chat and channels, this button gives you the option to add code snippets and hyperlinks. You can also mark the message as important to let it stand out from other messages.

2. Channel your information

Especially when working from home, there will be a lot of textual communication. If you use 1 chatgroup or channel, it basically becomes impossible to find back previous messages. Everybody will also be notified of all new messages, no matter if they are relevant. Compare it with replying to all in an e-mail and changing the topic. Isn’t that confusing? Create different channels for different topics and let people set their notifications according to their needs.

3. Connect with your build server

Just like Slack, Teams has the option to connect with your buildserver and post messages of builds, releases and pull requests directly in a channel. The advantage is that you can easily have a conversation about a release, build or pull request without opening a separate window. Combine this with the previous tip to create a channel for pull requests and a channel for your test automation run for example.

4. Channel vs chat group

In a channel every post is basically a topic that people can reply to under the topic, similar to how a forum works. In a chatgroup, although you can quote someone, the messages are always sequential. If two topics are discussed simultaneously, a channel will have a better overview of those 2 discussions than a chatgroup, if used correctly. Take this into consideration when structuring your communication.

5. Initialising a call and adding people

A (video)call can be initialized from a chatgroup or a meeting invite. Every meeting invite is by default a call which you can join. Typically meeting invites are used for regular meetings and (video)calls in a chat group to discuss ad hoc topics. In any call, people can be added manually. Both people who are already invited, so they get a pop-up or people who were not invited yet. This can both be done in the ‘show participants’ screen.

6. Poker during refinements

During a (video)call, people can share their screen to show JIRA for example. In addition, each call has their own chat integrated, which could be useful to poker during refinements. I would also recommend separating the votes per story with any comment (e.g. a dotted line), to avoid confusion which values are given for a story.

7. Online whiteboard

Besides sharing a screen, you can also set up a online whiteboard where all participants can draw on at the same time. This is an option in the share screen window. Multiple colors are available, and I would recommend assigning people to colors to see who draws what. In addition, an iPad (with MS teams app) or device with a touchscreen (e.g. Microsoft Surface Pro) combined with a pencil will improve this feature. Alternatively a Wacom drawing tablet could also improve your drawing skills over a mouse.

8. Add tabs for additional tools

In addition to Posts and Files (Sharpoint) can add ‘tabs’ to any channel or chatgroup. This can be a OneNote document, Wiki, a Trello board and many other free and paid options like brainstorm tools. People can work in these documents simultaneously. For example, a OneNote can be very useful to store meeting notes.

9. Digital sticky notes for a retrospective

During any call, you can go back to teams and your call will remain active and viewed in the top left corner of the screen. For example, you can go to your shared OneNote document or Trello board.  This can be used as alternative for anything you would normally do with sticky notes in a retrospective for example. In Trello you can add tasks and assign them to yourself to show that this is your ‘sticky note’. If you create a board with Start/Stop/Continue columns, you can still have a very basic online retrospective. There are probably paid options with better visuals and more features, like Miro for example, but with free options and some creativity you can do a lot.

10. Record a meeting

Any call can be recorded to view later for those who missed it. This is a built-in option when the call is active. This could be particularly useful for a sprint review. Although the feedback might come later, the demonstration can be shared with a wider audience more easily. If many people would like to join your review though, Teams has a Live events option that supports up to 10.000 viewers.

BONUS tip

For people who like dark mode, there is a setting for this in both the browser and desktop app. Click your icon in the top right and go to settings. Here you can change the color palet.

 

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.’