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 for Startups – Scaling Scrum? or just a lot of Scrum?

This is a re-post of a post from July 2015, which may be a while ago but may still have some relevance today.

Yesterday I attended Scrum Day Europe, which had the theme ‘Scaling Scrum’.  Perhaps predictably, the only one to consider the case: ‘natural growth’ was Gunther Verheyen.  Everyone who spoke after him was actually talking about how to impose/implement Scrum when you already have lots of people.

Startups have the luxury that they can think about scaling before having to do it and can make/choose a framework that they can settle- as opposed to get-crammed-into.

This topic has interested me since, as a budding Scrum Master, I heard about the Scrum implementation at a Dutch bank, ING, where they had just implemented Scrum in 135 teams.  It all sounded very exciting, a massive giant of an organisation that had decided to ‘become Agile’.   Later, when formalising my Scrum knowledge on a Scrum Master course, I met more ING folk, but this time they seemed a lot less enthusiastic.  Not because of Scrum, but because the organisation around them had decided to adopt ‘Architects’ and ‘Q&A teams’ – not particularly Agile practices.  The management layers were not adapting to the new situation and I understand that this is still a problem.

How, at a startup, should you start scaling and how much, if anything, can you learn from ‘old’ organisation?

Naive Agility vs Imposed Rigidity

You would think that a startup is lean and mean, that agility is inherent in an organisation that has not had time to go rusty.  I can tell you that that is far from the truth.  Especially when you have to deal with banks or external financiers, things quickly get far from Agile.  But I have also come across founders wanting to think up everything in advance for superficially good reasons like hardening their vision or to get developers to stick to the plan or delivering what they promise.  Until ‘lean startup‘ the advice was always ‘first, write a business plan’.

These practices mean that even a startup has some bad habits by the time they are together enough to consider growing.  Even completely newly-founded startups with a large budget often inherit baggage from managers that get in the way with growth.  I interviewed for a job last winter at a startup that was being created to house the marketing department of a large retailer.  They were three months old but they already had decision-making lag because their board of directors wanted to command-and-control all of the processes.  They seemed to be breaking records for turning something new, fresh and agile into an oil tanker.

So, is it hopeless? Are we just as handicapped in startups as if we were an enterprise scale organisation?  Luckily there is an important difference in where a startup is, compared to the legacy problems in most enterprises – our product is still young.  That really is the key – if your product backlog can be built up without too much dependencies, your teams can operate independently, thereby not requiring too much organisational overhead.  Many of those familiar with XP will know the mnemonic ‘INVEST‘ for defining good user stories – the ‘Independence’ of items in your product backlog dictates how self-organising your teams can be.

“One comes to the conclusion that this idea of scaling scrum teams to a larger endeavour is dependent on your ability to reduce the dependencies between the teams.”  – Ken Schwaber April 3rd 2015

There are currently five scaling methods/frameworks that I know of (the first three are summarised here).  They are listed in order of my perception of their Agility, most rigid first.

The 2nd of July saw Scrum Day Europe in Amsterdam. A disclaimer: this day was organised by Prowareness, a consultancy that earns its money by training and certifying Scrum professionals. They are heavily invested in enterprise scaling of Agile as their customers are exclusively large. That said, I did learn some new things about scaling Scrum but the attention was heavily skewed to large enterprises.

Usually, scaling Scrum means – we go to an already large company and we implement Scrum.  Because the company is already large and has many employees that it cannot fire and already has products that it knows and runs, the need is for a matrix that fits the existing structure.  The main complaint seems to stem from a lack of commitment to Scrum – in the business as opposed to the developers.  The business already has a set of behaviours and expectations and wants to better the process of development without having to change these practices.

Real Scrum is impossible to scale.

Much like a city is not a scaled-up village, an enterprise IT department is not a scaled-up scrum team. Scalability of human relationships is severely limited by the number of interactions someone can have and the number of people one can know well.  In a practiced Scrum team, people know each other well and the members of the team can easily interact with each other without it having a serious impact on their productive time.  In Scrum we don’t want more than nine people in a team and prefer about five team members for this very reason.

Which is probably the reason that Nexus – in my opinion the most ‘vanilla’ of the Scrum scaling techniques – scales to a max of 9 teams.  It is a Scrum team for Scrum teams.  It does carry some overhead – a Nexus team has to continually monitor and regulate integration of the teams’ outputs.  It is probably what I will be choosing if we need to integrate.

Hopefully that will never be necessary.  If your product backlog items carry almost no dependencies, there is no real reason for ‘scaling’ at all.  In most cases it may be better to solve your problem by keeping your product small, clean and modular.

Lessons from Open Source

Open Source projects like Linux have managed to swim against the tide in terms of being Agile and still scaling.  The thing that these projects have gotten right is that lack of management has meant that they have been forced to self-organize.  And to be honest, it is a Darwinian process – there are scores of abandoned projects for every Ubuntu, Apache and Firefox.

There are of course a few other things that Open Source projects have gotten wrong.  The major one is earning model – it is still very hard for a large number of people to earn their living in Open Source. Agile solves this problem by either employing the entire team or with very Agile contracts and compromising a little on the self-management of teams (for example, at a Swiss Post Scrum implementation they had Agile contracts but teams could not ‘pull’ work items off the backlog – instead getting delegated items from the Product Owners).

Then there is specialisation – something that Scrum also has trouble with.  What to do with people who are specialised in other fields that do not contribute continually to the product like marketeers or UX designers? Open Source has no use for them, in Scrum we have to spoon them in somehow.  We prefer it when people are good at other things too, so they can contribute evenly to a product.  But that can lead to high-quality software that is horrendously ugly to look at.

But if there is just one thing that growing startups can learn from Open Source, it is to have small, modular products that have little to no interdependencies.  That way teams can develop the product independently from each other so that no central organisation is necessary.  And when integration is needed – make an open standard for sharing between the products.  If a standard does not quite fit – one team can fork a product to suit their needs, whilst the original builder can merge this later on.

If you can avoid it: don’t scale, just grow.

Motivation Dennis Mansell

Can you handle an Agile view of Human Nature? – Motivation

Implicit in Agile methods, is a certain image of human nature.  This view of human nature is prescriptive, you have to ‘buy in’ to this view or else somewhere along the line you will end up in conflict with yourself or with the particular agile method you are attempting.  This is a real problem if you have entrenched beliefs about how people are motivated and work, less so if you are still flexible enough to let yourself be surprised.
These are the assumptions:

  • People are intrinsically motivated,
  • can and want to decide for themselves,
  • wish to work in interaction with others,
  • want to make things that work,
  • need a ‘sustainable’ workpace and
  • can be critical of themselves.

Intrinsic vs Extrinsic motivation

In Agile implementations, this is the most troublesome of the assumptions to face head on.  Most managers see their underlings as parts of a powered machine like a bike or a car. The machine needs continuous effort to keep it going, it will not work by itself, at least not for very long.

Extrinsic
  • Money
  • Good Grade
  • Avoiding Punishment
  • Higher Status
  • Social Ridicule
Intrinsic
  • Enjoyment
  • Challenge
  • Excitement
  • Self-Image
  • Wanting to
This is often coupled with a self serving bias.
Most managers got promoted into their positions and a pleasant explanation of their status is that it was due to their own hard work, insight etc. that they now manage people who are ‘just’ developers. That their underlings were not promoted must therefore be due to something and a lack of internal drive is a convenient explanation.

But – saying that all people are completely autonomous self-starters would also be naïve. Just because ‘Agile’ wants us to treat our teams as intrinsically motivated does not mean it is true. However, the catch 22 is that the only way to achieve self-motivation in your teams is to empower them. Believe me, I have seen this go spectacularly wrong, complete with crying children, burning equipment and rescue services (not at my office job thankfully). Nonetheless, the trick is to give away as much responsibility away as early as possible.

To get trustworthiness, you must also give trust. The expectation of self-motivation, when given to the right team in an atmosphere of mutual respect and trust, is in itself enough to foster self-motivation, sometimes even to the surprise of some of your team members! Conversely; using external motivation, having a lack of trust and respect or defective team members will all lead to dysfunction and the need for carrots and sticks. And it does happen, there are defective people with (thankfully rare) personality disorders that mean that they will never be self-motivated. But if you need to push and pull your team into action, make doubly sure that you are not causing the behaviour yourself.

User Story Mapping tijdens Agile Meetup Breda: de Retrospective

Op 22 april hebben we met Agile Meetup Breda een online workshop gehouden met als thema “User Story Mapping”.

Initieel was het de bedoeling om de meetup in levende lijve te doen op een mooie locatie in Breda. De coronacrisis gooide echter helaas roet in het eten. Omdat we toch aan de slag wilden met het onderwerp en we ook erg benieuwd waren of we dit op afstand konden doen hebben we de meetup alsnog door laten gaan maar dan online.

Een overzicht van onze aanpak en de stappen die we hebben doorlopen kun je hier vinden.

De meetup was van 15:00u tot 17:00u. Met van 14:30u tot 15:00u digitale inloop. We hadden 15 deelnemers. Als digitale hulpmiddelen hebben me Microsoft Teams en Mural gebruikt.

Dit was voor ons de eerste keer dat we het op deze manier hebben gefaciliteerd. Heel veel ging goed, maar er viel zeker nog genoeg te verbeteren voor een volgende keer. Onderstaand de belangrijkste punten uit onze retrospective:

Wat ging goed

  • Overall hebben we in een korte tijd de belangrijkste aspecten van de techniek kunnen behandelen. Voor een volgende keer gaan we nog goed kijken of bepaalde onderdelen meer of minder of op een andere manier aan de orde moeten komen. Hiervoor gaan we ook beter vooraf luisteren naar de behoeften van de groep.
  • We hadden een zeer enthousiaste groep deelnemers. Voor zover we dat goed meekregen had iedereen er lol in en was het voor iedereen een interessante ervaring.
  • Naast centrale onderdelen hadden we ook twee breakout momenten, waarin een facilitator met een groepje van 3 tot 5 mensen in een aparte teamroom werkte aan het invullen van een gedeelte van de User Story Map. Dat was erg geslaagd. De sfeer was goed. Omdat je met een klein groepje bent wordt het gelijk wat intiemer en persoonlijker.
  • Richting het einde vielen er een aantal kwartjes, met name voor wat betreft waar User Story Mapping past in een flow met andere technieken. Bijvoorbeeld dat je begint met een product vision, dan maak je een User Story Map en vervolgens komen de User Stories hiervan als items op een Sprint Backlog terecht, al dan niet via een Product Backlog. Hierdoor kwam er meer beeld bij de context van een User Story Map.

Wat kan beter

  • Microsoft teams werkt in de huidige vorm niet goed genoeg. Ondanks vooraf gestuurde uitnodigingen met toegang tot onze Teams omgeving duurde het zeker 20 minuten voordat we van start konden omdat mensen toch tegen toegangsproblemen aanliepen. We hadden verschillende rooms aangemaakt voor de break-out onderdelen. Ook daarbij duurde het langer dan wenselijk voordat iedereen op de juiste plek zat. Een volgende keer gaan we gebruik maken van Zoom of een andere online tool.
  • Daarnaast willen we de volgende keer dat een persoon als moderator optreed voor wat betreft technische zaken en mensen die inlogproblemen hebben. Dat moet ook duidelijk zijn voor de genodigden. Nu waren er een aantal mensen bezig, o.a. de gene die het eerste gedeelte aan het uitleggen was, met mensen toegang te verlenen en troubleshooting.
  • We hadden vooraf een half uur inloop gepland voor het officiële gedeelte zou beginnen. Net als bij een fysieke meetup. We merkten echter dat nu bijna iedereen pas in de laatste minuut digitaal binnenkwam. De volgende week maken 20 tot 30 minuten inloop onderdeel van de officiële planning. Zijn we eerder klaar, dan is het mooi en gaan we van start, maar andere loop je gelijk al achter op de planning.
  • We hadden een vrij strakke planning, met het schakelen van gezamenlijke onderdelen naar break-out onderdelen verloren we tijd, waardoor de planning nog meer in het gedrang kwam. De volgende keer gaan we dus ruimer plannen.
  • De intro die we gaven m.b.t. User Story Mapping was te kort. Gedurende de meetup kwamen we er achter dat niet voor iedereen duidelijk wat nou precies het doel is en wanneer je het goed kunt gebruiken. De volgende keer gaan we hier vooraf langer bij stilstaan.
  • Ondanks dat User Story Mapping redelijk gangbaar is, merkten we toch dat er verschillende interpretaties zijn van de techniek. Ook als facilitators. Hier hadden we vooraf langer bij stil moeten staan. Voor een volgende keer gaan we bijvoorbeeld duidelijker bepalen of we gaan focussen op het maken van een back-bone of dat we meer aandacht gaan besteden aan het maken van slices en een development strategie. We hadden een redelijk complexe casus gekozen, met als onderwerp het Havenbedrijf in Rotterdam. Erg interessant, maar wellicht dat we voor een volgende een iets minder complexe casus kiezen.
  • Twee uur voor een meetup/workshop met een onderwerp als dit is erg kort. Om het onderwerp echt recht te doen en tijd te hebben om er zelf mee aan de slag te gaan, heb je al gauw 4 tot 6 uur nodig.

De volgende keer dat we aan de slag gaan met User Story Mapping is op 27 mei, met Agile Meetup Rotterdam.

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.

 

Scrum mastery in corona-tijden

Als gevolg van de corona maatregelen zullen de meeste van onze teams thuis gaan werken. Dat is lastig. Met een heel team op dezelfde werkplek zitten maakt goed scrummen veel gemakkelijker. Er is veel spontane communicatie, we zien elkaar’s non-verbale communicatie, en dat raken we nu kwijt. Dat betekent dat de rol van de scrum master nog veel belangrijker wordt dan deze al was.
Hierbij een aantal praktische tips die wij met elkaar verzonnen. Ik hoor van jullie wel of er nog meer ideeën zijn.

Algemeen

  • communiceer heel erg veel, bel ieder teamlid elke dag even persoonlijk op om te horen hoe het gaat, juist ook privé. Zijn er zorgen rondom corona in het gezin, bij grootouders, etc.
  • het zijn best spannende tijden, mensen zullen meer gespannen zijn dan anders, als scrum master ben je nu vooral vertrouwenspersoon
  • deel de informatie uit je bedrijf over hoe wij omgaan met Corona
  • doe aan verwachtingsmanagement naar je team en naar je stakeholders toe. De velocity zal wel wat omlaag gaan, de moraal in het team misschien ook. Bespreek dit, wees er open over
  • on-line meetings zijn lastiger dan gewone, mensen zijn sneller afgeleid en zo’n meeting is vermoeiender. Benoem dit. Vraag mensen om dingen die afleiden (nu.nl dat open staat, whatsapp, e.d.) uit te zetten tijdens de meeting. Vraag iedereen de camera aan te zetten, zodat je de betrokkenheid, net als in een gewone meeting, kan monitoren.
  • houd je meetings korter dan anders. 1 uur is echt de max!
  • faciliteer wat strakker. Er kan maar 1 persoon tegelijk aan het woord zijn. Er zit vaak wat vertraging in beeld en/of geluid, houd daar rekening mee.
  • gebruik een headset en niet het geluid van je laptop zodat er veel minder achtergrondgeruis is
    thuiswerken biedt een hoop flexibiliteit, als ’s middags de kinderen thuis zijn kan je ook ’s avonds werken. Maar voor de samenwerking is dat allemaal niet zo handig. Maak dat bespreekbaar in je team. Houden we ons aan de gewone kantoortijden? Of in ieder geval ’s ochtends?
  • wij hebben zelf wel goede ervaringen met Microsoft Teams – en Microsoft biedt het op dit moment ook gratis aan. Experimenteer er veel mee als scrum master. Zorg dat je er zo handig mee bent dat de tool een goede meeting niet (of zo min mogelijk) in de weg zit.
  • zet ook een kanaal op in Teams voor het gewone gekwebbel – we blijven gewoon mensen die af en toe een beetje persoonlijk willen ouwehoeren
  • als je Jira gebruikt: de desktop app is vaak veel sneller, en is overzichtelijker dan de web-app

Per Scrum event (een beetje creatief geïnterpreteerd 😉

Sprint Planning

  • zorg, nog meer dan anders, dat je Product Backlog (in Jira of anders) helemaal op orde is. Verdoe de tijd van je team niet met allerlei klein grut. Maar de nieuwe sprint vast aan. Sleep de items die de PO graag wil hebben in deze sprint hier vast naar toe. En heb dan de discussie of dit wel past.
  • zorg dat je de gemiddelde velocity van de afgelopen sprints, en de vakantieplanning van medewerkers paraat hebt, zodat je goed de verwachte velocity voor de komende sprint kan inschatten. Ik vermoed dat deze door veel thuiswerken al snel 10-20% lager zal liggen dan wat je in een co-located team zou halen
  • de Sprint Planning 1 (waar je items van de product backlog de sprint in trekt) is iets dat je echt met het gehele team moet doen
  • Sprint Planning 2 (waar je je detailed design doet en technische taken aanmaakt) kan prima gedaan worden in kleine groepjes of door individuele teamleden. Daardoor kan je de meeting korter en meer gefocust houden

Daily Scrum (aka Daily Standup)

  • het zou kunnen dat je wat meer tijd nodig hebt dan anders, ga wat flexibeler met de 15 minuten timebox om
  • en misschien moet je 2x of 3x per dag een daily scrum doen
  • een check-in, waarin iedereen even vertelt hoe het met hem/haar gaat, voordat je de inhoud in gaat lijkt ons erg nuttig
  • het lijkt nu, nog meer dan anders, nuttig om niet een ‘rondje langs de mensen’ te maken, maar de sprintbacklog te volgen. “Wie heeft er gisteren aan item 1 gewerkt, wie werkt er vandaag aan, wat houdt ons tegen om dit vandaag of morgen naar DONE te krijgen?”. Hierdoor voorkom je dat je continu heen en weer moet scrollen in Jira (of welke sprint backlog tool je ook gebruikt). Nu kan je rustig van boven naar beneden gaan. Dat stimuleert meteen dat mensen swarmen en de belangrijkste items als eerste oppakken. Meer hierover in deze post.

Het gewone werk

  • let erop als scrum master dat er nog steeds veel informeel contact is tussen de teamleden, houd je chat/slack kanalen een beetje in de gaten, is er genoeg communicatie, doet iedereen mee?
  • als er per backlog item geswarmed wordt, zet er een apart kanaal voor op zodat de mensen die aan dat item werken een eigen plekje hebben voor communicatie
  • laat de techniek ook z’n werk doen – koppel een teams kanaal aan Git, zodat je ziet dat er pull requests worden gedaan, koppel aan je test automation framework zodat je ziet dat je tests omvallen

Backlog Refinement

  • houd zeker deze meetings wat korter. Kies een duidelijke, kleine scope, en refine alleen dat. Dus liever wat meer refinement meetings, die ieder wat korter zijn.
  • gebruik on-line tools om te schetsen, ik vind zelf miro.com wel een fijne tool.
  • planning poker kan prima in een microsoft teams chat, iedereen tikt daar gewoon haar geschatte getal in

Retrospective

  • misschien kan je deze iets vaker doen. 1 keer per week in plaats van 1 keer per sprint – en dan uiteraard per keer wat korter
  • start met een check-in, “hoe gaat het met je?”
  • begin de retro met een retro op het thuiswerken
  • geef teambuilding, samenwerking nog meer aandacht dan anders
  • zorg zeker voor een goede sfeer, de complimentendouche is nu zeker een mooie werkvorm – schuif een beetje van procesverbetering naar ‘hoe maken we er het beste van’
  • haal vooraf de punten op die men wil bespreken, dat scheelt wat tijd in de data gathering fase van de retro.
  • en zoals altijd, zorg voor 1 of 2 concrete, kleine verbeterpunten

Microsoft Teams (of een ander medium voor online samenwerken)

  • als je dit goed gebruikt en goed inricht wordt dit je enige communicatiekanaal. Mail, Outlook meetings, Whatsapp worden overbodig.
  • Teams is goed te koppelen met allerlei externe applicaties, dus de status in Git of van je Tests is in een eigen kanaal voor iedereen zichtbaar
  • Je kunt mensen in een kanaal uitnodigen voor een meeting, die staat dan meteen in de team-agenda, en je hoeft niet een voor een de mensen uit te nodigen, iedereen die in het team zit krijgt ‘m vanzelf

Succes ermee! Meer tips?

Een goed begin: het einde van het begin

Dit is het vervolg op Een goed begin: het verhaal in kaart, dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

De vorige oefening eindigde met een story map. Bijzonder nuttig en prettig, maar hoe hier een begin mee te maken? Ik legde uit dat we eerst een tussenstap gingen maken, voordat we dit gingen bepalen.

Done? Or Done?

Wanneer is iets klaar?

Leuk, al die kleine brokjes werk, maar wanneer zijn deze af? Hier geeft de Definition of Done (DoD) antwoord op. Ik legde uit dat dat zij als team deze zelf mochten definiëren. Ik gaf een aantal voorbeelden:

  • Het ontwerp is aangepast
  • De code is gereviewed
  • De user story is getest
  • De documentatie is bijgewerkt
  • De Product Owner is akkoord

Ik vroeg elk teamlid de volgens hem/haar 3 belangrijkste elementen van een DoD te noteren op een post-it. Dit was binnen 5 minuten gebeurd. Daarna mocht het team dot-voten, waarbij ieder teamlid 3 stemmen kreeg. Hiermee probeerde ik De DoD – initieel – klein te houden. Bij uitzondering gaf ik ook een stemadvies mee: “Let op: de DoD werkt als een ‘kwaliteitslat’. Deze leg je jezelf op. De lat verhogen kan altijd en een start maken als team is al lastig zat. Leg de lat daarom niet te hoog voor jezelf”.

Dit werd goed begrepen en de uitslag van de stemming leverde vrij weinig discussie op. De DoD was daarmee vastgesteld.

Inschatten maar

Terug naar de story map. Nu we hadden vastgesteld wanneer een user story klaar was, konden we de stories gaan inschatten om een gevoel te krijgen bij de grootte hiervan.

Om het makkelijk te houden, hanteerde ik de volgende groottes: Small, Medium en Large. Wat dit was, wisten we alleen nog niet. Daarom vroeg ik het team om een van de kleinste stories aan te wijzen op de story map. Deze kreeg een ‘S’. Idem voor een van de grootste en een gemiddelde.

Een S, M en L geïdentificeerd

De rest was een simpele kijk-en-vergelijk met deze drie ijkpunten. Ik ging van linksboven naar rechtonder alle user stories langs en vroeg het team telkens: ‘Is deze user story small, medium of large?’. Een enkele keer heb ik vragen/discussies moeten afkappen en de vraag moeten herhalen. Na 15 minuten zwoegen waren alle user stories ingeschat.

Allemaal ingeschat

De eerste sprint

Nu hadden we genoeg informatie om te bepalen wat we zouden gaan doen in de eerste sprint. Ik gaf de eerste zet aan de Product Owner. Hij mocht stemmen welke user stories hij graag opgepakt zou zien door het team. Ik gaf hem de volgende voorwaarden mee, allemaal met het idee de eerste sprint haalbaar te houden:

  • Slechts 5 stemmen. Dit hield de stories voor de eerste sprint beperkt.
  • Alleen stemmen op user stories in de eerste rij. We hadden niet voor niets de user stories op logische volgorde gehangen.
  • Alleen stemmen op user stories met een S. Kleine user stories zijn meestal makkelijker.

De 5 keuzes van de PO

De volgende zet was aan het team. Ten opzichte van de oefening met de elevator pitch waren de rollen nu omgedraaid. De wensen van de PO waren slechts wensen. Het was nu aan het team om een aantal user stories te kiezen voor de volgende sprint.

Het was leuk om te zien wat hier gebeurde:

  • Het team nam niet het advies van de PO 1-op-1 over. Aan sommige user stories wilden ze liever nog niet beginnen. Ik scoorde opnieuw een goede balans in de verhouding PO – team.
  • Het team zorgde voor voldoende werk voor alle teamleden (het team had enkele specialisten aan boord).

De keuzes van het team (vierkant omlijnd).

Daarmee hadden we een mini-sprintplanning gedaan! Ik feliciteerde het team met het resultaat en de wijze waarop ze dit met elkaar hadden gedaan (en zag dat ze er zelf ook wel tevreden en een beetje trots op waren).

Tot slot

Het was tijd geworden om af te sluiten. Het programma was op, maar de energie ook. Ik hield de afsluiting daarom super-kort (maar krachtig!).

Als eerste keken we terug op wat we wilden leren. Met zijn allen stonden we rond het brown-paper met de post-it’s met leerpunten. Een voor een haalde iedereen zijn geleerde punten weg. Slechts een paar leerpunten bleven over. Deze waren relatief technisch/inhoudelijk van aard. We spraken uit dat we deze punten in de eerste sprints waarschijnlijk gaandeweg zouden gaan leren.

De allerlaatste oefening vond plaats in een grote kring. Ik vroeg alle teamleden terug te kijken op de afgelopen dagen en hun gedachten te delen in één woord. Ze mochten dit woord toelichten, maar dat hoefde niet. Uit de reacties kon ik merken dat iedereen de dagen bijzonder waardevol had gevonden en graag aan de slag wilde gaan.

En dit was nog maar het begin.

Dit was het laatste deel in deze serie. Zonder te overdrijven: een betere investering voor een goed project heb ik in de afgelopen 15 jaar nog niet eerder meegemaakt.

Een goed begin: het verhaal in kaart

Dit is het vervolg op Een goed begin: Wat houdt je wakker? dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

In de vorige oefening haalden we de ‘ja-maars’ uit het team en maakten we hiervan gedeelde zorgen. We konden weer verder waar we gebleven waren: ‘Ok, en hoe gaan we dat dan doen?’. Om dat te bepalen, heb ik het team – in 3 stappen – een story map in elkaar laten zetten.

Stap 1: Van grote naar middelgrote brokken werk

Ik legde het team uit dat we een story map gingen maken, om beter zicht te krijgen op onze scope voor de komende maanden. Ik legde uit dat we dit stap voor stap gingen doen, kennis van wat een story map is, was dus handig, maar niet nodig.

De ‘epics’.

Voor een snelle start, had ik alvast gekeken naar wat het team in scope had gezet voor de komende maanden. Daaruit had ik een aantal grote brokken werk geïdentificeerd. Ik vroeg het team deze grote brokken werk te verdelen in middelgrote brokken. Per grote brok werk, minimaal 2, maximaal 7 middelgrote.

Ik kreeg direct vragen of dit dan epics en features waren en hoe we die dan definieerden. Ik was blij met deze voorkennis, maar ik had geen trek in een discussie over definities. Ik gaf daarom aan dat je dit zo zou kunnen zien, maar dat dit voor nu niet van belang was.

Na enige aarzeling kwam het team op gang, maar binnen een paar minuten was het al weer gebeurd:

Nu met ‘features’

Stap 2: Van middelgrote naar kleinste brokken werk

In deze stap vroeg ik het team alle post-it’s uit de vorige oefening een plek te geven onder een middelgrote brok werk. Dit pakte het team snel op en was zo gebeurd:

Nu met ‘Stories’

Twee nieuwe inzichten:

  • Enkele kleinste brokken werk bleken nergens te ‘passen’. Het team besloot hiervoor een extra grote brok werk te definiëren, inclusief onderliggende middelgrote brokken werk.
  • Sommige middelgrote brokken werk hadden geen kleinste brokken werk. Dat werd direct door het team opgemerkt (“Wat moeten we daarmee?” – “Goed gezien, daar komen we zo aan toe.”).

Voor we verder gingen naar de volgende stap, vroeg ik ze om de kleinste brokken werk op volgorde te zetten: de brokken werk die het eerste uitgevoerd moesten worden/het kleinste waren/het meest duidelijk waren bovenaan, de brokken werk die als laatste uitgevoerd moesten worden/het grootste waren/het meest onduidelijk waren onderaan. Dit was zo gebeurd, o.a. omdat ik had aangegeven dat ‘ongeveer’ goed genoeg was.

Stap 3: Kleinste brokken werk aangescherpt

Ik legde het team uit dat we de story map nu compleet gingen maken. Ik vroeg ze ieder een eigen kolom in de story map te kiezen en voor deze kolom te gaan staan, zodanig dat er een halve cirkel rond de story map zou ontstaan. Daarna vroeg ik ze om ‘hun’ kolom kritisch te bekijken. Alles mocht: post-it’s erbij plakken, herschrijven, splitsen of zelfs verwijderen. Ik gaf ze 2 minuten per kolom en liet ze daarna ‘doordraaien’.

In het begin waren ze nog redelijk voorzichtig, maar na een paar keer doordraaien ontstond er al meer initiatief (“Mag ik deze post-it aanpassen?” – “Natuurlijk. Maar misschien kan het geen kwaad hierover even te overleggen met iemand.”). Zo ontstonden er kleine gesprekken over de scope van sommige post-it’s en hoe deze beter te definiëren.

Na ongeveer 20 minuten was dit het resultaat:

En nu helemaal compleet

Deze oefening maakte, nog sterker dan de oefening waarbij de scope voor het eerst werd bepaald, dat het team echt zélf bepaalde wat er allemaal moest gebeuren. Ik zag in deze oefening voor mijn ogen gebeuren dat het team zich het werk toe-eigende. Daarmee waren ze klaar voor de volgende stap.

Een goed begin: Wat houdt je wakker?

Dit is het vervolg op To do, or not to do? dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

In de vorige oefening koos het team de scope voor het minimal lovable product over 3 maanden. De volgende logische stap zou zijn: ‘Ok, en hoe gaan we dat dan doen?’. Maar voordat we die stap zouden gaan nemen, was er een belangrijke tussenstap te zetten. Je zou dit de ‘ja-maar’ stap kunnen noemen.

In de allereerste kennismaking waren we er al achtergekomen dat het team stikte van het Insights consciëntieuze blauw. Mensen met dit profiel zijn van nature gericht op de details, al kunnen ze daar ook verstrikt in raken. Deze mensen zijn bij uitstek geschikt voor de luis-in-de-pels rol, de mensen van de ‘ja, maar…’.

En de details, die ontbraken natuurlijk volledig in de elke oefening die we deden. Die passen simpelweg nooit op een post-it. Dat is voor de oefening natuurlijk precies de bedoeling, omdat zo de snelheid erin blijft. Daarom was het tijd voor een moment van vertraging. Tijd voor de ‘ja, maar…’.

Ik hield ze daarom het volgende voor: “Ik neem jullie mee naar een donkere toekomst. Stel je voor: we hebben met zijn allen een aantal maanden keihard gewerkt. Misschien wel een jaar lang. Maar dan wordt dit project gestopt. Dat was onvermijdelijk, want het is gruwelijk mis gegaan. De vraag is nu ‘Wat heeft er voor gezorgd dat het zo gruwelijk is misgegaan?”

Met deze oefening vroeg ik om ze ‘terug’ te laten kijken op het nu vanuit een denkbeeldige toekomst. Dat was voor niet iedereen even makkelijk. Daarom voegde ik een alternatief toe: “Vind je dit een lastige vraag, dan mag je hem ook anders benaderen: Stel dat dit project hopeloos mis zou gaan, waar zou dit dan aan liggen?”

De rest van de oefening was eenvoudig: na ongeveer 5 minuten hing er een bonte verzameling van post-it’s op de wand. Deze mochten ze groeperen, en daarna mochten ze dotvoten met zo veel stemmen als ze wilden. In de pauze naar de volgende oefening hing ik de post-it’s vervolgens van links naar rechts op volgorde van het aantal stemmen dat ze hadden gekregen.

In de dagen, wekend en zelfs maanden die volgden, was deze ‘slinger’ een goed aanknopingspunt voor een gesprek. We wezen ernaar als we een zorg in de praktijk hadden gezien, we een maatregel besproken, of juist wanneer deze zorg (gelukkig!) zich niet voordeed.

Ter afsluiting nog twee dingen die we niet hebben gedaan tijdens de oefening (en die mij goed zijn bevallen 😊).

We hebben niet over risico’s gepraat. Zodra je over risico’s gaat praten, kan het namelijk heel goed gebeuren dat het meer theoretisch wordt dan praktisch, meer over de risico’s buiten het team, dan in het team, meer over wat er mis kan gaan bij de ander, dan bij jezelf. We hebben het daarom niet over de risico’s gepraat, maar onze eigen zorgen. En aan een oprechte zorg vanuit jezelf, daar doet niemand wat aan af.

Wat we ook niet hebben gedaan, is over risico-mitigatie gepraat. Daar ga je het over hebben, als je risico’s wilt voorkomen of de effecten van de risico’s wilt verminderen. Maar daar ging deze oefening helemaal niet over. Het doel van deze oefening was om zo eerlijk en transparant mogelijk elkaars zorgen te delen. Op die manier worden het gezamenlijke zorgen. Het dealen met deze zorgen wordt dan een teamaangelegenheid en komt dan echt wel goed.

Een goed begin: To do, or not to do?

Dit is het vervolg op Een goed begin: het product dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

Okay, het team heeft duidelijk zicht gekregen op de klanten en met de elevator pitch en de product box duidelijk gemaakt wat het product gaat worden. Tijd voor de volgende stap.

Ik vertelde het team dat we de focus gingen verleggen van het uiteindelijke product over ongeveer 1,5 jaar, naar een meest basale versie hiervan (voor de liefhebbers: een minimum viable loveable product) over 3 maanden. Ik gaf aan dat zij hiervan de scope gingen bepalen.

Ik vroeg ze te putten uit de informatie die ze hadden opgedaan uit de interviews, de elevator pitch en de product boxes. En natuurlijk hun eigen ervaring & expertise. In een aantal rondes kwamen we tot deze scope.

Ronde 1: Verzamelen

Iedereen kreeg van mij de bekende gele post-its, deze keer met een velletje groene en rode stickers. Ik vroeg ze zo veel mogelijk dingen te bedenken die volgens hen wel en niet in scope zouden moeten zijn voor de komende 3 maanden.

Ik vroeg ze de post-its te voorzien van een groene of rode sticker, afhankelijk van of ze vonden dat het wel of niet in scope zou moeten zijn. Dit alles gebeurde in stilte.

Na 5 minuten hing er een wand vol met post-its, kris-kras door elkaar, zowel qua onderwerp als qua wel/niet in scope.

Ronde 2: Groeperen

Vervolgens vroeg ik het team de post-its te groeperen op onderwerp, zonder te letten op de kleur van de stickers. Dit gebeurde weer in stilte.

Ronde 3: Bepaling scope – zonder discussie.

Nu hing de wand geordend in groepen van verschillende groottes. Op een andere plek op de wand had ik 3 kolommen gemaakt die aangaven of iets in scope is, uit scope, of nog onbeslist.

Ik vroeg het team de groepen post-its te bekijken en deze te verplaatsen naar een van deze 3 kolommen. Groepen van post-its met uitsluitend groene of rode stickers mochten naar de groene of rode kolom. Groepen van post-its met zowel groene als rode stickers mochten naar ‘?’.

Dit leidde er toe dat één hele grote groep post-its alsnog werd opgesplitst in kleinere groepen. Deze kleinere groepen werden vervolgens verplaatst naar een van de drie kolommen.

Ik vond het opvallend dat maar ongeveer 10% van alle post-its in de ‘twijfel’ kolom waren beland. Blijkbaar zat het team al goed op één lijn. Ik benoemde dit en vertelde dat we het over al de (groepen) post-its in de linker en rechter kolom niet gingen hebben. Daar waren we toch al over eens!

Ronde 4: Bepaling scope – met discussie

Nu restte ons nog de ‘?’ kolom van de wand. Ik vroeg aan het team te kijken of ze hun eigen post-it(s) herkenden en zo ja: naar voren te komen en uitleg te geven over de reden voor een groene of rode sticker.

Heel bewust gaf ik hierbij geen instructie over hoe de discussie gevoerd moest worden en wie hierbij de doorslaggevende stem had. Ik wilde – zonder het te benoemen – laten zien hoe belangrijk het is om initiatief nemen en je uit te spreken.

Even gebeurde er niets, en toen stapte de PO naar voren en begon de briefjes langs te lopen. Voor mij een goed moment om te kijken of PO en team goed met elkaar overweg zouden kunnen. Gelukkig sprak iedereen zich uit en werd er in het overgrote deel van de gevallen snel consensus bereikt. Over een enkel onderwerp bleef verschil van mening. Op mijn voorstel werden die discussies geparkeerd tot een later moment waarop we meer zouden weten.

In 60 minuten heeft het team zélf de scope vastgesteld voor de komende 3 maanden. Ik zag volop het nemen van verantwoordelijkheid en eigenaarschap in actie. Door de discussies kreeg het team inzicht in elkaars expertise en bouwde het zo aan onderling vertrouwen.

Deze oefening vond ik – by far – de spannendste. Tot nu toe kon je de oefeningen nog afdoen als spielerei, dit ging om scherpe keuzes maken. Wat als het team geen keuze durft te maken? Wat als het één grote discussie zou worden? Naar mijn mening zijn discussies onvermijdelijk en zijn deze het gemakkelijkst in het begin te voeren. Gelukkig had ik de Product Owner hierin helemaal mee en pakte de oefening goed uit. Aan de andere kant: als de oefening was ‘mislukt’ had dat gelijk ook een heleboel duidelijk gemaakt.