Scrum voor Bouwend Nederland

Eind 2015 werd ik gecontacteerd door twee Nederlandse heren die met mij wilden spreken over Scrum. Niet echt wereldschokkend, ware het niet dat Henri Boertien en Ronald van de Hoef wilden toelichten hoe zij Scrum toepasten in de vastgoedsector.

Tijdens ons gesprek, in januari 2016 in Antwerpen, werd niet enkel snel duidelijk hoe wij een passie voor Scrum, en een geloof in de onderliggende principes van Scrum deelden, maar ook hoe onze respectieve sectoren, softwareontwikkeling en vastgoedprojecten, nogal wat gelijkaardige problemen kennen waar Scrum een positief antwoord op heeft.

scrum2buildHenri en Ronald gingen door op hun elan, en publiceerden net de eerste versie van hun Scrum-gids voor Bouwend Nederland, getiteld “Scrum2Build“. Zij waren zo vriendelijk ondergetekende te vragen het voorwoord te schrijven, een vraag waar ik met heel veel plezier op in ging.

Dus nadat Nederland in diverse domeinen van de maatschappij reeds Scrum omarmde, en de fundamentele principes ervan; onderwijs, sales, marketing, thuiszorg, brengt Priom, de organisatie van Henri en Ronald, Scrum nu ook naar Bouwend Nederland.

Download je eigen exemplaar via de Scrum2Build website.

Contacteer deze voortrekkers van Scrum voor de bouwwereld via Info@scrum2build.nl.

The Future Present of Scrum (Are we Done yet?)

Scrum turns 21. Thank YOU!

Scrum was for the first time publicly presented and described in the paper “Scrum Development Process” in 1995. Scrum is turning 21 years old.

It starts and ends with people.

Scrum can only last and prosper -across the globe, across industries- because thousands and thousands of people, organized in teams, departments, organizations, employ Scrum to deal with complexity, to tackle difficult challenges, to create valuable product. Day in, day out. (Depending on the source, 70-90% of all Agile teams worldwide say they use Scrum.)

Regardless of region, organization, culture, or background, every individual has the intrinsic capability to self-organize and thrive by working in the context that Scrum creates. Through people those benefits can be unlocked to wider ecosystems.

Are we Done with Scrum?

Verheyen, Gunther - Scrum - A Pocket Guide (A Smart Travel Companion)In my book “Scrum –  A Pocket Guide” I present 2 major challenges, that will help define the future state of Scrum:

1/ The Power of the Possible Product

From having implemented Scrum for the ‘how’ of product development, adding more focus now to ‘what’ needs to be built is crucial. That shift will help organizations discover the power of the possible product, reduce the amount of product built, instead of merely optimizing the way that the product is being developed. (Scrum – A Pocket Guide, November 2013)

2/ Upstream Adoption

More than about process and techniques, moving from the old, industrial paradigm to the new Agile paradigm is about culture and behavior. The common bottom-up enthusiasm that arises from doing Scrum is unlikely to be sufficient for such transformation. For a lasting effect the common bottom-up enthusiasm needs to be supported and facilitated by upstream adoption.  (Scrum – A Pocket Guide, November 2013)

Besides these ones there are obviously many more challenges related to implementing and adopting Scrum, related to getting more benefits, a higher agility out of Scrum, a higher ability to adapt:

Scrum Challenges

Let alone the secondary-order challenges that many organizations get themselves into with attempts to re-define, wrap, package, and rename Scrum, although the core engine they build upon is still… Scrum.

Scrum, essentially

What if, moving forward, we focus on the essence, the core purpose of Scrum?

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. (“Done is a crucial part of Scrum, actually“, May 2015)

Scrum is a tool that supports people, teams, departments and organizations to gain agility; ‘agility’ being the ability to adapt, to change course, to explore unthreaded paths. Agility is not achieved at the insides of an organization. It is validated through external impact.

Hence the purpose of Scrum to create a Done Increment of product, no later than by the end of a Sprint, where a Sprint takes 4 weeks, no longer and often shorter.

Closed Loop Feedback (Scrum)

An Increment in Scrum is not really Done if it can’t potentially increase such impact. An Increment is not Done if it’s not releasable. An Increment in Scrum can be Done before a Sprint expires, but no later.

How Done are you?

Over the past year I started actively inquiring on how many people using Scrum create Done Increments, with “Done” reflecting a state of actually ‘releasable’. From all people and teams saying to be using Scrum, at most 10% indicate their Increments are in a releasable state. And even then the biggest struggle is to maintain this high state of quality Sprint after Sprint after Sprint. I recently heard Jeff Sutherland say his experience says it is certainly no more than 20%.

The crucial questions for every Scrum practitioner are:

  • Do you have a definition of Done?
    • Does your definition of Done reflect releasable?
  • Do you create actually releasable Increments of product?
    • Every Sprint?

Then ask yourself, “What is stopping me?” and take action. Involve your Scrum Master in removing the Impediments that are preventing you from creating releasable Increments of product. Expect your management to be involved as well.

The future present

It is obvious that we are not Done yet with Scrum. We’re not sufficiently employing Scrum to the level that every Sprint, or sooner, we have a Done, releasable Increment of product. This however is the foundation of agility, of empiricism, and the ultimate sense of fulfilment.

The future present of Scrum is the creation of Done Increments. It is an ambition that will get us a long way, if not another 2 decades.

Scrum begins with Done.
Let the next 20 years be about enacting Scrum.

Verschijning van mijn boek “Scrum Wegwijzer”

Scrum Wegwijzer6 April 2016. Mijn boek “Scrum Wegwijzer” is net verschenen.

Dit is de Nederlandse vertaling van “Scrum – A Pocket Guide” dat in november 2013 verscheen. Ik wilde bij het thema blijven dat Scrum een ontdekkingsreis is, een avontuur. Ik vertaalde daarom de originele subtitel “A Smart Travel Companion” naar “Een Kompas voor de Bewuste Reiziger”. Dat mijn schrijfsels de lezer, die bewuste reiziger, mogen leiden op zijn avontuurlijke reis.

Bestel je exemplaar alvast op Managementboek.nl.

Mijn “Scrum Wegwijzer” werd opnieuw uitgegeven door Van Haren (Zaltbommel, Nederland), met mijn dank aan het team van Van Haren voor het vertrouwen en het geleverde werk. Mijn gewaardeerde collega-trainer Paul Kuijten (‘piraat met een peperkoeken hart‘) was zo vriendelijk de ruwe vertaling voor me na te lezen. Josien Moerman heeft het boek geredigeerd op vraag van de uitgeverij. Ik ben beiden zeer dankbaar. Ze hebben mee gezorgd voor een verhoogde leesbaarheid, een wonderbaarlijk esthetisch resultaat en een gepaste bijsturing richting Noord-Nederlands, in plaats van het door mij overduidelijk gebezigde Belgisch-Nederlands.

Het heeft mij alvast verbaasd hoeveel tijd en werk deze vertaling mij kostte. Nochtans, zou je denken, was het origineel ook van mijn hand. Enfin, ik ben uiteindelijk vooral erg blij dat de vertaling er (bijna) is. Ik hoop er een breed publiek van Scrum-liefhebbers mee te bereiken in de Lage Landen, en zeker in wat mijn Scrum thuisland werd, Nederland. Ik hoop een klein steentje te kunnen bijdragen aan een beter begrip van Scrum, aan meer werkplezier voor een aantal mensen in de wondere wereld van softwareontwikkeling en aan de creatie van betere producten voor tevredener gebruikers.

Ik wens je veel leesplezier, inspiratie en nieuwe ideetjes bij het lezen van mijn Scrum Wegwijzer, mijn kompas voor jou, bewuste reiziger.

Groetjes
Gunther

Scrum Day Europe 2016

Scrum Day Europe 2016In March 2012, Ken Schwaber and I agreed to organize a new Scrum event in the Netherlands. We wanted it to be a platform for the attendants, not for the speakers, for the organizers, or for sponsors. We wanted to crave space for people to talk, connect, share ideas, experiences and challenges on Scrum.

On 11 July 2012 the first Scrum Day Europe event happened. 130 People, one day, no booths, no sponsors, no vendors, a few keynotes and lots of small high-energy, collaborative sessions. An event, not a conference. Impact, not volume.

Imagine, on 7 July 2016 the 5th edition of the Scrum Day Europe event takes place. The location is the same: the fantastic Pakhuis De Zwijger in Amsterdam. The ambition and core concept are the same: interactivity, people, Scrum. I am sure that some day we will even stop projecting the names of us, the organizing parties, Prowareness and Scrum.org.

The theme of this 2016 edition is “The next iteration“. We will not only celebrate the 5th anniversary of the event, but we want to use the occasion to be grateful that Scrum has reached the age of 20. We want to celebrate by thinking about the future of Scrum. My opening keynote, “The future present of Scrum”, will introduce some thoughts. But, much more important, during the open sessions and interactive workshops, attendees have plenty of time to interact with each other and the presenters. Therefore we need the input from Scrum practitioners that want to share viewpoints and considerations.

If YOU have ideas to share on the future of Scrum, the future that lies beyond those teenage years, please send in a proposal for the call for papers via the website. What challenges do we face with Scrum? What do you consider crucial looking forward? How can people, teams, and organizations employ Scrum for software development more and better?

Propose a session. Or get your ticket to join us on this fabulous day for high-energy interactions on Scrum. Be quick. Registration is limited!

Thanks for your participation. Thanks for Scrum.
Gunther.
 
Find us also on LinkedIn and on Facebook.

De Product Owner, mag het wat meer zijn (dan functioneel beheerder)?

Alle werk in Scrum wordt georganiseerd in Sprints en wordt gerealiseerd door Scrum Teams. Sprints zijn 4 weken, en vaak korter. Een Scrum Team heeft alle aansprakelijkheden noodzakelijk voor een goede uitvoering van productontwikkeling in zich, verspreid over 3 rollen:

  • Het Development Team organiseert alle werk om binnen het tijdsbestek van een Sprint, volgens de prioriteiten van de Product Owner, productiewaardige software te creëren.
  • De Product Owner beheert de Product Backlog, de enige bron van invoer voor de ontwikkelactiviteiten, en het budget van de ontwikkeling.
  • De Scrum Master bewaakt, promoot en faciliteert het Scrum-proces, en verwijdert alle (vaak organisatorische) Impediments (blokkeringen) die het team in de weg staan.

Jawel, je past Scrum toe als deze rollen, en alle andere regels van Scrum, worden gevolgd en gerespecteerd. Maar dat is niet meer dan een noodzakelijk begin. De uiteindelijke resultaten die je door Scrum behaalt, zijn vooral afhankelijk van de wijze waarop je de rollen en de regels toepast.

Scrum en de rol van de Product Owner.

Scrum wordt vaak ingevoerd vanuit de IT-tak van organisaties. Scrum wordt daarbij aanzien als het nieuwe IT-proces, het proces volgens hetwelke software wordt opgeleverd naar ‘de’ Business. Scrum schrijft voor dat er een Product Owner moet zijn, en een oppervlakkige lezing van de rol doet mensen overhaast besluiten dat dit wel de nieuwe benaming moet zijn voor de zogenaamde business analist. Een zucht van opluchting aangezien dit een bestaande rol binnen de IT-organisatie is. Merk op hoe het denken wordt bepaald door de historische tweedeling IT versus Business.

Organisaties gaan op deze wijze met Scrum aan de slag, maar stellen vast dat deze invulling van de Scrum-rol van Product Owner toch niet de verhoopte resultaten oplevert. De beslissingsbevoegdheid van de business analist is namelijk beperkt. Nog beperkter zijn de inzichten in de leefwereld van de Business. De analist moet nogal vaak in de richting van de projectmanager kijken voor beslissingen, of de stuurgroep, of is afhankelijk van andere instanties die extern zijn aan het Scrum Team. Het Development Team moet geregeld het werk onderbreken, stopzetten, ander werk tijdelijk oppikken, enz. Geen flow, geen waarde.

ScrumAnd - Product Owner

Dat was zelfs in de klassieke aanpak al een gekend probleem. Vaak werden daarom aan de grens van IT, maar duidelijk binnen IT, reeds aparte afdelingen opgericht om een brugfunctie richting ‘de’ Business te vormen. Vervolgens worden mensen uit deze afdeling gerekruteerd om de Product Owner-rol op zich te nemen en requirements te verzamelen en aan het Developent Team door te geven. De Product Owner-rol krijgt zo een proxy-invulling, wordt een tussenpersoon. De kloof met de echte beslissingscentra wordt iets kleiner, maar IT wil niet verder gaan wegens het behoud van controle over de rol. De wachttijden voor beslissingen en bijsturingen worden kleiner, de start-stop-situaties nemen licht af. Maar het blijft een moeilijke, want lange-afstandsrelatie.

We zien vaak dat in deze situatie de Business ook inzicht krijgt in het gevolgde proces, Scrum, en de rol van de Product Owner. Terecht groeit de behoefte om deze rol zelf op te nemen. De Business eist de rol op! Functionele, klant- en marktinzichten komen zo sneller tot bij het Development Team, en zorgen ervoor dat er meer focus is op het juiste product bouwen, en niet enkel een product op de juiste wijze bouwen. Echter, de afgevaardigde Business-persoon heeft niet steeds een breed mandaat.

De voordelen die met Scrum worden gerealiseerd worden nog groter als dergelijk mandaat en het bijhorende vertrouwen wel gegeven worden. Het is tevens een signaal dat de Business de rol ernstig neemt, het belang ervan inziet. Scrum ontstijgt de perceptie van het nieuwe IT-proces, en wordt een middel voor business agility, een instrument dat de organisatie toestaat sneller in te spelen op verandering, om sneller nieuwe, zakelijke kansen te ontdekken. Scrum wordt een tool die de organisatie holistisch helpt om business-, markt- en gebruikersnoden sneller en beter in te vullen.

De ultieme invulling van de rol is deze van de ‘mini-CEO’. ‘Mini-CEO’ is een metafoor die aangeeft dat er binnen de Business een persoon is die als een echte eigenaar van het product fungeert. Deze Product Owner heeft de volle bevoegdheid over het product, zowel budgettair als inhoudelijk. Deze persoon beschikt over alle contacten binnen de nodige departementen om het product vanuit een 360° perspectief te beheren; marketing, marktonderzoek, gebruikers, wettelijk, financieel. Deze persoon wijdt haar/zijn professioneel leven 100% aan het product, de ontwikkeling, groei en evolutie ervan.

De Product Owner, een functioneel beheerder?

Naarmate het inzicht van bedrijven in Scrum groeit, groeit ook de nood om te ontleren, om oude gewoontes en inzichten radicaal te bannen, en te vervangen door Agile inzichten.

De paradigma-overgang

De rol van ‘Functioneel Beheerder’ is geworteld in het oude denken. De opzet en het takenpakket van de Functioneel Beheerder zijn perfect. Op papier. In de praktijk werkt het niet. Te veel voorschriften, te veel detaillistische overhead, te methodologisch. Het voegt te veel zwaarte toe aan Scrum, legt zwaarwegende constructies op Scrum. Scrum is licht. Dat is de kracht van Scrum. Scrum bestaat uit een set minimale voorschriften. De rol van de Product Owner houdt engagement in, betrokkenheid, waarde-gedreven gedrag. Laat ons de schoonheid van deze nieuwe rol niet ten onder doen gaan in een aanpak die geworteld is in het oude, industriële paradigma.

Ik vrees dat het geloof dat de Product Owner-rol de aangewezen functie is voor de functioneel beheerder, behalve in de menselijke drang naar job-, status- en titelbehoud, geworteld is in de misvatting dat in Scrum de hoofdverantwoordelijkheid van de Product Owner de aanlevering is van uitgeschreven requirements. Echter, de Product Owner is in eerste instantie aansprakelijk voor het bestaan van een Product Backlog, en voor de sortering van alle items op de Product Backlog. Intelligente Product Owners doen voor het uitschrijven van de items een beroep op business-inzichten binnen het Development Team, bvb. via de skills die een business analist, of -wie weet- een functioneel beheerder, toevoegt aan het team.

Scrum zet het product centraal.

Scrum maakt abstractie van interne structuren en departementen. Scrum kent geen tweedeling Business-IT. Scrum zet het product centraal, en de waardeverhoging die via het product gerealiseerd wordt, zowel voor de organisatie als voor haar klanten, gebruikers en consumenten. Dit vereist intense en nauwe samen-werking tussen de rollen voor productontwikkeling die Scrum beschrijft. Gun het jezelf om alle voordelen te halen uit je keuze voor Scrum. Leg net dat beetje meer ambitie in je toepassing van Scrum dan enkel de termen van Scrum te gebruiken als de nieuwe verpakking voor een oude aanpak.

Laat de Product Owner vooral een echte producteigenaar zijn. Daar is de rol uiteindelijk ook voor bedoeld.

In 2013 publiceerde ik mijn boek “Scrum – A Pocket Guide (A Smart Travel Companion)”. Vanuit mijn werk bij Scrum.org heb ik een goed beeld van de mondiale verspreiding van Scrum. Het doet me plezier vast te stellen dat Nederland wereldwijd (!) koploper is qua invoering van Scrum. Dankzij de vele mensen, teams en organisaties waarmee ik mocht werken sinds 2010 is Nederland zowat mijn thuisland qua Scrum geworden. Het is een belangrijke drijfveer geweest om mijn boek te vertalen naar het Nederlands, zodat dit in 2016 nog beschikbaar kan zijn voor mijn feitelijke thuis (België) en mijn Scrum-thuis (Nederland).

Worrying interpretations of Scrum

At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:

Definition of Scrum (9)

It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:

Definition of Scrum (9?)

I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.

What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:

  • Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
  • Transparency is optimized when Product Backlog holds all types of work and requirements for the product. The format and syntax of Product Backlog items is open for the teams to decide over. User Stories are certainly not mandatory.
  • Burn-down charts were removed as mandatory from Scrum some years ago. It was replaced by the expectation that progress, regardless the format, is visualised on Product Backlog and Sprint Backlog.
  • If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a releasable Increment in a Sprint. It is the basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of Scrum.
  • Scrum has no prescription that the Daily Scrum needs to happen standing up. Scrum’s interest is making sure that the team’s progress toward the Sprint Goal is inspected on a daily base, in order to allow the team to adapt.
  • The Sprint Review is a collaborative event at which the Scrum Team and the stakeholders work together, and identify what is most important to work on next. Adding input from the stakeholders to the inspected, current state of the software (via the Increment), improves that decision. It is so much richer than a demo.
  • All events in Scrum are contained within a Sprint. Sprints take no more than 30 days, and often less. Not mentioning the Sprint as such (container) event might allow to overlook that aspect.

Definition of Scrum (11)