Vaak genoeg online, informatie zoekend en publicerend, om via diverse wegen medesurfers met soortgelijke interesses te boeien. Muziek, IT, websites, genealogie, fotografie, nieuwe vormen van communicatie en interessante sites zijn gemeenplaatsen.

07 juli 2009

Agile Haarlemmerolie voor projecten?

Mike Cottmeyer riep onlangs uit Yes, Agile isn't Project Management. Inderdaad, niet als projectmanagement methodiek, wel als ontwikkelaanpak die onmiskenbaar invloed heeft op de manier waarop projecten worden ingericht en bestuurd.

Smaakt naar meer?
En waar je Agile projecten in actie hebt gezien, er zelf één of meer geleid hebt, is de vervolgvraag al snel: waarom doen we dit niet altijd? Is Agile de Haarlemmerolie voor on-time delivery en een scope die wel voldoet aan fitness for purpose / fitness for use?

Uiteraard biedt elk project weer uitdagingen voor inrichten en besturing, bemensing en draagvlak. Zelf zal ik niet meer spontaan voor een klassieke waterval-methode kiezen. Motivatie en betrokkenheid van medewerkers bij een incrementeel groeiend, gaandeweg bijgestuurd resultaat is nu eenmaal in een Agile veel groter. Cultuurelementen als verantwoordelijkheid nemen als team, de business letterlijk aan het stuur zetten van ICT-ontwikkelingen spreken me enorm aan.

Dan maar overal en altijd?
Trek je het beeld van haarlemmerolie door, dan kom je bij Dustin Wax die onlangs Scrum for One bepleitte. In mijn ogen draaf je dan door, want wat hebben je eigen effectiviteit en efficiency, getting things done maniertjes direct met een team effort als Agile Scrum te maken? Noem het in de persoonlijke sfeer vooral doelgericht werken/leven, een persoonlijk ontwikkelplan, getting things done, of iets anders, maar niet Agile en/of Scrum. En pas op met het propageren van je eigen recept, zoals Koen van der Borght: naast erkenning als goeroe kan ook maar zo het label methode freak, evangelist, of tunnelvisie geplakt worden.

Labels: ,

21 juni 2009

Hoe bewijs je waar je in gelooft?

Paulus heeft geloof alsvolgt 'gedefinieerd' in Hebreeën 11 vers 1:
"Het geloof legt de grondslag voor alles waarop we hopen, het overtuigt ons van de waarheid van wat we niet zien."
Het blijft lastig voor ons denkende mensen die overal een 'bewijs' voor willen zien. Een paar recente voorbeelden uit mijn eigen omgeving.

Wat is de toegevoegde waarde van social media?
Waarschijnlijke achtergrond: tijdverdrijf, lastig te verkopen als product of dienst aan een in crisistijden op de centen zittende klant / opdrachtgever. En dus wordt een beroep gedaan op Social media case studies. En dat terwijl de basishouding bij social media (web 2.0, sociale netwerken en verwante 'buzz words') samenwerking is. En terwijl iedereen intuïtief instemt met de meerwaarde van samenwerken, willen we de effecten wel graag kwantificeren voor een business case.

Werkt Agile Scrum?
De demonstratie aan het eind van de eerste Scrum sprint van vier weken deed veel deelnemers de schellen van de ogen vallen. Ja, het kan dus echt, werkende software, inclusief foutafhandeling, achterliggende database en voldoen aan de huisstijl. En dus heb je 'late bekeerlingen' die als Thomas een week later alsnog een eigen demonstratie willen hebben. En opnieuw, kun je een op elkaar ingespeeld team 'pakken'? OK, je kunt een burndown chart raadplegen, maar wat heb je aan dat 'teken'?

Creationist en evolutionist begraven strijdbijl
Aantrekkelijke kop in het Nederlands Dagblad over een congres in het kader van het Darwinjaar. Het zijn allebei geloven, zo stelde men moedig. Een week ervoor had een 'brede groep christenen' nog de Verklaring van een gezamenlijk geloof in God als schepper ondertekend. En dus leidde dat tot terechte satire op Goedgelovig.nl: de Schepper en Zijn angsthaasjes. Kun je je geloof bewijzen met een handtekening? Is dat nodig?

Een kleine stap verder is dan de koppeling tussen Genesis 1 en Pangaea, zoals KingdomGeek laatst 'bewees'.

Geen geloof zonder bewijs
Pé de Bruin, in januari 2009 overleden, schreef onder meer Geen geloof zonder bewijs. De oprichter van het Utrechtse Stadsblad wilde na het verlies van twee kinderen "weten waarom hij ze moest verliezen, en besloot de bijbel te bestuderen. In een studie theologie geloofde hij niet. Hij was niet echt geïnteresseerd in wat anderen over de bijbel schreven, maar wilde hem zelf lezen, terug naar de bron."

Labels: , ,

17 juni 2009

Agile project management: dagelijks inzicht

Hoeveel projectmanagers zitten niet in een spagaat tussen enerzijds de lijnmanagers die het liefst wekelijks duimdikke rapportages willen ontvangen en anderzijds de beperkingen van een urenverantwoording en -aggregatieproces dat over vele schakels loopt? Om dan nog zinvol te kunnen sturen op tijd en geld, wordt een uitdaging op zich. Tel daarbij de structureel niet door individuele projectmedewerkers ingevulde estimates to complete (ETC's) en wijzigingen in uurtarieven gaandeweg het project.

Zodoende is maandelijkse rapportage al een verplichte dag in afzondering met project management software, rekenmachine en je issue log om de beweging ten opzichte van je planning te onderbouwen.

Zo kan het ook!
Hoe anders is de transparantie van Jira's Greenhopper extensie, waarmee op dagbasis de voortgang in je project inzichtelijk is, niet alleen voor jou, maar voor iedereen die toegang heeft tot Atlassian's vlaggenschip voor ondersteuning van systeemontwikkeling en test.


Dat maakt op dagbasis mogelijk om maatregelen te nemen als:
- de groep herinneren aan de toezegging als team in deze sprint het beloofde te gaan opleveren.
- soepel om te gaan met een aanvraag voor een vrije dag volgende week, of juist een toegekende verlofdag in te trekken.
- hulp in te roepen om bijvoorbeeld op testable gezette software items te testen en zodoende de status 'done' te bereiken en het verloop van de grafiek positief te beïnvloeden.

Labels: ,

27 mei 2009

Agile project management inspiratie uit netwerken

De komende periode kun je inspiratie opdoen om je Agile projecten nog beter te kunnen leiden.

Integrating Agile Conference
Op donderdag 18 juni organiseert Agile Consortium Benelux in samenwerking met Agile Holland de conferentie Integrating Agile met ondertitel It's time to permanently incorporate Agile in your organization. Plaats van handeling: Claus Hotel & Event Center, Hoofddorp

Leden van ACB of Agile Holland betalen €400 exclusief BTW; niet-leden € 450, exclusief BTW. CIOs, COOs, CTOs, program managers, project managers, IT managers, business analysts en product managers/owners zijn het beoogde publiek. De introductie van Agile practices en principes in je organisatie staat centraal.
Lees alles na in de conferentie flyer.

NL Scrum meetup met Sutherland

De NL Scrum user group organiseert 24 juni een Open Space met Jeff Sutherland. Jeff Sutherland is de uitvinder van Scrum en heeft bij meerdere bedrijven met Scrum gepraktizeerd en geeft Scrum trainingen over de hele wereld. In een Open Space bijeenkomst krijg je de gelegenheid om jouw vragen en uitdagingen te bespreken met Jeff Sutherland en andere ervaren Scrummers.

Deze bijzondere meetup heeft al meer dan 65 belangstellenden getrokken, en vol=vol. Zorg ervoor dat je vrienden hebt die wel kunnen gaan en je op de hoogte willen houden. Word zo snel mogelijk lid van NL Scrum en houdt toekomstige meetups in de gaten.

DSDM Consortium
Het DSDM Consortium waarvan ik jaren geleden lid werd, toen DSDM bij ABN AMRO de verplichte methode voor systeemontwikkeling was, heeft zich inmiddels verbreed. De club denkt en rapporteert inmiddels over het gehele spectrum aan Agile methoden. Op hun website staan diverse rapporten en artikelen.

Labels: ,

13 mei 2009

Agile project management - schatten en meten

Voor de eerste sprint hebben de ontwikkelaars en software architect in het project een inschatting van de zwaarte van User Stories gemaakt met behulp van Planning Poker kaarten, daarbij gefaciliteerd door de Scrum master.

Bij het meten van de uitvoering, in het onderhanden project met de GreenHopper plugin op Atlassian's JIRA, speelt onder meer de burndown chart een belangrijke rol.

Maar wat als de zwaarte van een te realiseren stuk software niet overeenkomt met de (gepercipieerde) zwaarte vanuit optiek van een tester, of - zij het eerder aangegeven - ontwerper? Kun je wel veilig Story Points per dag als maatstaf voor de productiviteit van een team spreken, als rollen van ontwerper, ontwikkelaar en tester niet uitwisselbaar zijn?

De bedachte work-around is een schatting te vragen van de afzonderlijke rolhouders, dus een schatting van de ontwikkelaars, ontwerpers en testers. Waar de zwaarte sterk uiteenloopt (makkelijk om te ontwerpen, redelijk bouwbaar, maar verrekte lastig om te testen) moet ouderwets gepland, gepuzzeld en geschoven worden met
- de beschikbare capaciteit in de verschillende rollen
- de volgorde van oplevering van User Stories

Was deze uitdaging ook opgetreden bij hanteren van een andere eenheid van werk, zoals het bij het Capgemini Accelerated Delivery Platform gebruikte Smart Use Case? Ik vermoed van wel, gegeven de leegte bij de disciplines Development (wat is het verschil met Code and deliverable generation?), Testing en Acceptation.

Apart vooraf schatten OK, maar commitment van het team voor de inhoud van de sprint, en dus ook het meten van de productiviteit van het team tijdens de looptijd van de sprint, blijft onverkort staan. Als projectleider heb ik immers niets aan achteraf wijzen naar elkaar (ja, maar zij zorgden voor vertraging!).

Heb je ervaring met deze planningperikelen? Deel dan je ervaring met een commentaar.

Labels: ,

15 april 2009

Agile Project management - a user story

Projectized' Thushara Wijewardena uit Sri-Lanka zette onlangs een aantal persoonlijke lessen naar aanleiding van eerste kennismakingen met Scrum projecten op een rijtje. Een herkenbaar verhaal, want een relatief nieuw en relatief met weinig handboeken, structuren, best practices en dergelijke omkleed proces vergt bij toepassing in een concreet project bij een specifieke opdrachtgever wat eigen smaakmakers. En dat is zo met elke methode, aanpak of structuur die je voor een proces wilt inzetten. Nooit op basis van de letter alleen, geruchten of aannames, maar altijd nuchter, praktisch gemaakt en met de nodige eigen inbreng.

Twee onderwerpen vergen bij het momenteel zelf op maat snijden van de Scrum aanpak de nodige aandacht: specificaties en testen.

Specificaties: wat voor wie en waarom?
Vooraf is nagedacht over requirements, de functies die het systeem moet hebben, helemaal goed. Anders dan anders worden die niet in beton gegoten, onder het dreigement dat elke wijziging via een formeel wijzigingstraject loopt. Nee, de aanpak houdt expliciet rekening met wijzigingen in de scope tijdens de uitvoeringsfase. Niet, dat er vrijheid is om alles maar op te pakken. Er vindt juist een afgewogen afruil in prioriteiten plaats. Wat je nu extra oppakt, moet direct ten koste gaan van wat anders. En of je de specificaties nu vormgeeft in SMART requirements, smart use cases of user stories, is mij geen stammenstrijd waard.

Wat me wel interesseert vanuit project management optiek:
1. efficiency in de vastlegging (graag eenmalig, eenduidig en traceerbaar gedurende de looptijd van het project)
2. overdraagbaarheid van eindresultaten naar de beheerders
3. een prettige match van aanpak, gebruikte hulpmiddelen en de vaardigheden van de projectmedewerkers.

Testen in agile projecten: wie accepteert wat wanneer?
Agile testing binnen de sprint ligt voor de hand, de reden waarom testers van meet af aan ook in het scrum team zitten, en niet pas bij acceptatie of oplevering komen kijken. Voor unit- en delen van systeemtesten waren er de eerste jaren dat Scrum gebruikt werd allerlei oplossingen beschikbaar. De aandacht voor functionele testen en gebruikersacceptatietesten is van zeer recente datum. De twee hiernaast afgebeelde boeken, Agile Testing en Testen 2.0 helpen ons team enorm om vanuit de Definition of Done via een (product) risico-analyse te komen tot een master testplan. De teststrategie is erop gericht de functionaliteiten zoveel mogelijk tijdens de maandelijkse sprint af te dekken met tests. De demo op de laatste werkdag van de maand is gericht om acceptatie van de opgeleverde sprint te krijgen.
Die oogst wil je niet na het uitvoeren van de sprint kwijtraken door een reguliere wekenlang durende gebruikersacceptatietest (GAT). Vaak is zo'n GAT een vrijbrief om echte testbevindingen te mengen met wensen, dingen die men gaandeweg het project vergeten is en het betrekken van stellingen, zodat het lijkt alsof de wereld vergaat als met een aantal bekende fouten de in productiename fiatteert.

Heb je echt even de tijd, besteed dan een uur om de Google TechTalk presentatie van Quality Tree's Elisabeth Hendrickson over Agile testing te bekijken.

Labels: ,

01 april 2009

Agile project management - sprint zero

The Scrum project management method. Part of t...Image via Wikipedia

Na jarenlang PRINCE2 (of pogingen van bedrijven daartoe) te hebben gecombineerd met systeemontwikkeling volgens waterval of System Development Methodology (SDM), Dynamic Systems Development Method (DSDM) en Rational Unified Process (RUP), heb ik voor mijn huidige project gekozen voor toepassing van een (andere) Agile aanpak, Scrum.

Dat je ook een agile ('wendbaar') aanpak kunt gebruiken in een rigide toepassing ervan of misbruiken om vooral geen specificaties vast te leggen, carte blanche te krijgen voor ontwikkelwerk, is bekend. Collega Sander Hoogendoorn schreef er vorige week een kritisch stuk over op Capgemini's Capping IT Off blog.

Ook het vorige week per e-mail aangekondigde congres Integrating Agile, dat Agile Consortium Benelux met Agile Holland op 18 juni organiseert in Hoofddorp, belicht deze aspecten:
- Grip on Agile, on how to apply just enough process
- Breaking the myths surrounding traditional software development and Agile
- Organizational impact of Agile on IT and the rest of the organization

Sprekers worden gezocht, dus heb je over deze onderwerpen echt wat toe te voegen aan een geïnteresseerd publiek, geef dat dan aan bij de organisatoren.

Anyway, geen enkel project, team of ontwikkeltraject is volledig zelfstartend. En daarom is ter voorbereiding van de genummerde sprints (iteraties, tijdvakken met op te leveren producten) een zogenaamde sprint 0 (sprint zero) gedefinieerd.

De principes achter Scrum 'tussen de oren krijgen', ontwikkelomgevingen inrichten, het verdelen van de project scope over sprints en het plannen van producten voor de eerste sprint, het verkrijgen van geschikte medewerkers, allemaal zaken die je niet op een achternamiddag doet. Afgelopen periode stond het klaarstomen van use cases en requirements om een expert schatting te kunnen doen centraal. Vanaf vandaag start de samenwerking met een echte Scrum coach.


Er zitten voor mij als projectmanager onmiskenbaar voordelen aan deze aanpak. De business staat met een product owner echt zelf aan het stuur en bepaalt wat er gebouwd gaat worden. Een de maximale hoeveelheid tijd en geld die aan een sprint besteed wordt, liggen vast. Gelukkig is er in de wisselwerking met de omgeving en de vele andere op te leveren producten nog genoeg over om mijn dagen interessant te vullen.

En dan zijn er nog interessante aspecten als het werken met een uitbestedingspartner met ontwikkelaars in Nederland en India. Jeff Sutherland en Xebia hebben vorig jaar een boeiende presentatie gehouden over Distributed Scrum.

Binnenkort meer indrukken van het scrummen.
Reblog this post [with Zemanta]

Labels: ,

This page is powered by Blogger. Isn't yours? eXTReMe Tracker