Scrum in een Prince2 georienteerde organisatie

Prince2 als projectmethodiek, met Scrum als ontwikkelmethodiek zijn beter te combineren dan je op het eerste gezicht zou denken. Het bijt elkaar niet, maar kan elkaar versterken en aanvullen. En dat is goed nieuws, want in veel organisaties is de behoefte om vast te houden aan de Prince2 sturings- en controle mechanismes nog heel nadrukkelijk aanwezig. Je kan daar als Agile evangelist tegen vechten en binnen de organisatie veelvuldig de voordelen van agile / scrum, en de nadelen van Prince2 en waterfall onder de aandacht brengen. Maar je kan ook (al dan niet tijdelijk) een tussenvorm realiseren, hier een paar tips:

– Een stuurgroep is een krachtig Prince2 instrument. Bij hardnekkige impediments / issues kan de ScrumMaster de stuurgroep gebruiken om deze snel op te lossen. Het is dan wel essentieel dat de stuurgroep heel regelmatig bij elkaar komt (wekelijks/tweewekelijks)

– Een productowner heeft (helaas) niet altijd de beslissingsbevoegdheid om bepaalde requirments hoog of laag op de prioriteitenlijst te krijgen (oftewel, business value bepalen van userstories op de backloglist), ook hier kan de stuurgroep uitkomst bieden, belangrijk is dat de productowner zitting neemt in de stuurgroep, en dat deze vorm alleen wordt gebruikt voor grote beslissingen, de product owner moet wel enige mate van beslissingsbevoegdheid hebben anders wordt de voortgang en succesvol afronden van de sprints bedreigd.

– Sturen op geld / tijd en scope: Dit aspect is meestal de belangrijkste reden voor een organisatie om vast te willen blijven houden aan de Prince2 artifacten waarbij er vooraf in een Projectinitiatie fase afspraken worden vastgelegd omtrent geld /tijd en scope, en de toleranties hiervan. In Scrum kunnen deze nooit alle 3 vastliggen omdat er ruimte is voor voortschreiddend inzicht en dus verandering in de scope (iets wat in ieder project voorkomt). In Scrum kunnen tijd en geld heel goed worden vastgelegd. De productbacklog zal gebruikt moeten worden om de impact van de veranderingen in scope aan de stuurgroep duidelijk te maken. Het krachtige hieraan is dat ze een (voor de business) belangrijke functionaliteit waar ze blijkbaar niet eerder aan hadden gedacht in scope krijgen, terwijl er een minder belangrijke functionaliteit (die met een lagere business value is gewaardeerd) afvalt. Dus gratis meer waarde voor de business. Dit geeft heel expliciet de kracht van scrum weer!

– Doordat scrum al heel snel werkende producten oplevert (dat is namelijk het doel van elke sprint) kan er naar een stuurgroep behalve alleen met een highlight rapport ook dmv een review concrete functionaliteit worden gedemonstreerd. Dit vergroot de betrokkenheid van het management op een hele krachtige manier.

Advertentie

Scrum; geen methodiek maar een mindset

Scrum is in hele korte tijd een zeer populair framework geworden voor software ontwikkeling. Het is een Agile aanpak die vooral transparantie aan de business biedt en tools om snel te schakelen. Maar waarom slaat het zo aan, wat is de essentie van Scrum?

De kracht van Scrum, en daarmee de kern van het succes zit hem wat mij betreft vooral in de nieuwe manier van samenwerken. Het is niet voor niks dat grote internationals als Toyota Scrum incorporeren als framework voor allerlei projecten, niet alleen gerelareerd aan software. Alle projecten waarij in een relatief korte tijd veel hoogwaardig, innovatieve output geleverd moet worden is in principe geschikt om gebruik te maken van Scrum.

De combinatie van korte itteraties met concrete deelopleveringen, zelf organiserende teams, en een stevige empirische basis van constante inspectie van de workload en adaptie van veranderingen in de business maken Scrum tot een revolutionair framework wat helemaal past in de filosofie van het nieuwe werken; maar dan vooral het nieuwe werken in de context van de behoeftes van de innovatieve, enthousiaste, flexibele nieuwe werker!

Zoals met meer ontwikkelingen die op dit moment plaatsvinden waarbij transparantie en samenwerking de basis is, hebben traditionele, hierarchische organisaties nog moeite met deze mindset die ten grondslag ligt aan Scrum. De angst om transparant te zijn en niet alles vooraf in beton te gieten, ipv vol en met vertrouwen het proces in te gaan levert nog wat weerstand op. Maar feit is; eenmaal met deze aanpak in aanraking gekomen is het onmogelijk om oude waterfall methodes te blijven hanteren. Een verandering in projectmatig werken zal dan ook langzaam maar zeker toeslaan, totdat de bewijslast van meer succesvolle projecten een feit is.

5 tips voor een succesvolle SharePoint implementatie adhv Scrum (deel 1)

Langzamerhand is de Scrum ontwikkelmethodiek terrein aan het winnen; ook binnen Sharepoint projecten wordt meer en meer de Scrum ontwikkelmethodiek toegepast; deel 1 van een serie tips uit de praktijk;

• Eis een betrokken Product Owner!; het actief beheren van de requirements dmv de productbackloglist, en zijn aanwezigheid gedurende de sprints (ook buiten de sprintplanningsmeeting om) is een kritische succesfactor voor het team, ook om betrokkenheid van de business bij het project te borgen. De Product Owner heeft de essentiële rol om te fungeren als spreekbuis voor zowel de business als de eindgebruikers wensen. Dat betekent niet dat hij alle beslissingen op eigen houtje dient te nemen: het is de taak van de Product Owner om naar eigen inzicht mensen uit de business of gebruikers(groepen) bij zijn taken te betrekken.



• Hou gedisciplineerd vast aan alle Scrum meetings, dat betekent elke ochtend de stand up meeting houden (Daily Scrum), na de sprint een Retrospective met het team voor evaluatie en het formuleren van verbeterpunten (ook als het daar eigenlijk te druk voor is!), en geef na elke sprint een demo aan de business van de opgeleverde functionaliteit; hiermee vergroot je de transparantie van het proces en creeer je wederom betrokkenheid bij de business.
• Categoriseer je userstories in herkenbare Sharepoint thema’s. Op deze manier is het makkelijker om iets substantieels tijdens de sprintdemo’s te laten zien, denk hierbij aan thema’s als: documentmanagement, profielpagina’s / teamsamenwerking, etc. Binnen de thema’s worden de userstories gewoon adhv de business value opgepakt.
• Werk proactief en project overschrijdend; een sharepoint ontwikkelteam heeft in veel gevallen een grote afhankelijkheid van afdelingen in de lijnorganisatie (bijvoorbeeld met een afdeling beheer of met een IT team); realiser je dat er vaak een groot verschil is in flexibiliteit tussen Scrum teams en traditionele teams & afdelingen; wanneer je deze (cultuur) verschillen weet te overbruggen is de kans op succes en acceptatie vele malen groter. Een manier om dit te doen is de gewenste deliverables expliciet te formulieren (ipv een vage opdracht ‘over de heg’ te gooien)
• Zorg er als ScrumMaster voor dat binnen het team iedereen gelijkwaardig is. De kracht van Scrum is dat het team zichzelf organiseert en zich gezamenlijk commiteert aan de doelstellingen van de sprint (sprintbacklog), het gevolg is dat men elkaar motiveert om kwalitatief hoogwaardige output te leveren.


Binnenkort meer!

Nieuw intranet? Met z’n allen op de sofa!

Er wordt wel eens gezegd; een intranet ontwikkelen is als met een bedrijf naar de psycholoog gaan: Je legt het management en de werknemers op de sofa, laat ze praten, onderwerpt ze aan zelfanalyse en dan komen er allemaal interessante dingen naar boven; denk aan inefficiënte maar ingesleten gewoontes, slechte onderlinge communicatie en samenwerking, en allerhande behoeftes (zoals aan betekenisvol zakendoen, zich in een sneller tempo willen ontwikkelen en vernieuwen). En al dit zelfonderzoek leidt, met de juiste begeleiding en de juiste middelen, tot nieuwe inzichten en met een beetje geluk tot wat meer transparantie in de organisatie.

Wanneer is een psychiater/coach succesvol? Wanneer de coachee een bepaalde mate van zelfinzicht realiseert en met de aangereikte tools zijn vooraf bepaalde doelstellingen gehaald heeft!

Wanneer is een intranet succesvol? Als eerste natuurlijk het succesvol uitrollen van de IT gerelateerde componenten, na een grondige business- en user analyse moet duidelijk geworden zijn waar het bedrijf behoefte aan heeft, en welke componenten op welke manier worden uitgerold. Vervolgens is het succes afhankelijk van de mate waarin de gebruikers getraind zijn om de dingen te doen die ze willen doen, het niveau van support en de helderheid rondom regels en vrijheden binnen het systeem.

Maar dan begint het pas! Om de nieuw verworven tools ook succesvol te gebruiken moeten er een aantal individuele en organisatorische cultuurveranderingen plaatsvinden. Maar werkt dat wel? Hoeveel succesvolle cultuurveranderingen ken jij?

En dan liggen we dus weer op die sofa, want willen we wel echt veranderen? Of is het een opgelegde wens? Waarom is veranderen zo moeilijk?

Er wordt vaak redelijk vanzelfsprekend gesproken van ‘en dan moet er dus een cultuurverandering plaatsvinden’. Maar een bedrijfscultuur zit op vele manieren verankerd in een bedrijf.

Een belangrijke peiler voor succes is de verantwoordelijkheid die de individuele werknemer neemt in zijn dagelijkse werkzaamheden! Vooral bij de zogenaamde ‘information workers’ vind er een ontwikkeling plaats waarin de werknemer zich meer en meer opstelt als zelfstandig ondernemer die zelf verantwoordelijkheden neemt en zijn eigen tools kiest om zijn doelen te bereiken. In de nieuwe organisatie wordt er niet meer passief gewacht tot er een van bovenaf gedefinieerde missie langzaam in de vorm van opdrachten en taken bij een bepaalde afdeling is terecht gekomen (of niet, soms wordt er bij bedrijven jarenlang inefficiënt en zonder enig besef van doel en nut ‘gewoon gewerkt’, de onvrede en frustratie van een zwaar psychiatrische patiënt is hier niets bij vergeleken).

Het nemen van eigen verantwoordelijkheid is de eerste stap in de filosofie van Het Nieuwe Werken, als omslagpunt wordt vaak de nieuw ingerichte kantoor omgeving genoemd, met al zijn nieuwe digitale middelen om overal bereikbaar te zijn, maar wat daar aan vooraf gaat is een enthousiasme voor de (gezamenlijk) gestelde doelen, en een daarbij behorende hernieuwde verantwoordelijkheid om de zaken in eigen hand te nemen.

Wanneer het enthousiasme ontbreekt, is de vereiste cultuurverandering gedoemd te mislukken. En kunnen we met z’n allen opnieuw naar de psychiater.

De nieuwe organisatie, waar te beginnen?

Stel je zit in het MT van een organisatie, je hebt afgelopen zomer het boek Wikinomics van Don Tapscot gelezen, en je bent ervan overtuigd geraakt dat de enterprise 2.0 filosofie een speerpunt moet worden van jullie nieuwe business strategie voor het komende jaar. Waar begin je? Belangrijk is natuurijk dat je begrijpt waar je het over hebt; voor de echte groentjes; probeer concepten als blogging, social networking, Wiki’s en RSS werkelijk tot je door te laten dringen door over de schouders te kijken vanje kinderen, collega’s of vrienden waarbij het kwartje al gevallen is. Vervolgens duik je zelf het diepe in. Maak accounts aan bij Facebook en LinkedIn zodat je daar de waarde van ziet, initieer het opzetten van een Wiki rondom voor het bedrijf belangrijke thema’s. Bloggen ga je alleen doen als je ergens een (liefst onderscheidende..) mening over hebt. Je nieuwsvoorziening krijg je vanaf nu alleen nog maar binnen op je RSS reader.

So far so good. Hoe krijg je de rest van de organisatie enthousiast? Ik zou starten met het aanschaffen van een aantal exemplaren van het boek Wikinomics en die op strategische plekken in het kantoor laten rondslingeren. De volgende belangrijke stap is het vinden van evangelisten; welke collega’s kunnen een voortrekkersrol vervullen, wie snapt het belang van een intensieve samenwerking met collega’s klanten en toeleveranciers? Zorg ervoor dat je een succesvolle case realiseert die als voorbeeld kan dienen. De veranderingen op langere termijn kunnen heel groot zijn en kunnen afhankelijk van de bedrijfscultuur op weerstand stuiten. Om een voorbeeld te noemen: in heel veel organisaties heerst nog steeds een onuitgesproken cultuur die samen te vatten valt onder de noemer ‘kennis is macht’. Niet iedereen is zomaar geneigd om zijn opgebouwde kennis zomaar te delen. Resultaat is dat er op lokale c-schijven en geautoriseerde server mappen hele waardevolle maar voor de rest van de organisatie onvindbare presentaties, artikelen, etc. staan. Nie iedereen wil van nature samenwerken voor een beter gezamelijk resultaat. Hoe dit op te lossen? Hier komen de evangelisten weer om de hoek kijken. Het is belangrijk om te laten zien dat met de collaboratie tools heel mooi inzichtelijk kan worden gemaakt wie welke kenis heeft verspreid, dus van ‘kennis is macht’ naar; ‘publiseer en wordt expert’! Wanneer je een aantal key personen in de organisatie ‘om’ hebt, is al het belangrijke voorwerk gedaan en kan er op strategisch niveau nagedacht worden over de de veranderende business visie, en een serieus implementatie traject worden gestart. Dit betekend niet dat de veranderingen top down kunnen worden gerealiseerd, maar wel dat er door de hele organisatie heen commitment moet zijn om transparanter, en vanuit open netwerken (‘cells’) te gaan werken.

Meet Charlie

Ik heb tot nu toe de enterprise 2.0 filosofie vooral vanuit de organisatie belicht. In deze presentatie wordt op een hele frisse en duidelijke manier de perceptie en beleving van een gebruiker, Charlie, geschets.  Hoe ziet de (online) wereld van een enterprise 2.0 evangelist er uit?