Tag: Scrum

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

Posted on by — 8 Comments

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)

 

Posted on by — 1 Comment

The Agile Paradigm (who said it was going to be easy?)

Grafx - Paradigm shift (Industrial)The domination of software development by a paradigm of industrial views and beliefs, a copy-paste of old manufacturing routines and theories, got us in a crisis. The attempts to overcome this crisis by fortifying the industrial approach are without result. The flaws and problems are huge, known and well documented. The crisis largely continues to this day.

Grafx - Agile ParadigmThe seeds of a new world view were already sown in the 1990’s, and resulted in 2001 in the formal naming of ‘Agile’. A turning-point in the history of software development. A new paradigm for the software industry was born; a paradigm that thrives upon heuristics and creativity. A paradigm that restores the respect for the creative nature of software development and the intelligence of its practitioners.

Yet, many say that Agile is too radical. They keep propagating, to this day, a gradual -if any- introduction of Agile practices into existing, traditional processes. Having witnessed several of such attempts, I am extremely skeptical about such a ‘gradual’ evolution, a slow progression to the Agile paradigm. Because:

  1. A gradual evolution only scratches the surface. New names are installed, new terms, tools and techniques imposed, but the fundamental thinking remains the same.
  2. The mentioned paradigms consist of fundamentally different concepts and ideas, and many are mutually exclusive. No meaningful introduction of Agile practices in an industrial paradigm is possible.

A gradual shift is factually a status-quo. The industrial paradigm remains. A permanent crisis is called upon us.

It requires honesty to accept the mismatch of the old ways, and courageous leadership to embrace the new ways.

Abandoning the old thinking will take time. Scrum helps. Its distinct rules help in getting a grip on the new, Agile paradigm. The limited prescriptions allow immediate action. They allow developing new ways of working; through discovery, experimentation-based learning and collaboration. It is worthwhile the giant leap.

I wish you a 2016 of determination and improvement. I congratulate you with the hard work you will have performed in a year from now.

(Note: much of the above was copied, with some editing, from my book “Scrum – A Pocket Guide“, providing context to my description of the Scrum framework, its rules and roles, and their purpose)