Accurate Forecasting Without Estimation

Often the team or somebody in the role of product owner gets either the question ‘When will it be finished?’ or ‘What will be finished at <some future date>?’ and some forecasting is necessary to answer the question.

This blog shows an alternative way of forecasting that is based on empirical data and skips estimation altogether. In a follow-up blog I will address the ordening of the backlog of items.

Read more →

More Effective Team With Less Efficient Workers!

Methods based on Agile and the Kanban Method both stimulate collaboration to achieve focus and flow. In practice this is often challenged by teams with specialists who have a tendency to maximize the utilization of the specialists.

So, is a team with a focus to finish work more effective than a team with focus on efficiently using expertise?Read more →

Versnel je team met Scrumban!

Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende 'velocity' laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg hieruit door een structuur en principes te bieden.

Veel voorkomende symptomen

In de praktijk kom ik het volgende veel tegen:

  • herhaaldelijk missen van de sprint commitments,
  • het hebben van 2 Definition of Dones,
  • een velocity die over sprints heen hetzelfde blijft,
  • het blijven sleutelen aan het proces zonder zichtbare verbetering,
  • 'deployment' user stories, of 'user acceptance testing' user stories.

Het probleem met het 'snel' repareren van deze symptomen is dat als je de eigenlijke oorzaak niet goed genoeg onderzoekt en deze niet wegneemt, het symptoom in een andere vorm terugkomt. Het komt dat terug maar in een andere vorm en herken je het niet zo snel meer.

Om te weten hoe de Kanban Methode hierbij kan helpen, duiken we een beetje dieper in Kanban.

Kanban Methode principes

De 4 principes van de Kanban Methode zijn:

  1. Neem het huidige proces als startpunt,
  2. Respecteer de huidige rollen en verantwoordelijkheden,
  3. Spreek met elkaar af geleidelijke verbeteringen na te streven,
  4. Moedig leiderschap aan op alle nivo's.

Juist vanwege de eerste 2 punten maakt dat de Kanban Methode uitstekend is toe te passen op Scrum teams: hun huidige manier van scrum doen, is het startpunt!

Met deze principes weten we wel dat het toe te passen is op scrum teams, maar nog niet 'hoe'.

Aan de slag met Scrumban

In de praktijk merk ik vooral dat:

  • het doel of purpose van het team niet helder is voor hen,
  • sterke focus op het 'eigen' werk,
  • een backlog die bestaat uit verschillende soorten werk.

Purpose. Een van de eerste dingen is dat om de focus op juiste dingen er weer in te brengen. Dit doe ik dan door samen met het team het purpose te achterhalen. Voor wie doen we het en wat zijn de behoeften van de klant? Hoe herkennen we dit? Maak het meetbaar. Dit maakt het makkelijker te bepalen hoe we het nu doen en of dit al voldoende is of juist niet.

Soorten werk. Waar komt het werk vandaan? Hoe komt het aan bij het team? Aan wie levert het team het op? Met wat voor regelmaat: ineens, met pieken, via een backlog, terugkerend werk, etc. Wat zijn de kwaliteitseisen en verwachtingen?

Focus op het geheel. Als de purpose helder is, breng ik met het team de keten waar ze onderdeel van uitmaken in kaart. Van begin tot in productie. Hier kun je ook prima afhankelijkheden op andere teams en partijen kwijt. Ook maakt dit transparant dat het doel is dingen in productie te krijgen.

Metrics. In ieder geval beginnen met het meten van 3 dingen:

  1. gemiddelde doorlooptijd per soort werk,
  2. hoe vaak komen verschillende doorlooptijden voor?
  3. hoeveelheid werk dat er in de keten tegelijk onderhanden is.

Met deze informatie bepaal je een eerste verbeteractie met het team waarbij je ook een link legt naar de purpose; je wilt dat deze er beter van wordt.

Hoe pak je het aan? Een stappenplan

Wat hiervoor beschreven is, zijn de eerste stappen in wat bij de Kanban Methode onder STATIK wordt verstaan. STATIK staat voor 'Systems Thinking Approach to Introducing Kanban'. Bij sommige stappen sta je wat langer of korter stil dan bij andere stappen.

De aanpak bestaat erin met het team de volgende stappen te doorlopen:

  1. Doel of dienst van het team: wat is de identiteit van het team?
  2. Onderzoek bronnen van ontevredenheid bij klanten, gebruikers en het team zelf,
  3. Analyseer de vraag van de klant en de mogelijkheden van het team,
  4. Wat voor werk komt er op het team af? Waar gaat het naar toe? Wat zijn de verwachtingen ten aanzien van kwaliteit en snelheid?
  5. Breng in kaart wat er daarnaar met dit werk gebeurt,
  6. Kijk naar de risicoprofielen van dit werk,
  7. Ontwerp het kanbansysteem (met bord)
  8. Doe het!

Met name de eerste 2 stappen zorgen ervoor dat de veranderingen altijd een verbetering van de dienst zullen zijn, of op z'n minst de verwachtingen hebben deze te verbeteren.

Patronen.....

Tot nu toe heb ik een algemene aanpak beschreven die in de praktijk werkt. Voorbeelden hiervan zullen in komende blogs verder aan bod komen.

Backlog ordering done right!

Various methods exist for helping product owners to decide which backlog item to start first. That this pays off to do so (more or less) right has been shown in blogs of Maurits Rijk and Jeff Sutherland.

These approaches to ordering backlog items all assume that items once picked up by the team are finished according to the motto: 'Stop starting, start finishing'. An example of a well-known algorithm for ordering is Weighted Shortest Job First (WSJF).

For items that may be interrupted, this results not in the best scheduling possible. Items that usually are interrupted by other items include story map slices, (large) epics, themes, Marketable Features and possibly more.

In this blog I'll show what scheduling is more optimal and how it works.

Read more →

Demonstration of the Exactness of Little's Law

Day 18

Little's Law is a powerful tool that relates the amount the work a team is doing and the average lead time of each work item. Basically there are two main applications involving either 1) the input rate of work entering the team, or 2) the throughput of work completed.

In previous posts (Applying Little's Law in agile gamesWhy Little's law works...always) I already explained that Little's Law is exact and hardly has any assumptions, other than work entering the team (or system).

This post demonstrates this by calculating Little Law at every project day while playing GetKanban.
Read more →

The Business Support Team Pattern

Lately I've encountered several teams that organize their work using Agile methods and they all exhibit a similar pattern. Teams (or actually the work) having such work patterns I call Business Support Teams. This type of team usually is responsible for operating the application, supporting the business in using the application, and developing new features on top of the (usually third party) application,

The nature of the work may be plannable or highly ad hoc, e.g. production incidents and/or urgent requests from the business. In practice I notice that the more ad hoc type of work the team has to deal with, the more they are struggling with approaches based on a single backlog of work.

In this post I'll show a set-up using boards and agreements that works for these type of teams very nicely.

Read more →

Dancing with GetKanban (Using POLCA)

Very recently POLCA got some attention on twitter. The potential and application of POLCA to knowledge work I explained in my blog 'Squeeze more out of kanban with POLCA!' [Rij11] of 4 years ago.

In this blog the GetKanban [GetKanban] game is played by following the the initial 'standard' rules for handling Work in Progress (WiP) limits and by changing the rules of the game inspired by POLCA (See [POLCA]).

The results show an equal throughput between POLCA and non-overlapping WiP limits, with smaller inventory size in the case of POLCA way of approaching WiP limits.

Read more →

Questions with a license to kill in the Sprint Review

A team I had been coaching held a sprint review to show what they had achieved and to get feedback from stakeholders. Among these were managers, other teams, enterprise architects, and other interested colleagues.

In the past sprint they had built and realized the automation of part of the Continuous Delivery pipeline. This was quite a big achievement for the team. The organization had been struggling for quite some time to get this working, and the team had realized this in a couple of sprints!

Team - "Anyone has questions or wants to know more?"
Stakeholder - "Thanks for the demo. How does the shown solution deal with 'X'?"

The team replied with a straightforward answer to this relatively simple question.

Stakeholder - "I have more questions related to the presented solution and concerns on corporate level, but this is probably not the good time to go into details."

What just happened and how did the team respond?

Read more →

Why 'Why' Is Everything

The 'Why' part is perhaps the most important aspect of a user story. This links to the sprint goal which links ultimately to the product vision and organisation's vision.

Lately, I got reminded of the very truth of this statement. Read more →