Daily Scrum

What is the Daily Scrum for?

The daily scrum / daily stand-up / daily huddle. Oh well.

The good questions are:
1. What have you done yesterday that contributes to reach the sprint goal?
2. What will you do today that contributes to reach the sprint goal?
3. Do you encounter any impediments/issues/problems that prevent you from reaching the sprint goal?

The habit of each person listing all the things he has done yesterday, and what he will do today is quite besides the point. The daily scrum is not a status meeting, it’s not a reporting meeting. In essence people should say what and how they’re progressing towards the sprint goal, and think and act as team how to plan their work together… for the next 24 hours. So yes, it’s a planning meeting, for the shortest iteration: the next 24 hours.

There are many “anti-patterns” regarding the daily scrum:
– Talking to the board, and not to the people
– No board at all
– Talking only to the scrum master
– Not expressing the progress of what your working on
– Having no sprint goals (so nothing to measure against)
– Talking too much, speaking about sprint goal – irrelevant stuff (for example discussing tasks in detail)
– Discussing problems and solutions in great detail > these should be taken offline, by preference the discussion continues in subgroups (with the relevant people), directly after the daily scrum (when the topic is still hot).

Displaying a sprint planning using a Gantt chart

Displaying a sprint planning using a Gantt chart

Gantt charts have been invented and developed by Henry Gantt in the 1910s. These charts became more widely used by the US military during the Word War I. Project managers typically use Gantt charts to visualize the project planning, it visually shows the start and end date of tasks, plus any dependencies. A Gantt chart greatly visualizes how project phases or tasks are to be executed in consecutive order – of course certain tasks or group of tasks can be executed in parallel.

My eyes hurt when I see project manager visualizing an incremental and iterative project using a Gant chart.

It looks like this:

gant chart

What do we see?

  • Iterations have a fixed duration (by definition)
  • When iteration A ends, iteration B starts (by definition)
  • The schedule pre-defines X number of iterations (unknown by definition – unless you need to meet a fixed deadline)

It gets worse when the project pre-defines the scope of each iteration – clearly not the intention. The team (together with the product owner) defines and selects the content of the iteration (sprint) during the sprint planning; the team will define the tasks to achieve and construct those items.

I believe the common preference by the community and teams is to visualize tasks and dependency using a visual board (on all levels: team, release …) and burn-down charts as information radar to communicate progress.

I stumbled upon this article entitled “How to use Gantt charts for your agile project”.

Do you use Gant charts in your projects?

Wat voornamelijk niet doen bij het vergroten van agile teams

How NOT to scale agile

“Scaling” agile betreft het schalen van agile groter dan het team niveau.

Tiago Garcez @tcgarcez gaf hierover een interessante sessie op #atbru 2014. Slides: “How NOT to scale agile”. Deze post is gebaseerd op zijn sessie.

Er werden redenen aangehaald dat agile niet zomaar geschaald hoeft te worden; en dat een aantal  praktijken in organisaties haaks staan op agile waarden.

1. Projecten

Projecten zijn per definitie eindig. Echter, verandering en transformatie naar een agile manier van denken en werken is niet eindig.

2. Resource planning

Resource planning optimaliseert het gebruik van resources. Typisch in een organisatie betekent dit dat mensen verschillende activiteiten uitvoeren voor meerdere projecten. Individuen worden ook vaak opnieuw ingepland op andere projecten, en in andere teams ondergebracht. Dit is nefast voor de productiviteit en de samenhorigheid van een team. Een medewerker in deze omstandigheden heeft last van context-switching en ziet niet het resultaat van zijn werk.

Bottom-line: investeer in teams en hou goed werkende teams stabiel.

3. Focus niet op efficiëntie

Maar focus op effectiviteit. Efficiëntie betekent optimalisatie (van resources). “Een resource die niet werkt is niet efficiënt“. Wat we nodig hebben zijn individuen die effectief zijn in hun activiteiten. Het over focussen op efficiëntie leidt in middelgrote tot grote organisaties tot nefaste effecten waarbij medewerkers niet de kans/tijd krijgen om zichzelf te ontplooien of om goede werkrelaties op te bouwen met collega’s.

4. Focus op de eindgebruiker

Vaak zien we projecten heel sterk focussen op de (interne) klant, en vergeet men wie de feitelijke eindgebruiker is. Met een juiste aanpak (lean UX, incrementele persona’s, herhaalde testing met eindgebruikers, …) en technieken kunnen we meer zeker zijn dat hetgeen wat we bouwen effectief nuttig zal zijn voor de eindgebruiker van het product (en niet enkel de interne klant: bv. het marketing departement, …).

5. Schaal geen incompetenties

De basis is belangrijk: get the basics right. Slechts als een team agile ademt, kan je bekijken hoe je kan uitvergroten over meerdere teams heen. Alle agile waarden zijn belangrijk, en niet enkel dat. Denk niet dat goede engineering praktijken er niet meer toe te doen. Expertise, vakmanschap en een agile samenwerking zijn de basis voor productiviteit en resultaat. Als je dit bereikt hebt in meerdere teams, kan je kijken hoe je dit kan schalen over de teams heen.

6. Geen traditionele carrière paden

Organisaties focussen heel erg op een carrière pad dat start bij een beginnende functie en vervolgens het individu promoveert tot een ‘hogere’ functie. Vb. van junior ontwikkelaar, naar senior ontwikkelaar, naar team manager, naar project manager. Of van business analist, naar manager. Van junior associate, naar senior associate, naar partner. What’s in a name?

Laat mensen doen waar ze goed in zijn. Verplicht hen niet om een bepaald carrière pad te bewandelen indien met ‘hogerop’ wil geraken zowel qua verloning als aanzien bij een hogere anciënniteit. Een ontwikkelaar die zijn werk met passie en expertise doet, kan dit met passie zijn hele carrière beoefenen – en waardeer hem daarvoor met een gepaste remuneratie. Idem dito voor alle andere rollen. Hou een carrière pad gezond en op maat van het individu.

Persoonlijk hou ik niet van senior functies. Senior kan duiden op de leeftijd, maar het gaat hem voornamelijk om de ervaring, kennis en aanpak.

7. Schaal geen processen

Schaal geen processen op een blindelingse manier. Het op grote schaal toepassen van een proces (zoals Scrum) zonder de agile waarden zal leiden tot een heel mechanische manier van werken. Investeer eerst in de teams, hun cultuur, hun doelstelling en het onderling vertrouwen.

8. Schaal niet indien niet nodig

Bekijk of dat het toepassen van agile op grote schaal onontbeerlijk is. Hebben we meerdere agile teams die succesvol en correct werken? Wat is de huidige norm van agile projecten? Kunnen we succesvol zijn in het realiseren van meerdere agile teams? Is het überhaupt nodig voor ons om teams te schalen?

9. Stop outsourcing omwille van foute redenen

Mijn suggestie: stop outsourcing omwille van foute redenen. Organisaties gaan vaak de mist in als men al hun activiteiten wilt outsourcen. Mijn inziens het pijnlijkste voorbeeld hiervan in het outsourcen van research. Een organisatie heeft er alle baat bij om research intern te verwezenlijken: behoud de kennis, train mensen in de technieken en stop niet met het (markt)onderzoek na oplevering van de studie.

Do not outsourch your research.

Scrum en scaling

Opinies verschillen. Huidig is over het scalen van Scrum volgende gedefinieerd:

  • Scrum.org: Scaling Scrum
  • SAFe (Scaled Agile Framework)
  • LeSS (Large-Scale Scrum)
  • Andere frameworks…?