Openheid/ Openbaarheid (Openness)

“Het Scrum Team en haar stakeholders zijn het eens open te zijn over al het werk en de uitdagingen bij het uitvoeren van het werk.”

Dit is misschien wel dé kernwaarde die agile scrum onderscheidend maakt van andere projectmanagement stijlen. Open zijn over al het werk en de uitdagingen die dit werk met zich meebrengt. Dit geld logischerwijs voor het team maar, let op, óók voor de organisatie en stakeholders! Ik moet bij openheid meteen denken aan een ander woord, namelijk transparantie. Een van de “artefacten” van Scrum. Echter een woordgrapje geeft meteen het heikele punt aan.

Wat is het toppunt van transparantie? Onzichtbaarheid!

En als er iets is wat we niet willen is het wel onzichtbaarheid. We willen binnen scrum samenwerken op gelijke voet. Om dat te kunnen zullen we álle inzichten moeten delen. Empirisme, kennis uit ervaring, vormt de basis van de agile werkwijze. Op basis van álle beschikbare kennis willen we de “inspecteer en pas aan” cyclus kunnen uitvoeren. Leren door openheid, transparantie.

Maar dat betekent nogal wat. De doelen van iedereen én de voortgang in het behalen van deze doelen moet voor iedere betrokkene inzichtelijk en duidelijk zijn. Taakborden, informatie “stralers” zoals een “burn-down” kaart, obstakels, etc. helpen daarbij. Maar vooral ook open communicatie tussen mensen.

Mens

Open zijn over wat je doet en over wat iets met je doet. Dat vraagt nogal wat van mensen:

Vertrouwen! Op mens niveau is vertrouwen onontbeerlijk als je openheid verwacht.
Lef! Fouten durven toegeven, niet alleen binnen je eigen team, maar ook aan stakeholders.
Respect! Ik kan heel open zijn, maar dat wil nog niet zeggen dat ik bot of zonder respect moet of mag communiceren.

Maar betrek het vooral niet alleen op jezelf!

Open zijn betekent ook “nee” zeggen tegen de product owner als er niet meer werk in een sprint past.
Open zijn betekent ook sociale controle binnen en buiten het team, iemand aanspreken op ongewenst gedrag.
Open zijn betekend ook zeggen dat ik nu deze blog schrijf, maar voor passende voorbeelden ook Google op internet en echt niet alles zelf bedenk, sorry.

Openheid binnen een (scrum)project is een randvoorwaarde voor succes. Zonder openheid geen ruimte voor verbetering. Maar je zult eraan moeten wennen en werken! Openheid moet groeien, samen met vertrouwen. Een ervaren scrummaster of coach kan je hier zeker bij helpen.

Organisatie

De belangrijkste randvoorwaarde voor openheid moet door de organisatie worden ingevuld!
Op het moment dat er binnen een organisatie ook maar enige reden voor “angst” is om open te communiceren dan houdt alles op!

“We hebben deze fout gemaakt waardoor we deze sprint niet leveren wat we bedacht hadden …”

“Die functionaliteit was beloofd aan de gebruikers! Hoe gaan JULLIE dat oplossen? Dat wordt overwerken de komende weken! Daarnaast gaat dat natuurlijk impact hebben op jullie beoordeling, en daarmee gerelateerde bonus…”

Hoe denk je dat een team of persoon de volgende keer zal communiceren?

Fouten maken mag. In een lerende organisatie zou je zelfs kunnen stellen dat fouten maken moet. Zolang daar een les uit wordt geleerd is het fenomeen fouten maken geen enkele reden voor sancties. Goede retrospective vraag: Wat is de meest leerzame fout die je hebt gemaakt?

Openheid werkt binnen agile scrum 2 kanten op!

Iets wat vanuit organisaties voor het gemak vaak over het hoofd wordt gezien. Alle focus is op het team of de teams. Maar openheid gaat niet over verantwoording van uit een team richting organisatie. Het is tweerichtingsverkeer. Ook de organisatie moet zich “verantwoorden” bij het team, als je het al over verantwoorden mag hebben.
Als organisatie moet je open zijn over wat je drijft. Wat je doelstellingen zijn. Waarom werken we als team aan dit project?
Openheid vanuit de organisatie begint met een heel duidelijk verhaal over het waarom. En niet te vergeten het tijdig communiceren van wijzigingen op het waarom.

Vervolgens het wat, de “productbacklog”. Deze moet te allen tijde zo volledig als mogelijk zijn. Inzicht in al het werk dat voor zover we nu kunnen inschatten verzet moet gaan worden. Inzicht voor het team én de stakeholders.

Bedenk dat het team, waarschijnlijk binnen enige kaders, het hoe bepaald. Niet alleen de Product Owner, maar ook de organisatie moet open staan voor verandering en nieuwe ideeën.

Volgende waarde: Eerbied / Respecteren

Focus/ Aandacht (Focus)

“Iedereen richt zich op het werk/de inhoud van de Sprint en de doelstellingen van het Sprint Team.”

Focus en Aandacht. Wil je echt meters maken in je sprint en daarmee je project dan zal je dit moeten hebben. Deze waarde is 1 van de belangrijke bouwstenen van Scrum. Focus op de werkzaamheden zoals deze op de sprintbacklog staan en daarmee op het behalen van het sprintdoel. Niet met 10 dingen tegelijk bezig zijn, maar echt je aandacht kunnen geven op de werkzaamheden waar de prioriteit ligt en waarvan je de bijbehorende taken op jouw eigen bordje hebt gelegd. Aandacht voor de belangrijke zaken.

Focus zit in het DNA van Scrum. Iedereen in het team speelt zijn of haar eigen rol. Deze rol moet duidelijk zijn en met heldere doelstellingen. Daar moet je je als teamlid ook volledig op kunnen storten en niet afgeleid worden door andere zaken. Als je je rol goed invult en de bijbehorende doelstellingen weet te halen dan weet je dat je bijdraagt aan het halen van het team- en daarmee projectdoel. En iedereen weet dat als je je lekker kunt concentreren op je werkzaamheden zonder al te veel gestoord te worden dat deze vele malen sneller gaan.

Mens

Als lid van een (Scrum) team (als Developer) wil je je kunnen concentreren op je werkzaamheden, wil je focus aanbrengen. Lekker kunnen doorwerken zonder gestoord te worden door meetings, telefoontjes, dat vorige project, etc. De randvoorwaarden om in een “productieve flow” te komen zitten ingebakken in het Scrum raamwerk.

Je krijgt de “WAT”, zaken die belangrijk zijn om NU waarde toe te voegen aan de doelstellingen van de organisatie op een presenteerblaadje aangereikt (de prioriteit van de Product Backlog).
“WIE” wat gaat doen mag je als zelf sturend team zelf invullen.
“WAAROM” iets gedaan moet worden is voor het team ook duidelijk want ze worden deelgemaakt van visie, missie en projectdoelstellingen door de Product Owner. Daarnaast heb je zelf deelgenomen in refinement en poker sessie.
Het “HOE” mag je al dan niet beperkt door architectuur of te gebruiken tools als zelf organiserend team invullen, waarbij de beperkingen uiteraard “ge-challenged” mogen worden door het team als er betere oplossingen zijn.
Het “WANNEER” is ook duidelijk en inzichtelijk, gedurende de lopende sprint, niet te ver vooruitdenken maar nu.

Tel daarbij op dat er een Scrum Master het proces faciliteert (let op, niet leidt!) en problemen of “impediments” die niet direct door het team kunnen worden opgelost wegneemt en er een Product Owner is die direct vragen beantwoord.
De reguliere meetings die er zijn, staan bij voorbaat vast, zijn ingepland en worden ge-timeboxed. Bijna Utopia!

Organisatie

Ook op organisatieniveau moet er sprake zijn van focus.
Vanuit de business: Wijs die ene Product Owner aan die voor een specifieke product-backlog verantwoordelijk is. Die daar ook zijn of haar tijd aan kan besteden. De rol van Product Owner is niet een rol die “er even bij” kan worden gedaan. Geef deze Product Owner mandaat en daarmee vertrouwen. Kanaliseer de vragen over processen en daarmee de bijbehorende impact op projecten via de Product Owner(s).

Maar ook vanuit de resource gedachte. Wijs mensen toe aan een team, niet aan meerdere teams. Iemand die zijn of haar werkzaamheden moet verdelen over meerdere projecten is VEEL minder efficiënt, als dat alle tijd aan 1 project besteed kan worden. Binnen een Scrum team zijn mensen niet even “uitwisselbaar”. Continuïteit en beschikbaarheid bepalen de effectiviteit van mensen binnen een team. Het wisselen van teamleden kan grote impact hebben op de wijze waarop een team kan samenwerken. Om het even technisch te maken van “high-performing” terug naar “storming”. Iets wat je als organisatie niet wil.

Als laatste focus op het raamwerk. Scrum is een agile werkwijze. Echt agile werken doe je niet door een trucje toe te passen (Do Agile). De beste resultaten bereik je door een agile mindset in je organisatie te laten landen (Be Agile). Tenzij je als organisatie een start-up bent is dit een veranderingstraject. Ben je hier bewust van, benoem het en geef het focus. Dan kun je de vruchten plukken van agile werken. Op mens maar ook op organisatieniveau.

Volgende waarde: Openheid / Openbaarheid

En we hebben 1 pagina meer …

Gisteren was de presentatie van een nieuwe revisie van de Scrum Guide, versie Juli 2016.

En de verandering is schokkend. 1 pagina meer! Dat wordt de training aanpassen …

Alle gekheid op een stokje. De Scrum “waarden” zijn toegevoegd aan de Scrum Guide. Een wens die vanuit de Scrum “gemeenschap” al langer speelt.
Het gaat denk ik weer net iets meer houvast geven aan teams en niet te vergeten de organisatie om Scrum op een juiste wijze toe te passen.

Ik ben wel erg benieuwd hoe ze vertaald gaan worden in de “officiële” Nederlandse vertaling. Dit omdat er meerdere betekenissen mogelijk zijn die net een andere invulling (kunnen) geven.

Inzet / Betrokkenheid – Je persoonlijk inzetten voor de verwezenlijking van de doelstellingen van het Scrum-team.
Focus / Aandacht – Iedereen richt zich op het werk/de inhoud van de Sprint en de doelstellingen van het Sprint Team.
Openheid / Openbaarheid – Het Scrum Team en haar stakeholders zijn het eens open te zijn over al het werk en de uitdagingen bij het uitvoeren van het werk.
Eerbied / Respecteren – Scrum team leden respecteren elkaar als capabele, onafhankelijke mensen.
Moed / Lef / Durf – Scrum Team leden hebben de moed om het juiste te doen en te werken aan moeilijke problemen.

In een latere post kom ik in meer detail terug op de afzonderlijke waarden en wat nu het effect van deze waarden is …

Agile is een mindset, een manier van denken …

Deze zinsnede hoor je van iedere zichzelf respecterende agile coach (en dus ook van mij!). Uiteraard besteedt je als coach en trainer ook aandacht aan. Het is echter belangrijk om jezelf hiervan bewust te zijn. Sterker nog, even heel goed bij stil te staan. Deze andere manier van denken vormt namelijk de basis van succesvol aan de slag gaan met een agile manier van werken.

In veel organisaties zie je helaas het omgekeerde. We gaan agile werken! En waarom gaan we agile werken?

Het is hip, gaaf, cool, kwaka. Iedereen doet het.
We hebben als organisatie in onze projecten problemen met productiviteit, kwaliteit, reageren op verandering.
Agile belooft mooie dingen, bijv. het tevredenstellen van de klant, snel(ler) leveren, zelfsturende/organiserende teams. Wat wil je als management nog meer?

Agile is het toverstokje, het wondermiddel, in goed Nederlands "the silver bullet" waarmee we al onze problemen in projecten gaan oplossen. En hoe doen we dat dan?

Mag ik van jou, uit de serie werkwijzes ... Scrum op het moment dat we op teamniveau bezig zijn of bijvoorbeeld SAFe als we agile willen werken op bedrijfsniveau.

We gaan volledig voorbij aan de manier van denken (of stippen dat even aan tijdens een cursus ...) en "implementeren" een manier van werken. Een manier van werken die nogal wat vraagt van de mensen die er mee aan de slag gaan. Allerlei voorgeschreven bijeenkomsten, voorbereiden van werk in de vorm van een "product backlog", dagelijks inzicht geven in je werkzaamheden en de status daarvan, in korte tijd iets moeten opleveren. De boog staat meer gespannen dan met een traditionele project aanpak.

Dit een wezenlijke verandering. En wat is onze natuurlijke reactie op een verandering? Inderdaad!
Het "waarom doen we dit?" is een vraag die al heel snel de kop opsteekt, gevolgd door "moet dit echt?" en voor je het weet werk je nog alleen agile voor de bühne.
Et voilà, zie hier de reden waarom veel agile implementaties niet datgene brengen wat er van te voren van verwacht werd.

Agile gaan werken vraagt van iedereen een agile manier van denken. Niet alleen een opgelegde gedragsaanpassing van de IT club, of nog beperkter het project team. Iedereen die enigszins betrokken is bij een project zal anders tegen de wereld moeten gaan aankijken. Van opdrachtgever tot uitvoerder, van bouwer tot gebruiker.

Maar wat behelst die agile manier van denken dan? Waarom is die dan anders dan wat we zien in traditioneel project management (voor het gemak de waterval methodiek)?

Wordt vervolgd …