Mijn kerst hoogtepunt

Kersttijd, eten, feesten, ... maar het heeft ook zijn leuke kanten! Zo liet een nonkel mij volgende gevleugelde zinntjes van Willem Elsschot vallen op een onbewaakt moment:

want tussen droom en daad
staan wetten in de weg en praktische bezwaren
en ook weemoedigheid, die niemand kan verklaren
en die des avonds komt, wanneer men slapen gaat

Alle kunde en kennis vergaat als iemand zo'n mooie woorden zachtjes kan laten vloeien op papier, die bij het vertellen heen en weer gaan glijden langs je oren, naar binnen, tot zij sterven in het diepst van je gedachten.

Watervallen en valkuilen

Het heeft zo'n negatieve bijklank... we houden er niet van... Waterfall

Nochtans:
De oorspronkelijke (traditionele) waterfal methode -1970 door W. Royce- was een reactie op het phased model: een veel rigidere aanpak. Royce heeft feedback loops geïntroduceerd, en prototyping: als je 't mij vraagt heel erg agile concepten. De feedback processen zijn trouwens volledig geïntegreerd in Prince2 (controlling a stage – work package authorising & monitoring), maar meestal vergeet men om dit toe te passen.

Ik spreek daarom eerder over "push" versus "pull" aanpak: dat duidt op het kernverschil, en vermijdt een onterechte veronderstelling dat de waterval aanpak niet adaptief kan zijn.

Design upfront is ook een verschil, maar eerder een oorzaak/gevolg/noodzaak van een push keuze -ik schreef bijna noodzakelijk kwaad, sorry hiervoor- . Design en analyse zijn nodig om planning te kunnen opmaken. Agilisten stellen zich kritisch op tov (big) design upfront: hoe betrouwbaar is zo'n design? Wat is de waarde ervan? Is dit voldoende voor een goede planning? Wat is de impact van fouten? Hoe gemakkelijk is het om dit plan aan te passen als de realiteit andere noden blijkt te stellen? Is het de kost van de investering waard? enz...

http://en.wikipedia.org/wiki/Winston_W._Royce

Gartner rapport ondestreept belang van Agile (indirect)

Agile met andere woorden.

Enkele suggesties in dit Gartner rapport wijzen op een toenemend belang aan adaptief vermogen, zoals

"Tegen 2015 zal geen enkel bedrijf nog concurrentieel voordeel halen of behouden
als het geen gebruik maakt van de gecombineerde kracht van individuele keuzes,
sociale dynamiek en samenwerking."

"Web mash-ups zullen het dominante model worden voor de creatie van samengestelde bedrijfstoepassingen." Volgens de analist kunnen daarmee een nieuwe soort van kortetermijns- of zelfs wegwerpapplicaties gebouwd worden.

Bad smells when implementing Scrum

Het komt me allemaal voor als reality TV...
It all comes down to trust

extract uit: Team Disfunctios and Scrum by Plamen R. Balkanski

(Pat is a Scrum master of a new scrum team with members that blame each other causing bad velocity...)

"Pat feels betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have been for nothing. The team hasn’t been maturing; it hasn’t even formed. Team members were living in artificial harmony by avoiding conflict. Now they feel disengaged and demonstrate no commitment. When a team fails to hold one another accountable, they demonstrate the most damaging dysfunction: inattention to results.

Pat is in an awkward situation because, though she firmly believes Scrum is not the reason for these problems, Scrum has exposed the dysfunctions. Everyone else is convinced that pre-Scrum, no dysfunctions existed. Post-Scrum, the team looks like it’s falling apart. How can Pat change this? How can she resurrect the team and prove to senior management that Scrum is worth the effort?

Can Somebody Please Explain!

I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like Pat’s. ..

I should warn you that this is not something that can change overnight. If your team is experiencing these types of dysfunctions, overcoming them will require patience, good coaching, facilitation skills and then more patience. It will probably be many days, if not weeks, until you see some change.

• It might take as long as six-to-nine months until you start feeling optimistic about your team.
• Are you willing to be vulnerable?

It all starts with trust. "

Simple visual example to motivate agile and lean processes

Heldere uitleg. Hoe een beeld duidelijke taal kan spreken.
Alleen al een vermelding waard omdat het artikel zo kort en duidelijk is, dat je het sneller kan lezen dan dat je ernaar kan surfen :) beknoptheid wordt beloond!

Het is een beeldvergelijking tussen een verkeerssituatie (alles staat stil ondanks de verkeerslichten en alle verkeersregels die iedereen toepast...)
en de situatie in een station, luchthaven, ... waar geen regels zijn over wie waar moet lopen, het individuele pad van elke passagier wordt last minute bepaald, door de passagier zelf: er zijn geen voorgedefinieerde sporen, het gebruikte pad is niet altijd de kortste weg, maar het systeem werkt wel. Ook dit systeem heeft zijn grenzen, en zal files veroorzaken als het overladen wordt, maar het is duidelijk veel stress bestendiger.

bron: http://jochenkrebs.com/agileportfolio/?p=28

Who is a leader?

Deze quote over leadership komt uit een pdf op de blog van Jeff
http://hersenspinselsenbuikverzinsels.blogspot.com/

The first problem with all the stuff that's out there on leadership is that we haven't got a clue what we are talking about." We typically think of the leader as being the person at the top.

"But if you define a leader as an executive, then you absolutely deny everyone else in an organization the opportunity to be a leader."

Peter Senge

Personal responsibilty

Op 34-24 naar Agile Business Conference geweest, en een bijzonder interessante sessie bijgewoond van Christopher Avery.

Van zijn presentatie bestaat een interessante MP3
http://www.christopheravery.com/temp/Part1of2HowtheMindProcessesResponsibility.mp3
ok, amerikaans: sla de eerste 17 minuten over, en zelfs daarna moet je om de 5 min. naast zijn self-publicity luisteren

eigen samenvatting/conclusie
In een agile context kan je pas aan verantwoordelijkheid komen, respons-ability - de kunde om zich continu te aan te passen om een vooropgesteld doel te bereiken, als je

• jouw doel kent en wil opnemen
• de dagelijkse uitdagingen erkent, je eigen rol erin erkent, zonder schaamte kunt redeneren, en uit eigen beweging (zonder verplichtingen)
• als je dit doel gemeenschappelijk (in team) wil opnemen).

Tagline:

team work is an individual skill

Mijn iets uitgebreidere notities
(sorry om engels en nl door elkaar te halen)

a manager van self managing teams maakt volgende evolutie door:
- van accountability way-of-working
= externe verwachting naar iemand in een team
Ik, manager, verwacht dat mijn team lid ...
- naar responsibility facilitator (responsibility = the ability to respond to problems, situations, challenges)
= interne eigen gedrevenheid, zichzelf eigenaar van een probleem, doelstelling voelen
Mijn team lid voelt zich verantwoordelijk om ....

How the mind works in a responsibility process?
How does everyone respond to a problem/challenge
What are the steps everyone goes trough growing to "responsibility"?

0. denial (is dit waar?)
(0 ontkent het probleem, de uitdaging)

1. lay blame (wie heeft dit gedaan?)
2. justify (de situatie verklaart dat dit normaal is...)
(1 en 2 leggen de oorzaak extern)

3. shame (Ach, waarom deed ik dat toch?)
4. obligation (ik ben verplicht om hier iets aan te doen)
(3 en 4 leggen de oorzaak intern, maar zijn nog onvoldoende om tot een verantwoordelijkheids gevoel te komen)

5. Responsibility

Je komt best voorbij 4 om een responsibility leerproces mogelijk te maken.
Elk quit scenario voor 5 verhindert een leerproces, en veroorzaakt enkel frustraties op korte en lange termijn Niet toevallig dat Lysa Adkins (http://www.youtube.com/watch?v=TvYqhYEaqMs) terecht zegt dat Freedom (als je boven de obligations staat) = responsibility

Keys to personal responsibility:
1. intention: I want xxx
2. awareness: Be aware in which of the above steps you are (blame, justify, ...), how you go through it, when (in which situations) you also block, ...
3. confront: Face the truth - acknowledge that you don't have a complete view on reality (you need a team)


Note: Research naar verantwoordelijkheid: conclusie What -> how
Wrong: yes/no - sm is having personal responsibility or not having personal responsibility
Right: how? - How is sm taking up personal responsibility?

User Stories Applied For Agile Software Development

Voor de zoveelste keer gebladerd door het boek van oa Mike Cohn, en deze keer enkele notities verzameld...

Schrijf elke user story in de vorm “als [type gebruiker x] wil ik .....” en hou dit beknopt

• Beknopt: Max 3 lijnen, indien mogelijk enkel een paar woorden – hulpmiddeltjes:
• beschouw elke user story (=een requirement) niet als iets dat nu volledig moet zijn, maar als “een reminder om te bespreken op het moment dat het in een sprint gepland wordt” -> dat vermijdt ook dat je veel werk steekt in requirements die nooit ontwikkeld worden
• focus op “bespreken”: communicatie op het goede moment is rijker en efficienter dan lange requirement listings
• ipv gedetailleerde beschrijvingen van requirements, is het nuttiger om voorbeelden toe te voegen in de vorm van test cases die voor acceptatie zullen gebruikt worden – steek je tijd eerder in de overweging of die test cases volledig en representatief zijn, eerder dan in de beschrijving ervan
• idem voor uitzonderingen, specialekes etc: voeg ze toe als test cases ipv ze te beschrijven
• wat niet in een voorbeeld kan, past vaak in de “definition of done” van sprints, releases, ...
• zolang een user story niet gepland is in een sprint kan je de test cases oplijsten ipv ze onmiddellijk te verzamelen bij elke user story
• als “herinnering” kan je notes toevoegen met dingen die je later niet mag vergeten bespreken
• vervang eventueel [type user x] door een concrete naam: dat maakt alles meer tastbaar en helpt de developer om in concrete situaties te denken
• vermijd zo veel mogelijk dependencies tussen user stories