product owner value game: refinement on-going

Product owner value game

Product owner value game

Dit game is ontworpen door Paul Kuijten en Dajo Breddels.

De context van de simulatie is om de rol en verantwoordelijkheden van een product owner beter te leren kennen en aan te leren. De simulatie focust zich dus op de backlog.

Wat is de rol van een product owner in een organisatie?

De product owner is verantwoordelijk voor het maximaliseren van de waarde van het product of service dat gemaakt wordt. De product owner zijn vehikel is de backlog: een lijst (1 bron) van alle requirements. De product owner heeft de autoriteit om te bepalen aan welke items het team eerst werkt (dit reflecteert zich in de rangschikking van de items in de backlog). Een product owner moet dus zeer goed weten wat de waarde is van items.

Het doel van de simulatie is dan ook uiteraard om maximaal waarde te creëren!

De simulatie maakt een abstractie, dus het volgende is gegeven:

  • Een backlog met een lijst van items (features/epics met een gegeven schatting van waarde en effort)
  • De features bestaan uit een aantal user stories (opnieuw met een gegeven schatting van waarde en effort)

Wat is product backlog refinement?

Refinement is de activiteit van het onderhouden van de backlog en het verder verfijnen van items in de backlog (door verduidelijking, toevoegen detail, verfijnen van waarde, verfijnen van inschattingen, etc.).

De simulatie

Initiële backlog (T-shirt sizing voor effort, waarde schatting in punten):

product owner value game: the backlog

product owner value game: the backlog

Refinement van 2 features (decompositie in user stories) (story points voor effort, nieuwe waarde schatting in punten):

product owner value game: refinement

product owner value game: refinement

product owner value game: refinement on-going

product owner value game: refinement on-going

Na 3 sprints (en toen was het game over):

product owner value game: value delivered

product owner value game: value delivered

  • Sprint 1: oplevering van feature 9 (één user story 46) bleek een goede keuze (aanvankelijk Small ingeschat, uiteindelijk 13 story points, maar met een hoge waarde: 1630 waarde punten)
  • Sprint 2: oplevering van user story 31, 40 en 22 (totale waarde 1560)
  • Sprint 3: oplevering van user story 1, 42 en 39 (totale waarde 1330)
product owner value game: results

product owner value game: results

Opgeleverd:

  • 7 stories
  • Totaal effort: 46 story points
  • Totaal waarde: 4520 punten
  • Gemiddeld waarde / story point: ~98 punten

(statistieken om te vergelijken bij volgende uitvoeringen van het spel 😉

Wat zijn de learnings?

  • Het belang van het toekennen van een waarde aan items (en niet enkel ontwikkeling effort)
  • Het toekennen van waarde aan de hand van een schaal van punten)
  • Het afwegen tussen het verder verfijnen of het opleveren van items (enkel effectief opgeleverde functionaliteiten creëren waarde!)
  • De activiteit van refinement is niet gratis (dit kost capaciteit van het team)
  • Prioritisatie gebeurt niet enkel op basis van waarde, maar een combinatie van de verwachte waarde en benodigde inschattingen)
  • Als product owner moet je ook effectief lage waarde items durven weggooien 🙂

Mogelijke variatie op spel:

Een team dat speelt met kaartjes gegeven zonder een waarde schatting, en een team dat speelt met kaart met een waarde schatting. Op die manier zal met zeker het belang van waarde ondervinden.

Read more:

Game on!

getKanban3: some items deployed

getKanban: board game to learn and experience Kanban (software development)

getKanban is a board game, which enables you to learn and practice Kanban in software development.

Kanban

  • Kanban is Japanese. “Kan” translates visual and “ban” means card
  • Kanban is a process tool
  • Kanban works as a pull mechanism (as opposite to a push mechanism)
  • Kanban visualizes flow
  • Kanban limits work-in-progress
  • By limiting work-in-progress, bottlenecks in the flow will become visible

By visualizing bottlenecks, there’s an opportunity to improve the process flow (to remove the bottlenecks, to remove waste, and as a consequence, to better match capacity with demand in the different stages of the flow)

Kanban applies control by measuring lead and cycle times – by improving the flow you can improve those lead and cycle times, and therefore optimize the flow to get work at a higher rate through the flow.

Kanban originates from lean manufacturing. A kanban card is a message, it signals the depletion of goods (products, parts, inventory) to an upstream part of the process.

Conceptual diagram of a Kanban system Conceptual diagram of a Kanban system; http://files.iquijada.webnode.es/200000139-034270535c/Kanban4.png

When received, the kanban card triggers the production requests of those goods. Therefore, the consumption of goods drives the demand for more production of the needed goods – so kanban enables a demand-driven system (a pull system). A demand-driven systems aims to minimize (or even eliminate) inventory; just-in-time production; higher flow throughput, and therefore aims companies to become more production efficient. Lean manufacturing specifies a number of forms of wastes and origins of waste.

Kanban itself comprises of set of very simple rules, but (by years of application in lean manufacturing and almost a decade in software development) it has demonstrated its powerful abilities to trigger self-reflection, collaboration and process improvements. It has its roots in lean. Lean thinking’s pillars are respect for people and Kaizen.

The game

The game setup consists out of a board, a stack of cards (backlog items with a certain value and effort to complete for analysis, development and test), a number of works (analysts, developers, testers), and the necessary charts (financials, and Cumulative Flow Diagram).

When playing the game you quickly learn about the pull mechanism, the effect of limiting work-in-progress and use of the fast-track (expedite) lane and specific impediments (problems, interruptions …).

The start of the game is at day 9 of a project (the context is a web application development with a customer-subscription based revenue model) – so you enter the game with some items in progress. The game can be played in quick play (till day 15), standard mode (till day 21) and advanced mode (till day 24).

The initial state looks like this:

getKanban1: from left to right: blue indicates the backlog cards, black indicates the ready column, red indicates the analysis column, blue indicates the development column, green indicates the testing column

getKanban1: from left to right: blue indicates the backlog cards, black indicates the ready column, red indicates the analysis column, blue indicates the development column, green indicates the testing column

As you see, the work-in-progress limits are respected:

  • Maximum 4 cards (items) in the ready column (stage of the flow)
  • Maximum 2 cards in analysis
  • Maximum 4 cards in development
  • Maximum 3 cards in test
  • No maximum in ready to deploy
  • No maximum in deployed (which basically means “finished”)

Now it’s up to the team to evaluate the state of the board; the game is played as following:

Assign workers to the different phases (analysis, development, test) – the workers are represented by dice. The number you throw with the dice gives you the number of effort units you can do for a particular phase and you consume these on the items on that respective column on the board.

getKanban2: Arrows indicate the flow of items (via a pull from the right)

getKanban2: Arrows indicate the flow of items (via a pull from the right)

Items are pulled through the flow starting at the end of the flow (so from the far-right column: deployed). As you spent your effort points (dice points) on items you will subsequently pull items through the flow, but pay attention to respect the work-in-progress limits.

At the end of the day:

  • Read the event card (the event may be positive or negative)
  • Add the numbers of the Cumulative Flow Diagram (CFD)
  • Tick off end of the day

Cumulative Flow Diagram

Cumulative Flow Diagram example, the colored lines indicate the different stages in the flow

Cumulative Flow Diagram example, the colored lines indicate the different stages in the flow

Cumulative Flow Diagram is a tool used in queuing theory. It shows the evolution of the flow in its different stages and the queue of items being built up before each stage. It shows the size of the queue (vertical line) and the lead time (horizontal line). Lead time indicates the time from request till delivery. Cycle time starts when actual work begins on the request and when the item is ready for delivery.

Billing time

Every 3rth day (day 9, day 12 …) it’s billing time.

getKanban3: some items deployed

getKanban3: some items deployed

  • You deploy read-to-deploy items
  • You cash-in your newly earned user-subscriptions (newly deployed features attract new customers) (new subscriptions gained are written on the back of each card)
  • You replenish the ready column with items from the backlog (respecting the work-in-progress limit) (because only every 3 days the product owner is available)

Expedite lane

The expedite lane is used to fast-track an item to delivery.

getKanban4: the expidite (fast lane) indicated in red, this lane has its own WIP limit

getKanban4: the expidite (fast lane) indicated in red, this lane has its own WIP limit

  • This lane has a work-in-progress limit of its own – an item in this lane does not count for the regular column work-in-progress limits.
  • Only items with a fixed delivery date flow through this lane
  • Delivering such an item too late results in a fine

!!! SPOILER ALERT !!!

You have several manipulations at hand:

  • Assign the workers (dices) – for example you can decide to assign a work outside his speciality (e.g. a developer to analysis or test); as in real life, a person working outside his expertise will be less productive.
  • Decide upon the number of items in the flow (the work-in-progress limit is an upper limit) (take care you cannot as such change the limit itself)
  • Prioritize the items in the backlog
  • Look at the effort required to complete of each item
  • Look at your metrics and use this data
  • And as such limit the work in progress, try to avoid bottlenecks, try to reduce lead times
  • Decide to deliver any fixed-delivery date items or not, if yes, decide the right time to handle these

Blocker

getKanban5: blocker indicated in red

getKanban5: blocker indicated in red

A blocker might occur (via an event card). Obviously this will influence the flow. For example, it might break the work-in-progress limit (because a team has decided to do so). It might black a specific item (in the form of a block that must be resolved first).

More reading (more spoilers): Playing getKanban with an experienced team

Game over 🙂

getKanban6: end score

getKanban6: end score

Our gratitude to @AgileConsortium for hosting this event and @PatrickSteyaert for guiding the game.

Game on!

Kanban for skeptics

Book review and summary: Kanban for skeptics

Kanban for skeptics” is a book describing the purpose of Kanban and withdrawing any arguments against or any misconceptions. In general, folks regularly have misunderstandings regarding concepts, frameworks, and methodologies… in that perspective I like the intention of the book.

Some might say the book is not a traditional explanation to a subject, which is the case – on the other hand that was not the intention of the book. If you’re new to Kanban, I do think you learn quite a lot by reading this book. I also think the arguments and explanations given are quite useful and make sense (at least to me). It does show the power of Kanban as a process improvement and change management tool.

In summary and my key take-away: Kanban is in essence a change management approach and vehicle (I don’t like saying a “tool”).

Kanban leads to establishing a continuous flow based on a pull system, by limiting the number of items in progress and subsequently forcing an organization to implement sustainable process improvements. Limiting the work-in-progress surfaces the obstacles in a current progress (cf. the powerful lean metaphor of rocks in the lake).

The goal of Kanban is to maximize end-to-end flow efficiency by removing bottlenecks, redesigning the process flow when necessary and focusing on delivering work fully completed. The aim is to make the flow well-balanced, so that the stages in the flow are close to the defined throughput limits. Control is exercised by an approach of monitoring and measuring throughput times (lead and cycle times) (and not estimations). Delivering steady business value occurs when a continuous flow is in place that consistently delivers work items finished on a regular basis at a speed that matches the needs of the organization.

I’ve noticed clear similarities between Kanban with other agile frameworks (i.e. Scrum):

  • The goal is to deliver business value, based upon customer demand (in Scrum: value is managed by the product owner)
  • The team pulls work from a single source: a list of work items (i.e. a backlog or queue).
  • One defines a set of rules to define when an item is considered ready to be pulled into the flow (definition of ready): in Kanban: you can set the rules per stage of the workflow
  • Transparent way of tracking progress
  • Lean rocks-and-lake principle: impediments and obstacles in processes will become painfully visible – this triggers the need for change and facilitates organizational change
  • It leads to better processes, by incorporating feedback and by building upon a momentum to improve a process (as in a Scrum’s retrospective)
  • It leads to better collaboration in an organization (if you want to improve, you’ll need to break out of your organizational unit/silo) (Scrum: resolving organizational impediments + cross-functional team work)
  • Kanban limits work-in-progress by process step, by lane. Scrum limits work-in-progress by sprint.

I’ve noticed differences Kanban with other agile frameworks (i.e. Scrum):

  • Kanban works with measurements – no estimates (note: in agile there is a stream of thinking to work without estimations: on the contrary, the Scrum guide does specify that a product backlog item must have an estimate)
  • A flow in Kanban is measured by lead / cycle times; in Scrum you measure by done work compared to planned work (velocity of a team)
  • Kanban is less prescriptive compared to Scrum (not that Scrum is very prescriptive, in my humble opinion; at least compared with traditionally project/process management methodologies…)
  • Kanban focuses on fully done work (due to the work-in-progress limits); in Scrum the teams defines itself their meaning of work done (note in Scrum the goal is to deliver actual working software at the end of the sprint)
  • Kanban starts from the existing process; Scrum does pre-scribe a specific process with specific roles and responsibilities. Kanban does not require you to change your organizational way of working to get started.

I’ve noticed that you can incorporate many agile techniques into Kanban – although Kanban does not prescribe it – this is optional and depending what fits the needs and the context:

  • Prioritizing the input queue (Scrum: product backlog) – this is a good practice as it enforces the stakeholders on focusing on the value of items in the queue
  • Planning with relative estimates (estimate by comparing items)
  • Planning by having relatively well-sized features (INVEST)
  • Introduce iterations > regular cadence (iteration as a heartbeat)
  • Daily scrum > team coordination
  • Cross-functional team (instead of silo-teams) – by defacto in Scrum
  • Build a minimal viable product (to start learning as fast as possible and to improve your product based upon real user feedback) – this is a lean concept; but anyhow considered a recommended practice for product development

Any choice of adding a particular practice is situation and context dependent and must be done with consideration.

All this confirms for me that Agile and Lean are blending philosophies.

The questions and reflections I had after reading this book:

  1. To enforce work-in-progress limits in Scrum (when necessary)
  2. Some general recommendations how to reach a steady continuous flow?
  3. When precisely to adjust the work-in-progress limits?

More reading

Scrum and Kanban: Making the Most of Both
Simple, short and to the point comparison of Scrum and Kanban

Small notes: since the writing of this book, some minor, but important modifications have been done to Scrum:
– a team forecasts the amount of work it can do in the next sprint (it does not commit  anymore)
– a burndown (or burnup) chart has become optional

Scrumban book
Book elaborating how to use Kanban on top of Scrum

quote unquote

Slacker manifesto

“As we all know, a sustainable pace is important for the quality of the end product and the health of the team. Some slack is needed to get your senses together or reflect on the future of the product which allows the team to take better decisions during the course of delivery.”

From: “Kanban for skeptics“, by Nick Oostvogels.

This made me think about the importance of slack time – it was taken to a higher level via the Slacker Manifesto. It’s basically about how we are part of projects where people are kept busy by having a queue of items to do. Managers think that people must be 100% busy otherwise they’re not valuable. But queues are a true enemy of flow. To move toward flow it is necessary to reduce batch size, cycle time, delay, WIP, and other wastes (read the lean primer). And as such 100% people “resource” utilization is a myth.

Therefore:

The Slacker Manifesto:

“On occasions we do nothing. Or something different. Or something else.

Because this means that our teams are more effective.

It also means that we are freaking awesome.”

If you’d like to sign, go here.

XP Days Benelux

Mini XP Days Benelux 2015

XP Days Benelux is een jaarlijkse conferentie over XP, Agile, Lean en gaat afwisselend door in België en Nederlands. Er is per jaar een volledige editie (Maxi XP Days)  en een mini editie (Mini XP Days) die het beste van de sessies van de vorige Maxi terug uitbrengt.

XP Days Benelux

XP Days Benelux

Mini XP Days Benelux 2015 programme

Mini XP Days Benelux 2015 programme

Dit is een verslag van 4 sessies die ik bijgewoond heb tijdens de Mini XP Days Benelux 2015.

Product owner game (door Paul Kuijten)

(Educatieve) games bieden het voordeel dat je zaken (details) van de realiteit kan abstraheren en je kunt focussen op een concrete leerervaring. Gefaciliteerde workshops en games bieden een mogelijkheid om effectief iets te gronde te leren (iets dat ‘blijft’ hangen) door zelf dingen uit te proberen.

Het spel simuleert de rol van de product owner. Het is een kaartspel (de kaarten stellen de backlog items voor) en de dobbelsteen bepaalt wanneer het spel ten einde is (wanneer de ‘shipping’ gebeurt en dus toont aan hoeveel waarde er gecreëerd is totdat moment).

De doelstelling van het spel is om de rol en verantwoordelijkheden van de product owner beter te leren kennen, en om de balans tussen ‘refinement’ (het verder analyseren van items) en ‘oplevering’ (en dus creatie van waarde) te ontdekken.

Praktisch: features in de backlog hebben een effort inschatting en een bepaling van de verwachtte waarden. Bij refinement tot op user story niveau, krijg je een nieuwe effort inschatting en waarde (zoals het hoort te zijn). Het spel (de sprints) kan abrupt eindigen – door het lot van de dobbelsteen.

Het is spel vond ik heel leuk en is een aanrader om te spelen met product owners, maar ook teams of andere stakeholders om het belang van een backlog en refinement te leren kennen.

De abstractie is hier dat we ons niet bezighouden met het detail (complexiteit) van effort en waarde bepaling, deze zijn gegeven. Het spel illustreert duidelijk de verschillende factoren die meespelen tijdens het rangschikken van een backlog.

Link naar het artikel op InfoQ: Playing the Product Owner Value Game

Product owner game (2)

Product owner game (2)

Product owner game (1)

Product owner game (1)

Product owner game (4)

Product owner game (4)

Product owner game (3)

Product owner game (3)

Visual facilitation (door Jef Cumps)

Visuele facilitatie is het gebruik van visuals en drawings / sketches tijdens workshops / besprekingen. Het incorporeren van visuals is een belangrijke troef om workshops / trainingen / besprekingen interactief te maken en de uitkomst te verhogen. Bij gebruik van visuals en het maken van visuals op maat tijdens een workshop kan de trainer/facilitator/spreker inspelen op input en is de inbreng, de betrokkenheid van de deelnemers veel groter.

Tijdens deze workshop beoefenden we de basis van sketching (schrijven van woorden; contouren, connectoren, frames, etc)

Nadruk werd gelegd op gebruik van kwalitatieve materialen (stiften) en papier.

Oefenen is belangrijk, dus koop je enkele stiften en flipchart papier en ga aan het werk (ik doe dat alvast, ook al na mijn 1e workshop ervaring met Mara Callaert)

Visual facilitation (4)

Visual facilitation (4)

Visual facilitation (3)

Visual facilitation (3)

Visual facilitation (1)

Visual facilitation (1)

Visual facilitation (2)

Visual facilitation (2)

Desirements on the fly (door Per M. Beining)

Per M. Beining presenteerde verschillende tools & technieken voor de flow van ‘business idea’ tot implementatie en roll-out. Dit was voor mij een interessant overzicht en een goede tip om bepaalde technieken, tools te leren of op te frissen. De lijst was niet exhaustief, maar zeker interessant! Per werkt in tussentijd ook blijkbaar aan een boek, dus feedback kan je hem altijd geven.

De besproken tools in deze presentatie (in geen specifieke volgorde):

Desirements on the fly

Desirements on the fly

Multi-level feedback cycle (door Kris Philippaerts)

Agile (Scrum) is gebaseerd op empirische controle – een continue cyclus van plan/do/check/act (inspectie en adaptatie). Dit betekent dat er veel verschillende feedback cycli aanwezig zijn, meer dan dat men op het eerste zicht erkent. De oefening bestaat er uit om voor de verschillende feedback cycli te achterhalen wat er gebeurt: tijdens welk ritueel (event, maar niet enkel ”meetings”), wat is de output (het artefact), wie is degene die het creëert.

En dit voor lange-termijn visie, business requirements, technische realisatie, planning en budget, en team dynamiek. Het doel van de oefening is ook te bekijken welke van deze feedback cycli expliciet aanwezig zijn in een framework zoals Scrum en welke impliciet. Belangrijk is om te realiseren dat deze feedback cycli bestaan en men vb. tijdens review en retrospectives rekening houdt met het bestaan ervan (of deze onderscheidt) en vervolgens de output naar de correcte stakeholders stuurt en opvolgt.

Link naar het artikel op InfoQ: Feedback Cycles in Scrum

Scrum feedback cycles team team dynamics

Scrum feedback cycles team team dynamics

Scrum feedback cycles technical realisation

Scrum feedback cycles technical realisation

Scrum feedback cycles planning and budget

Scrum feedback cycles planning and budget

Scrum feedback cycles long-term vision

Scrum feedback cycles long-term vision

Scrum feedback cycles business requirements

Scrum feedback cycles business requirements