The art of creating value

What is value?

Value is perceived differently per company. Making more money, increasing NPS or increasing market share for example. For some these are values and for some these are means. Take Oxfam who aim to create a world free of poverty. Making money is a means, having fewer people in poverty is value. Also commercial companies can see money as means. Take SpaceX with their mission to make life multiplanetary or Tesla who want to accelerate the world’s transition to sustainable energy. Creating a spacesuit for Mars would be value to SpaceX, because it will bring them 1 step closer to their mission. Technically, if all of Tesla’s competitors would switch to solely building electric cars, it would be value to Tesla, because it would bring them closer towards their mission. 

So creating value is simple, right? For whatever is valuable to us, we create a key performance indicator (KPI). Any distractions are forbidden, we tell everybody to FOCUS on the KPI and if the trend is upwards we must be creating value. 

Who seeks value?

Not just companies seek value, employees do as well. We want to learn, to be challenged, work towards a goal we also believe in and be compensated for something valuable to us at the end of every month. Business partners and even governments seek value from your company. Your business can grow theirs and your business supplies jobs for people who can then fund the government through taxes. In fact, anyone economically involved in a company can bring and wants to retrieve value from a company.  

How do we truly create value?

So let’s say our company is aiming to make more money and decide to cut the salary of the employees and increase the rates for its business partners. Are we creating value? According to our KPI we are. However, it decreased what is valuable to other stakeholders, so I think we should call this ‘moving value’* instead. Now if we decide to put an application live before testing it, are we creating value? This could hurt quality or increase the work after going live. I think we should call this ‘stealing value from the future’*. 

So what is the art of creating value? Creating value is the art of increasing value while preserving what is already valuable to us and all of our employees and stakeholders. If you are a privately owned company with 1 employee selling folded airplanes, then by all means create KPIs for everything that is valuable. However, if your company is (much) more complex than that, be under no illusion that KPIs will give you insight in whether value is being created rather than being stolen or movedIn order to add value, you need to listen to all of your employees and stakeholders, carefullyThis is art. 

*: The terms ‘moving value’ and ‘stealing value from the future’ were mentioned by Jurgen Appelo in his book ‘Managing for happiness’This partially inspired me to write this article and I can definitely recommend his book! 

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.

Screenshot Mural board User Story Mapping

User Story Mapping – faciliteer zelf een online workshop

Op 27 mei hebben we een tweede online meetup georganiseerd met als thema ‘User Story Mapping‘. Deze keer voor de leden van de meetup groep Agile Meetup Rotterdam (al maakt in deze tijden van thuiswerken de locatie niet veel meer uit). Een maand eerder hadden we dit onderwerp al besproken tijdens de  Agile Meetup Breda, waarvan je in deze blogpost de samenvatting kunt vinden. In dit artikel beschrijven we wat we anders hebben gedaan dan de vorige keer en wat het effect hiervan was. Kleine teaser: het was een groot succes!

Mocht je zelf een keer deze workshop willen faciliteren: een overzicht van onze aanpak, de stappen die we hebben doorlopen en enkele tips kun je vinden in de Facilitation Guide.

Heb je interesse in een door ons gefaciliteerde Story Mapping workshop voor jouw organisatie en teams? Neem dan contact met mij op via rutger.vandijk@valueminds.nl !

Agile Meetup Rotterdam

Via onze Meetup-site stond de teller op 30 inschrijvingen met een wachtlijst van 17 personen. Uiteindelijk waren er tijdens de sessie 22 deelnemers,  waarvan 4 Valueminds collega’s als facilitators. De meetup was van 15:00u tot 17:00u, met ongeveer 15 minuten ‘digitale inloop’.

Deze keer was de case: het ontwikkelen van een (fictieve) ‘Corona-app’. Ter voorbereiding hebben we enkele onderdelen van de story map uitgewerkt. Het doel was om een app te ontwikkelen die registreert wie, wanneer en waar met elkaar in contact komt. Vervolgens geeft de app aan of er contact is geweest met een persoon die mogelijk besmet is met Covid-19. Daarnaast kon een medewerker van een gezondheidsdienst een Covid-19 test uitvoeren en werden gebruikers geïnformeerd over eventueel te vermijden hotspots.

Tijdens de meetup hebben we in groepen de hoofdstappen van de story map opgesplitst in kleinere stappen, ideeën en mogelijke taken. Voor de Story Map-kenners: de ‘Explore’-fase. De fictieve heren ‘Chris Civilian’ en ‘Harry Health Care’ zijn ingezet als persona’s.

Aanpassingen & Verbeteringen

 

1. Microsoft Teams v.s. Zoom

Voor de bijeenkomst van Agile Meetup Breda hadden we gebruik gemaakt van Microsoft Teams; dat werkte toen niet ideaal. Met name vanwege toegangsproblemen en werkplekinstellingen duurde het 20 minuten voordat iedereen op de juiste plaats was en we konden starten.

Deze keer hebben we Zoom gebruikt en dat bleek een goede keuze. Iedereen kon zonder problemen in bij Zoom aanmelden en was er duidelijk beeld en geluid. De chat functionaliteit in Zoom is wel wat beperkt ten opzichte van Teams. Bij Zoom kan je dan weer alle deelnemers tegelijkertijd zien.

Tip
Het gebruik van de break-out rooms functionaliteit in Zoom werkt eenvoudig. In enkele klikken zijn alle deelnemers verdeeld over verschillende video-chat-groepen!

 

2. Hosting en moderating

Deze keer was een van de facilitators nu dedicated moderator én time keeper. Dat werkte erg prettig en gaf rust bij de overige facilitators. Zo konden eventuele ‘laatkomers’ worden opgevangen in de hoofdsessie en doorgestuurd worden naar de breakout rooms. De vorige keer deden alle facilitators dit erbij, waardoor het voor kwam dat degene die het woord was, ook bezig was om deelnemers toegang te verlenen. Zowel voor de facilitators als de deelnemers leidde dit erg af.

Tip
Zorg voor een apart betaald Zoom-account naast de ‘facilitator’ accounts. Zo kan de moderator alle ‘digitale’ touwtjes in handen houden!

 

3. De ‘digitale inloop’

Onderdeel van de officiële agenda was een kwartier “troubleshooting” en “sandboxing”. Oftewel: zorgen dat iedereen toegang had tot Zoom en de online collaboration tool van Mural.

Ook hebben we de deelnemers de kans gegeven om al even rond te kijken in het Mural-board. Hier kon alvast geoefend worden met het creëren en verslepen van bijvoorbeeld sticky notes.

De eerste keer hadden we een half uur ‘inloop’ voor de eigenlijke start van de meetup gepland. Daar werd toen nauwelijks gebruik van gemaakt. Deze keer was bijna iedereen stipt bij aanvang om 15:00u aanwezig. En omdat we geen problemen meer hadden met het aanmelden en instellen van Zoom, heeft iedereen de tijd gehad om al wat rond te neuzen in Mural.

Tip
Geef iedereen even tijd om de werking van browsers, webcams en microfoons te controleren.
(ondanks dat de meeste thuiswerkers in deze bijzondere periode hun werkplek inmiddels wel op orde hebben)

 

4. User Story Mapping: de ‘Corona-app’

Tijdens Agile Breda meetup hebben we een casus gebruikt met als onderwerp het ‘inspecteren van gevaarlijke stoffen aan boord van zeevaartschepen in de Rotterdamse haven’. Dit bleek toen best een complex situatie. Het was niet voor iedereen even gemakkelijk voor te stellen wat de persona’s nu aan precies aan taken (user actions) zouden kunnen hebben.

Gezien de actualiteit, kozen we voor het (fictief) ontwerpen van een Corona-app. We hebben nog licht getwijfeld of we ons, wat betreft User Story Mapping, wilden richten tot beginners of meer gevorderden. En of we in Mural zouden starten met een nagenoeg leeg canvas om vervolgens samen stap voor stap een story map op te bouwen. Een alternatief was om een uitgewerkte User Story Map neer te zetten, die we dan met de deelnemers zouden doorlopen.

Uiteindelijk hebben we gekozen voor een combinatie:

  • een tweetal persona’s beschreven (Harry Health Care en Chris Civilian)
  • een voorbeeld ‘backbone’ story map per break out groep gemaakt
  • een geheel uitgewerkt storymap met “release slices” en een ontwikkelstrategie.

De voorbeeld backbone story map was ingevuld tot aan het “Explore” gedeelte. Dat gedeelte hebben we in break out sessies met de deelnemers ingevuld. Hierna hebben we aan de hand van de voorbereide story map laten zien hoe je de release slices maakt op basis van duidelijke release doelen. Via deze release doelen hebben we een ontwikkelstrategie bepaalt. Tot slot hebben we laten zien hoe je de betreffende release opneemt in de Sprint Backlog, van waaruit de ontwikkelteams aan de slag kunnen. Want daar gaat het natuurlijk om!

Tip
Zorg voor voldoende interactie en samenwerking tijdens een online meetup. Als je alleen wilt vertellen of laten zien hoe je een Story Map maakt, kan een webinar of webcast een betere vorm zijn.

 

5. Agenda & tijd

Deze keer hebben we ons goed aan de agenda kunnen houden. De sessie was korter, maar wel exact binnen tijd klaar. Door bijvoorbeeld maar één keer te schakelen naar een break out sessie, wordt het minder rommelig. Hierdoor zijn de deelnemers minder afgeleid en is er een duidelijke scheiding tussen de meetup onderdelen. Daarnaast voorkom je het afhaken van deelnemers als je ‘uit de tijd loopt’. De moderator hield, naast de facilitators, de tijd per onderdeel extra in de gaten.

Het gebruik van tools als Zoom, samen een dedicated moderator, helpen bij het volgen van de agenda en houden van contact met de deelnemers.

Tip
Oefen vooraf met het gebruik van tools als Zoom.
Probeer ook eventuele alternatieven uit om te bepalen wat het beste past bij het type sessie.

 

6. Kleine tweaks voor een volgende keer…

  • Controleer of alle layout onderdelen in het Mural-board vergrendeld (‘gelocked’) zijn.
    Nu werd er tijdens de workshop wel eens onbedoeld een deel van de Story Map door iemand versleept.
  • Introduceer ‘energizers’ tijdens de meetup. Het energieniveau van de deelnemers valt vaak na een tijd terug (je kijkt tenslotte vrij passief naar een beeldscherm). Een korte leuke oefening kan helpen om iedereen weer fris en actief te krijgen tijdens de sessies.
  • Voeg eventueel een uitgebreidere toelichting toe bij de verschillende stappen van, in dit geval, de Story Map. Hiermee kunnen deelnemers zelf nog de instructie nalezen.
    Ook kan je de Outline-functie van Mural hiervoor gebruiken.

 

Volgende meetup!

Gezien de enthousiaste reacties van de deelnemers en de mooie NPS score van 33, gaan we deze meetup vaker online organiseren. Op dit moment hebben we voldoende onderwerpen waar we uit kunnen kiezen!

Mocht je een onderwerp hebben waar je het graag over wilt hebben, stuur ons dan een bericht via de Meetup pagina. Tot de volgende meetup!

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.

How a yacht race turned me into a Scrum Master

This is a re-post from my blog, but one that is still relevant today.

Continuous Improvement, Autonomy, Validation – these terms are becoming so worn that they feel like business jargon. But if you have experienced the pain that Stagnation, Command & Control and Big Bang Deployment brings, you have ample reason not to look back.  The mild embarrassment that comes with joining the ‘Agile cult’ is greatly outweighed by the soul-numbing awfulness that is the alternative.

Although the above is my experience too, this is not that story.  I have also had experiences with Chaos – the inferno that regularly erupts in Startupland and in many Open Source projects.  It, not Agile, is the real antithesis to the frozen hell that is Waterfall/Taylorism/TheoryX.  This is not that story either.  I actually started appreciating what I now call the Agile mindset, on a sailing boat.

As an adolescent I was pretty interested in ‘Team Building’ and while training as an outdoor sports instructor, we learned about Tuckman’s Forming/Norming/Storming/Performing.  I had noticed that cohesive teams had better morale and more fun but that they also sometimes missed creative solutions to problems that messier, argumentative teams seemed to come up with.  This even led me to study social psychology, although that field had disappointingly few insights on offer.  And really, I didn’t want to just understand teams, I wanted to be a part of one.

As a student and later as a Yacht Master I did a lot of yacht racing.  Now in the nineties, mirroring the software development world, yachts were starting to organise themselves differently.  Being a relative pauper but a skilled sailor, I was used to being ordered around the boat by the owner, who would also steer the boat. If you wanted to win races, you had to find that rare combination of the rich and skilled sailor.

Imagine my surprise when one day I stepped aboard a boat, shook the hand of the young man at the helm and he diverted me to the owner!  Here was a man who had given up the driver position to some pipsqueak, fresh out of a dinghy!  I recounted the experience to my skipper later that evening and we laughed about this.  What chaos it must be on board!  They’ll never win a thing.

That year the boat, Yellow Rose, won every series it entered.  The next season it won all the major series in the Netherlands and thereby the national title.  The season after that, it won the national title and its own class – X-332 – internationally, as well as Cork week – one of the biggest fleet races in the world.  I had gotten to know them well by then, I knew that they were a relatively young crew and that they hardly ever changed members.  I was allowed to join them for a race, the nationals in Hamble, UK.

I had never seen anything like this.  The owner took the position of tactician, but not the helmsman ‘driver’ position.  He completely trusted the crew with his boat, concentrating instead on the wind, tide and competition.  There was almost no shouting on board and if emotions flared up because of an inevitable mistake, these were evaluated after each race.  But the evaluation was of what went wrong in the situation, no blame was assigned.

Even more astonishing was that: no one person gave a call when a manoeuvre was initiated – each time it was initiated by a different person.  The helmsman initiated a tack, the mainsail trimmer initiated a gybe, the bowman initiated a kite hoist.  I saw manoeuvres called and then initiated seconds later that would have taken minutes of complicated instruction by the tactician on my previous team. And they improved all the time, every race was meticulously discussed and adapted to.

I was addicted – I sailed with Yellow Rose as much as I could.  I progressed to training other sailing teams too and started to spread the goodness there.  I wanted to spread this goodness to my work in software development too, but it took me another five years of searching before I found a team where I was allowed to apply what I had learned on a boat.

I am not going back.

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.

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.

Online User Story Mapping

Dit is een facilitatiegids voor een online User Story Mapping workshop.

Wanneer gebruik je dit?

User Story Mapping is een techniek om in plaats van een platte lijst, een groter verband te laten zien tussen werkitems.  In een (serie) workshop(s), maak je een kaart van al het werk wat er nodig zal zijn om bepaalde uitkomsten te bereiken.  Het is een goede manier om van een ruw idee naar concreet maakbare productonderdelen te komen.  Een user story map komt het best tot zijn recht als het iteratief gebruikt wordt: bijvoorbeeld bij Sprint Reviews.

Ruwweg, ziet een user story map er zo uit:

  • Langs de bovenkant staan de ‘klant reizen’ – een ruwe chronologische reis door het product, per klant type.
  • Aan de linkerkant staan de ‘releases’ – de generaties van het product, ieder met een beoogd, meetbaar doel.
  • In het midden staan de stukken werk, in user stories uitgedrukt.

Lees Meer:

Mensen Tijd Tools Rollen
2 – 30 6 – 8 uur MS Teams of

  • Facilitator
  • Moderator
  • Ontwikkel Team
  • Product Owner
  • Stakeholders

Voorbereidingen:

  • Nodig iedereen uit.  Bedenk dat dit een hele dag of meerdere workshops over meerdere dagen kan worden.
    • Moderator: stel iemand aan die helpt met verbindingen en online tools
    • Facilitator: een of meerdere mensen zullen de workshop moeten begeleiden. Bij meer dan zes mensen wil je in ieder geval de ‘explore’ en ‘slicing’ workshops in breakout sessie doen, ieder met een eigen facilitator.
    • Development Team: iedereen die gaat werken aan het product moet nadenken over wat er gemaakt gaat worden.
    • Stakeholders: mensen die het product (gaan) gebruiken en/of er voor betalen moeten vertegenwoordigd worden.
    • Product Owner: de vaste vertegenwoordiging van de stakeholders aan het team en van het team aan de stakeholders, de ondernemer van het product.
  • Zet je videoconferencing en werkruimte op.  Hier is een Mural Template om makkelijk van start te gaan.
  • Repeteer met iig de moderator en factilitator(s).
  • Product Owner: Kijk naar het onderdeel ‘Frame’ en zorg dat je vooraf goed weet wat het probleem is dat je wenst op te lossen en voor wie.  Trap daarbij niet in de val dat je teveel al een oplossing bedenkt – daar is immers deze workshop voor!  Bereid een boeiend verhaal voor om dit in uit te leggen – onze template gebruikt bijvoorbeeld het ‘Hills – Who What Wow‘ format.

Materialen:

  • Goede video conferencing tool (Grote groepen – gebruik Zoom omwille van de ‘breakout room’ functionaliteit)
  • Goede white-boarding tool met de voorbereidingen (Bijvoorbeeld Mural, Miro of MS Whiteboard).
  • Deelnemers hebben een computer met microfoon en speakers en breedband internetverbinding nodig.

Agenda

Programmapunt Tijd
Inloop 30 min
Check-in 20 min
Introductie 10 min
Frame 30 min
Big Picture 30 min
Explore 1 uur
Slice out haalbare releases 1 uur
Slice out ontwikkelstrategie 1 uur
Wrap up 30 min
Check-out 20 min

Stap-voor-stap

Inloop

Als je niet gewend bent om samen online te werken, neem de tijd om iedereen aan te sluiten, video en geluid te checken en te zorgen dat mensen makkelijk mee kunnen doen.

Check-in

Het doel:

  • Mensen kennen elkaar beter
  • Deelnemers begrijpen waar de workshops over gaan
  • Deelnemers hebben hun verwachtingen geuit

Bijvoorbeeld:

  • Iedereen geeft een rondleiding door hun werkkamer en vertelt over het handigste foefje van hun werkplek.
  • Iedereen maakt een Post-It op het whiteboard met het ene ding dat zij uit de workshop willen halen.

Introductie

De facilitator neemt het whiteboard door, in volgorde van de stappen van de workshop.

Frame

De Product Owner presenteert de ‘brief’ of ‘Big Picture’ van het product – wat is het wel en wat is het niet.

  • Voor wie gaan we dit product maken?
  • Wat doen die mensen nu? Wat moeten ze kunnen doen?
  • Welke pijn ervaren deze mensen?  Wat zou hun leven beter/makkelijker maken?

Map the Big Picture

De Facilitator en Product Owner nemen de groep mee door het verhaal van de gebruiker(s) in een lineaire volgorde – bijvoorbeeld hun werkproces of klantreis.   Het gaat hierbij om een heel hoog-over overzicht – de ‘backbone’ van het verhaal.

  • Begin met de belangrijkste gebruiker eerst.
  • Identificeer concreet de activiteiten die gedaan worden – groepen taken die een bepaald doel hebben.
  • Voeg daarna de tweede gebruiker toe en werk weer links-naar-rechts hun verhaal uit.

Explore

Nu wordt het tijd om het midden van de story map te gaan vullen.  Breek de gebruikerstaken in kleinere subtaken en functionele details.  Je zult kaartje toevoegen, splitsen, herschrijven en herschikken.

Gebruik deze fase om alle mogelijkheden van de product te ‘Omdenken’.  Maak je geen zorgen of zaken haalbaar zijn of niet, dat komt later.

  • Speel ‘zou het niet leuk zijn als…’ om productideeën te genereren.
  • Zoek naar variaties: wat zouden gebruikers van het systeem anders hebben gedaan?
  • Zoek naar uitzonderingen: wat kan er mis gaan? Hoe kom je daar uit?
  • Wat zouden andere gebruikers doen om hun doel te bereiken?
  • Voeg andere productdetails toe: omschrijving van de interface, business rules, data elementen.

Betrek anderen.  Vertel het verhaal van je product aan anderen die je gebruikers kennen en vraag om reacties.  Zij kunnen de gaten in je verhaal helpen ontdekken.  Betrek het ontwikkel team, zij weten de risico’s en dure investeringen alsook de technologische mogelijkheden.

Slice out haalbare releases

In deze fase splits je de story map in integrale stukken, naar gebruikers en hun gebruik.  De ‘slices’ vormen in incrementeel product release plan waar iedere release waarde toevoegd.

Omschrijf voor iedere release de beoogde uitkomst en impact.  De uitkomst en impact geven hoe we verwachten dat deze release zal bijdragen het hoofddoel van het product en hoe gebruikers zich zullen gedragen om dat doel te bereiken.

Identificeer meetbare variabelen die je iet zeggen over het succes van het product.  Vraag telkens “wat meten we om het succes van het product zichtbaar te maken?”  Idealiter zul je veranderingen in het gedrag van je gebruikers vinden die het succes aantonen.

Slice out ontwikkelstrategie

Neem de eerste release van je product en breng daar in onderverdeling in van drie of meer fases om vroeg te leren en risico’s de verminderen.  Denk aan de opening-, midden- en slotzetten in een schaakspel.

De ontwikkelstrategie helpt om het best mogelijke product te leveren in de tijd die er beschikbaar is.

  • De openingszetten bouwen aan een ‘lopend skelet’ – de simpelst mogelijk werkende versie van het product.  De openingszet wordt geverifieerd met de gebruikers en andere stakeholders en zal daarna voortdurend getoetst worden op prestaties en schaalbaarheid.
  • De middenzetten vullen het lopende skelet aan met het geleerde uit de gebruikerstests.  Er blijft getoetst worden op prestaties en schaalbaarheid.
  • De slotzetten maken het product klaar voor ‘release’.  Houdt continu in de gaten hoe het product presteert tegen de releaseuitkomst en -doel.  Houdt rekening met onvoorzien werk in deze fase.

Wrap Up

Als het goed is, is alles klaar voor Sprint- of Item Planning.  Rond de sessie af met:

  • Een terugblik over het resultaat.
  • Afspraken voor het iteratief en incrementeel kijken naar de voortgang van het product en het bijwerken van de user story map.
  • Het afwikkelen van andere punten in de ‘parkeerplaats’ of die anders tijdens de workshops naar voren kwamen.

Check-out

De retrospective voor deze workshop:

  • Wat hebben deelnemers geleerd?
  • Wat moet voor deze workshop: toegevoegd-/gehouden-/weg gehaald worden?
  • Teruglopen door de verwachtingen uit de check-in.