comment 0

Scrum anti-patterns

Jammergenoeg zijn er veel Scrum anti-patterns. Hoe vroeger men deze ontdekt, des te beter.

Ik probeer hieronder een aantal anti-patterns te documenteren. Dit zijn voorbeelden ervaren in projecten.

1. Anti-pattern: “we moeten de scope van de sprints plannen”

En hiermee werd dus bedoeld: de scope van alle (of x aantal) sprints zullen we plannen (op voorhand).

FOUT!

Een sprint is een iteratie met een vaste duurtijd. Aan het begin van elke sprint (iteratie) plannen we de sprint en bepalen we hoe we deze items zullen realiseren. De backlog (geprioriteerde lijst van items te realiseren) bevat verfijnde inschattingen voor de items bovenaan. Gegeven deze inschattingen (en eventueel gegeven de snelheid van het team) zal het team zich engageren om x items van de backlog te realiseren in de volgende sprint. Dit is de scope van de eerstvolgende sprint.

Dus niet:

  • op voorhand plannen hoeveel sprints we zullen uitvoeren
  • op voorhand plannen wat de inhoud van deze sprints zal zijn

2. Anti-pattern: “1 (lange) sprint”

Een reëel voorbeeld. De ontwikkeling wordt uitgevoerd in sprints, met een duurtijd van x weken, maar er wordt maar 1 sprint gepland.

FOUT!

De organisatie van Scrum is dat men net iteratief en incrementeel werkt. Het voordeel van agile projecten is dat de gerealiseerde meerwaarde vroeg in het project zichtbaar wordt. Een incrementele aanpak zorgt ervoor dat men die meerwaarde kan valideren, en gebruiken om de business case te bevestigen. Uiteraard dient men daarvoor op een incrementele wijze te werken, met enkele iteraties. Indien van toepassing en gewenst kan bepalen om sprints van korte duur (bv 1 week), met de intentie van meerdere sprints te kunnen plannen. Lees hier een artikel over de gepaste duurtijd van sprints voor een project (dit is afhankelijk van het project, en dient men zorgvuldig te kiezen). Let wel, het is de product owner die beslist wanneer het product ‘afgewerkt’ is, en daarmee het project zicht beëindigt. Indien de product owner oordeelt dat na 1 sprint het product leverbaar is (voor productie), dat kan dit zonder enig probleem.

Dus niet:

  • op voorhand maximum 1 sprint plannen (met een te lange duurtijd)

3. Anti-pattern: “we hebben geen inschattingen voor deze feature, dit betreft een change request”

Een reëel voorbeeld. De project manager acht de gevraagde feature niet in scope, maar oordeelt dat dit een change betreft.

FOUT!

  1. Een aanvraag voor een nieuwe feature, of een aanpassing voor een bestaande feature wordt opgenomen in de product backlog, en de product owner geeft deze de gewenste prioriteit.
  2. Dit item wordt niet opgenomen in de huidige sprint.
  3. De product backlog wordt verfijnd en het bewuste item krijgt een schatting (om de complexiteit te kennen)
  4. Bij de planning van de volgende sprint, kan het team het item opnemen in de scope van de te plannen sprint – en vervolgens zal het team gedetailleerde effort inschattingen geven.
  5. Het toevoegen van dit item (de “change”) kan uiteraard zijn gevolg hebben op het uitvoeren van andere items. Dit gebeurt door een natuurlijke selectie, doordat de product backlog steeds een geactualiseerd beeld geeft van de uit te voeren items volgens correcte business prioriteiten.

Dus niet:

  • Beweren dat een item een change betreft, omdat er geen schattingen voor bestaan
  • Op voorhand (al) te ontwikkelen features laten inschatten door het team
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s