Category: Scrum Caretakery

Posted on by — 2 Comments

Challenging Sprint Retrospectives

An essential question in the use of Scrum seems to be ” How can we make our (Sprint) Retrospectives more fun? ”

When digging a bit deeper, I always end up puzzled. I always end up wondering about the value and the level of team engagement. I wonder what sort of fun they are looking for. I wonder about the understanding of Scrum. I wonder about the subject of inspection and adaptation at their Sprint Retrospective. I wonder what purpose they are using Scrum for.

I wonder because Done Increments are at the heart of Scrum, crucial to optimally use empiricism as a way to increase agility. I wonder about the real purpose of a Sprint Retrospective when so few teams are able to actually deliver releasable versions of product, no later than by the end of a Sprint, Sprint after Sprint after Sprint. And that inability only increases proportionally, if not exponentially, with the number of teams when delivering one product.

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint.

Not achieving that purpose today is not failure. Failure is to stop moving towards that purpose. Failure is to stop inspecting and adapting towards that purpose. Not creating Done, releasable versions of product means sub-optimal use of Scrum. The danger is to stop challenging that status-quo.

Understanding that Scrum Masters are all about helping teams and organizations in understanding and enacting Scrum, following might be a great way to start your next Sprint Retrospective:

  • Scrum Master: “Have we delivered a Done, releasable version of product this Sprint?”
  • Team: “No.”
  • Scrum Master: “What can we do about that?”

Next to checking in with the team on their sense of engagement, how is that to kick off a professionally challenging Sprint Retrospective? Wouldn’t you expect that to initiate some serious reflections? Wouldn’t you expect the team to start initiating improvements that will help them and the organization get more from employing Scrum? Does that not lead to considering what actually is defined as “Done”, and what is needed to achieve that state of work and quality?

Committed, connected and engaged people will have serious conversations about:

  • How to increase effectiveness through collaboration, autonomy & self-organization?
  • What skills & knowledge are needed and (un)available?
  • Are our development practices & standards appropriate and up to par?
  • How are our access, knowledge and use of infrastructure, tooling & automation?
  • What are the quality standards & guidelines that we should take into account?
  • What are the toughest Impediments? Does our Scrum Master know? Can we help in the removal of them?
  • How can we increase our focus? Can we stop attending external meetings? How can we eliminate other forms of work of low value?

How is that as a start for identifying some ‘fun’ experiments and improvements in the next Sprint?

I that doesn’t engage people and appeal to their sense of professionalism, check what is needed to increase the level of team engagement. If reflecting, considering and investigating such questions doesn’t engage people, find out what is killing engagement.

I wish you fierce, focused and engaged Sprint Retrospectives. It’ll be seriously fun. Fun and happiness are important. Engagement however is the key. Fun is no replacement for team engagement. Fun techniques are no replacement for serious conversations.

Posted on by — 1 Comment

A simple framework for complex product delivery (in 3 minutes)

verheyen-gunther-scrum-a-pocket-guide-2016By the end of November 2016 the 5th re-print of my book “Scrum – A Pocket Guide” will be available, with a re-designed cover.

I wanted my book to reflect the simplicity of Scrum, a simple framework for complex product delivery.

As part of this re-print my publisher Van Haren Publishing kindly asked me to create a short video introduction to Scrum, of preferably no more than 3 minutes. The time constraint helped me focus. It helped me keeping it simple, just like Scrum.

What I say in the video was based upon following prepared text:

Scrum is a simple framework for complex product delivery.

1/ Scrum has been around for a while. It was officially introduced to the general public in 1995. Since then, as more and more people, teams and organizations started using Scrum, Scrum became the most adopted method for agile product delivery. At the same time, Scrum grew lighter and lighter, thereby, in a way becoming less and less complete and ‘perfect’. Prescribed practices and techniques were gradually removed from the official definition of Scrum, The Scrum Guide. Scrum turned into the framework it was always designed to be, a framework upon which people devise their own solutions, create their own working process. A Product Owner brings product ideas to a Development Team. No later than by the end of a Sprint the team turns these ideas into releasable versions of product. Sprints take no more than 4 weeks, and are often shorter. The Scrum Master creates and fosters an environment for such self-organised and creative collaboration to happen.

Scrum is a simple framework for complex product delivery.

2/ Scrum not only restores simplicity, Scrum brings empirical process control. All elements of Scrum support the process of regular inspection and adaptation. Empiricism is the way for people, teams and organisations to deal with the complexity, uncertainty and unpredictability typical to product development. The Scrum events set the frequency of the inspection and adaptation process. The artefacts provide transparency to all information required. As all waste has already been removed from Scrum, the framework is highly cohesive. Every element has a clear ‘why’, a clear purpose. Omitting any core elements breaks the cohesion, and is likely to cover up existing problems and impede the transparency required to continuously adapt, to be agile.

3/ Scrum, when employed well, allows a continual discovery of what is possible, what is not, of what works, what doesn’t work. Throughout this journey of discovery, the value of the work done is incrementally optimised. Product is regularly delivered to the market. It is extremely helpful to have a simple, yet proficient, tool like Scrum in highly unstable circumstances.

4/ Employing Scrum is a journey in itself. Mastering Scrum takes practice and time.

Posted on by — 7 Comments

A simple framework for complex product delivery (in 100 pages)

From March to June 2013 I created the book “Scrum – A Pocket Guide (A Smart Travel Companion)” for Van Haren Publishing (Netherlands). Although I had already written much about Scrum, it was really, really hard work. I wanted the book to be about its subject, not its writer. I wanted the book to be concise, yet complete. I wanted the book to reflect the simplicity of Scrum, in its appearance, tone, language, expressions, sentences.

Since its initial publication (November 2013) my pocket guide to Scrum was re-printed 3 times (January 2014, June 2014, November 2015). In April 2016 my Dutch translation was published as “Scrum Wegwijzer (Een kompas voor de bewuste reiziger)”. And two friends of Scrum are currently going through the really, really hard work of creating a German version, which will probably be named “Scrum Taschenbuch” and be available in 2017. And somewhere along the road I experimented with setting up a Facebook page for my book.

This is beyond any expectation I might have had handing in the first manuscript half way through 2013. I am totally humbled, and sometimes overwhelmed, by the continual appreciation of the book’s buyers and readers.

verheyen-gunther-scrum-a-pocket-guide-2016I want to share that a 5th print of the English version is on its way (end November 2016), holding a NEW COVER. The content of the book hasn’t changed. I was fortunate to have described the Scrum Values already in my book. The only change was the update to my personal history, as is also reflected on my website.

Thank you, readers. Thank you, publisher. Thank you, fellow Scrum Caretakers!

To support the update of my book, my publisher asked me to do a 3-minutes introduction to Scrum, a simple framework for complex product delivery. The time constraint helped me to keep it simple, just like Scrum.

Posted on by — 1 Comment

Thoughts on procurement, buyers and alike

I have spent most of the 24-years of my professional life in IT, consulting and software development. Maybe that is long enough to have and share my stance on procurement, buyers and alike practices.

Every organisation has the right to not work with me.

Every organisation has the right to deem the value potentially realised through our collaboration as insufficient.

Every organisation should absolutely consider the return expected on spending money on my expertise, skills and effort. Even if the consequence is to not work with me.

My observations indicate that the commonly applied strategies by procurement, buyers and alike are different. Common practice is to belittle my expertise, change the estimates on the work needed and blindly cut my proposed day rate.

I have no sales machine to counter such strategies. Fortunately, as that would just maintain the ridicule. I do preserve the right to push back, regardless the impact on any chances to collaborate. I preserve the right to not being treated like a discountable commodity. We probably have very different definitions in mind when this is labeled as “not professional”.

Personally, I would rather starve (so to speak) than give in to the humiliating and belittling line of approach commonly seen in sales and buying procedures.

Warm regards
Gunther

ps. Thank you for caring, but that ‘starving’ part was intended figuratively. There are plenty of good folks out there that, somewhat surprisingly maybe, do want to properly partner with me.

Posted on by — Leave a comment

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.

Posted on by — 1 Comment

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.

Posted on by — 2 Comments

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

Posted on by — Leave a comment

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.
Posted on by — 4 Comments

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).