Browsed by
Category: Agile

Heeft plannen nog wel zin?

Heeft plannen nog wel zin?

PlanEen korte video waarin Rini van Solingen de vraag stelt of het maken van een planning nog wel zin heeft. De wereld gaat zo snel dat we het niet kunnen plannen (wat we wel altijd dachten), maar

  • gebruikers weten vaak niet wat ze willen
  • ontwikkelaars weten niet hoe ze het moeten maken
  • we gaan er van uit dat er niets veranderd

Bekijk hieronder de video en je zult jezelf afvragen: Heeft plannen nog wel zin?

De zeven grootste tactische fouten in de praktijk bij de invoering van Scrum (en wat er aan te doen)

De zeven grootste tactische fouten in de praktijk bij de invoering van Scrum (en wat er aan te doen)

Rini van SolingenOp de TechDays 2014 heeft Rini van Solingen een zeer goede sessie gehouden over Scrum en de meeste gemaakte fouten bij de invoering:

Het lijkt wel of iedereen tegenwoordig aan het ‘Scrummen’ is. Vrijwel elk softwareteam heeft Scrum al opgepakt of

doet dit binnenkort. De belangrijkste reden voor de populariteit van Scrum is dat het een fundamentele oplossing biedt voor het telkens weer uitlopen van projecten en het ernstig overschrijden van budgetten.

 

Scrum lost dit probleem namelijk op aan de bron: via korte cycli sturen op een werkend product met de maximale waarde. Dat biedt tevens de kans om flexibel (Agile) te zijn. Vandaar dat iedereen ook zo enthousiast is over Scrum: directe sturing op concrete en haalbare resultaten. Wie wil dat nou niet? Maar werken met Scrum vraagt om een revolutie in de manier van werken, door nieuwe rollen, nieuwe processen, nieuwe documenten en nieuwe afspraken.

 

Scrum goed toepassen is daarom niet eenvoudig. Dat komt doordat de toepassing van Scrum een interventie is die de hele systematiek van werken op zijn kop zet en dus ook impact heeft op heel veel plaatsen, personen, ketens, processen, en dergelijke. In deze break-out sessie worden de zeven meest gemaakte tactische fouten behandeld en geïllustreerd aan de hand van échte voorbeelden uit de praktijk. Daarnaast worden oplossingen gegeven om deze fouten te herstellen dan wel te voorkomen.

Bekijk hieronder de video van deze sessie:

 

Agile programming for your family

Agile programming for your family

Bruce Feiler heeft een radicaal idee: Om om te gaan met de stress van het moderne gezinsleven, go Agile!. Geïnspireerd door agile software programmering, introduceert Feiler familie gedragingen die flexibiliteit, bottom-up idee stromen, constante feedback en verantwoording bevorderen. Een opmerkelijk detail: Kinderen kiezen hun eigen straffen.

Bruce Feiler

Scrum voor het onderwijs

Scrum voor het onderwijs

Dat Scrum niet alleen werkt voor het bedrijfsleven, maar ook voor het onderwijs, toont het eduScrum project van het Ashram College in Alphen aan den Rijn. Onderstaande video laat de bevindingen horen van de leerlingen die volgens Scrum methode werken.

eduScrum

Hyperproductieve Scrum-teams

Hyperproductieve Scrum-teams

Hyperproductieve Scrum-teamsIn de Automatisering Gids van 31 januari staat een goed artikel geschreven door Charlotte Bendermacher, Vikram Kapoor en Rini van Solingen van Prowareness over Scrum. Op de site van scrum.nl is het artikel te downloaden als pdf. Het artikel beschrijft de vier randvoorwaarden voor het realiseren van hyperproductieve Scrum-teams. Hieronder deze vier voorwaarden:

1. Maak de meeste waarde eerst

Lever in een sprint alleen die software die de hoogste waarde heeft. Daartoe schrijft Scrum een enkele ‘product owner’ voor die deze waarde kent en keuzes maakt. Hierdoor zijn teams eerder klaar en kunnen sneller met ander werk starten. Dit zal de productiviteit van veel teams al snel verdubbelen. In de praktijk zien we echter veel organisaties worstelen met deze rol van product owner. In veel gevallen is er geen product owner of deze persoon heeft veel te weinig tijd of mag geen keuzes maken. Door niet effectief op waarde te prioriteren wordt de eerste stap naar hyperproductiviteit dan niet gerealiseerd.

2. Doe alleen haalbaar werk

Aangezien Scrum-teams elke twee weken werkende software moeten opleveren, is het noodzakelijk dat ze alleen werk oppakken dat ook echt afgemaakt kan worden. Het team werkt alleen aan dat wat af kan komen en veel waarde heeft. Hierdoor wordt de productiviteit al snel twee keer zo hoog. Om dit te realiseren werken Scrum-teams met een lijst van criteria waarop staat of werk helder genoeg is. Deze lijst noemt men de ‘Definition-of-Ready’ (DoR).
In de praktijk zien we echter veel teams grote delen werk oppakken dat nog niet helder is. Veel teams werken niet met een Definition-of-Ready of houden zich er niet aan. De kans dat de software aan het eind van elke sprint ‘af’ is, wordt daardoor veel kleiner. De tweede stap om hyperproductiviteit te realiseren wordt hierdoor niet ingevuld.

3. Maak werk echt af

Zorg dat elke sprint werkende en geteste software oplevert die naar eindgebruikers toe kan. Rework wordt hierdoor voorkomen, bugs worden veel sneller gevonden en opgelost, en bijsturen wordt mogelijk. Tegelijkertijd is het een behoorlijke ingreep voor ontwikkelteams. Immers, testen mag niet worden uitgesteld maar moet binnen elke sprint worden gedaan. Dat vraagt om een andere test-mindset. Functionele testautomatisering en waar mogelijk automatische integratie zijn nodig. Om software ook echt af te maken, werken Scrum-teams met een lijst van criteria waarop staat wanneer software echt ‘af’ is. Deze lijst heet de ‘Definition-of-Done’ (DoD).
In de praktijk zien we veel teams met Scrum werken, maar niet elke sprint levert werkende en geteste software op. Er is geen Definition-of-Done of zij wordt niet nagekomen. De derde stap naar hyperproductiviteit wordt daardoor genegeerd.

4. Word steeds beter

Het idee van Scrum is om elke sprint te leren en daardoor steeds beter te worden. Stabiele teams die elke sprint beter worden, zorgen minimaal voor een productiviteitsverdubbeling. Veel organisaties vinden het echter erg lastig om teams stabiel te houden. Het frequent wisselen van mensen over teams maakt deze teams juist langzamer. Bovendien is het ‘beter worden’ voor veel teams lastig doordat de grootste belemmeringen om hyperproductief te worden vaak buiten het team liggen (testomgevingen, toegang tot gebruikers, heldere businesswaarde). Het management heeft nog onvoldoende door dat het zijn taak is om de teams te helpen deze belemmeringen weg te nemen. Daarmee wordt de vierde stap om hyperproductiviteit te realiseren geëlimineerd.