Please find herewith a short movie in which I describe what Agile is.
It is in Dutch with English subtitles. It was created for Xebia with the Xebia marketing wizzy Ted Stravers, and recorded and processed by Higher View:
Tag: Scrum
Wat/what is Scrum?
Please find herewith a short movie in which I introduce the Scrum framework. It is in Dutch with English subtitles. It was created for Xebia with the Xebia marketing wizzy Ted Stravers, and recorded and processed by Higher View:
De kernwaarden van Scrum
Scrum is een samenhangend framework van regels, rollen en principes die mensen en organisaties ondersteunen, maar dat afhankelijk van de exacte situatie en context ingevuld kan worden. Scrum is een expliciet empirisch proces omdat alleen een empirische aanpak in complexe omgevingen werkelijke controle biedt. Scrum is geënt op een aantal kernwaarden. Alhoewel deze waarden op zich niet uniek zijn voor Scrum, geven ze toch richting. Ze oriënteren en onderbouwen gedrag, acties en binnen Scrum genomen beslissingen.
In een context van Scrum zouden alle beslissingen die we nemen – alle stappen die we wel of niet zetten, de manier waarop we het spel van softwareontwikkeling spelen, de invulling die we geven binnen het framework – de kernwaarden moeten versterken, niet ondermijnen of omzeilen.
Commitment
De Engelse definitie van ‘commitment’ is: the state or quality of being dedicated to a cause, activity, etc. Vertaald is dit: ‘een toestand van toewijding of engagement voor een doel, een activiteit, enzovoort’. Een illustratie van deze definitie is de uitspraak van een trainer van een sportploeg: “Ik kan mijn spelers op het gebied van commitment niets verwijten.”
Deze definitie vertelt exact waarom ‘commitment’ als een kernwaarde in Scrum is opgenomen. Commitment gaat over inzet, toewijding en inspanning, veel meer dan over het behalen van een vooropgesteld resultaat. Het begrip werd echter vooral als dat laatste geïnterpreteerd, niet in het minst omdat in de context van het verleden vaak werd gesteld dat een team zich moest committeren aan de scope voor een Sprint. Vanuit het oude, industriële denken werd dit al snel gezien als een belofte dat de geselecteerde scope voor een Sprint per se moest en zou worden opgeleverd. ‘Commitment’ werd ten onrechte vertaald als een na te leven contract.
In de complexe, creatieve en innovatieve wereld van softwareontwikkeling is een belofte dat scope, budget en tijd perfect ingeschat, gepland en opgeleverd kunnen worden niet mogelijk – zelfs niet voor een Sprint. Er zijn te veel variabelen en parameters die een toegezegd resultaat, tijdens het proces, nog beïnvloeden.
Om de oorspronkelijke bedoeling van het woord en de context van empirische procescontrole versterkt weer te geven, werd ‘commitment’, wat betreft de geselecteerde scope als resultaat van de Sprint Planning, vervangen door ‘forecast’. Echter, commitment is en blijft een belangrijke kernwaarde van Scrum.
Alle individuele spelers committeren zich aan het team: aan kwaliteit, aan samen-werking en aan voortdurend leren en bijsturen. Er is commitment om hard te werken en te doen wat mogelijk is, elke dag opnieuw. Er is commitment aan de Sprint Goal, commitment aan professioneel gedrag. Er is commitment aan zelf-sturing, aan de principes beschreven in het Agile Manifesto. Men committeert zich om werkende software op te leveren en er is commitment aan voortdurende openheid voor verbeteringen. Een team committeert zich aan de definition of Done, aan de regels van het Scrum framework. Er is commitment om waarde op te leveren, om werk daadwerkelijk af te ronden. Er is commitment aan volle transparantie, evenals commitment om elke status quo ter discussie te stellen.
Focus
In de combinatie van de rollen binnen Scrum en hun aansprakelijkheid zit een balans. Het complementaire karakter ervan versterkt niet alleen de noodzaak van samen-werking, ze zorgen er ook voor dat iedereen focus kan houden op een specifieke expertise.
Het principe van time-boxing binnen Scrum moedigt spelers aan om zich te concentreren op wat nu het meest belangrijk is, zonder te veel afleiding door wat misschien, wie weet, belangrijk zou kunnen zijn in een verder onbepaalde toekomst, ooit. Men focust op de actueel beschikbare kennis, nu. In de context van eXtreme Programming werd hiervoor de afkorting YAGNI in het leven geroepen: ‘You Ain’t Gonna Need It’. Als je nu onvoldoende zekerheid hebt over een verwachting of behoefte, negeer die dan, gedraag je alsof je die niet nodig zult hebben. De toekomst is een onzeker gegeven. Het is belangrijker in het heden ervaring en lering op te doen, die je later helpt om beter met de toekomst om te gaan, hoe die er ook uit ziet. Teams hebben een focus op afwerking, oplevering, en al het werk dat hiervoor te doen valt. Teams zoeken naar de eenvoudigste oplossing, de oplossing die op de eenvoudigste wijze tegemoet komt aan de huidige en bekende verwachtingen.
Dankzij de Sprint Goal heeft een team een focus, een oriëntatiepunt voor de volgende vier weken of korter. Binnen die periode zorgt de Daily Scrum ervoor dat mensen gezamenlijk focus houden op de dagelijkse werkzaamheden die hen naar die doelstelling helpen.
Openheid
De empirische procesfundamenten van Scrum vereisen transparantie, wat op zich openheid en eerlijkheid impliceert. De gecommitteerde spelers, die ook verantwoordelijk zijn voor de regelmatige inspecties (annex aanpassingen), hebben een beeld nodig van de werkelijke situatie om geen zinloze aanpassingen door te voeren. Aanpassingen op basis van een gefingeerde werkelijkheid leiden alleen maar tot meer leugens. Alle spelers delen dan ook openlijk de werkelijke status van hun werk, hun voortgang, hun inschattingen, hun problemen en hun moeilijkheden. Alle spelers staan echter ook open voor het feit dat softwareontwikkeling gebeurt door en voor mensen. Mensen zijn geen ‘resources’, robots of vervangbare machineonderdelen.
De spelers tonen openheid voor samen-werking met andere disciplines en functies, openheid om functieomschrijvingen te overstijgen. Ze tonen openheid naar de stakeholders en de bredere omgeving. Ze delen openlijk feedback en geleerde lessen. De spelers in Scrum staan open voor verandering, aangezien ze erkennen dat hun organisatie en de wereld waarin zij en hun organisatie opereren voortdurend veranderen – vaak erg onverwacht en onvoorspelbaar, maar wel voortdurend.
Respect
Binnen het bredere ecosysteem dat ontstaat rond Scrum heerst een sfeer van respect: respect voor mensen, voor de andere spelers en de andere teams; respect voor hun inzichten, kennis en ervaring, respect voor hun afkomst en persoonlijke achtergrond. De spelers respecteren – en waarderen – diversiteit als bron en sleutelelement voor nieuwe en mogelijk conflicterende ideeën. Ze hebben respect voor andere meningen.
De spelers van de teams tonen respect voor de omliggende organisatie door zich niet te gedragen alsof ze op een afgelegen eiland werken. Er is respect voor klanten, gebruikers en hun veranderlijke verwachtingen of ideeën. Teams tonen respect voor sponsors en geldschieters door geen features te behouden die toch nooit gebruikt worden, en die uiteindelijk slechts de onderhoudskosten van de software verhogen. Teams tonen respect door geen tijd, inspanningen en budget te verkwisten aan taken, producten of productonderdelen die geen waarde hebben, niet gewaardeerd worden, noch door de gebruikers, noch door de organisatie. Ze respecteren gebruikers door de problemen die deze ondervinden, op te lossen. Teams tonen zich respectvolle professionals door geen crappy software in productie te zetten.
Alle spelers respecteren de regels van het Scrum framework en de aansprakelijkheden die daaruit voortvloeien.
Moed
Alle spelers tonen moed door geen software te bouwen waar niemand op zit te wachten. Moed zit vervat in de onderkenning dat requirements nooit perfect zijn, en dat geen plan ooit de complexe werkelijkheid kan voorspellen.
Men toont moed als veranderende inzichten, meningen en verwachtingen als een bron van inspiratie en innovatie worden beschouwd, in plaats van als een bron van ergernis. Het vergt moed om tijdelijke opleveringen uit te voeren, software te tonen die niet volledig en perfect lijkt, maar wel waarde levert of toevoegt. Alle spelers tonen moed door op elk gewenst moment de noodzakelijke informatie te delen die het team en de organisatie vooruithelpt. Spelers zijn moedig als ze erkennen dat niemand perfect is. Er is de moed om meer of minder radicaal van richting te durven veranderen, om een ander idee dan het eigen idee te omarmen, moed om zowel risico’s als voordelen te delen. Het vereist moed om de oude, valse zekerheden los te laten.
De spelers tonen moed als ze Scrum correct toelichten als een empirisch proces, vanuit de moed om toe te geven dat aanpasbaarheid de enige wijze is om met complexiteit om te gaan. Ze hebben de moed om de kernwaarden van Scrum te leven en te beleven, om een beslissing te nemen, tot actie over te gaan, niet tot een impasse verleid te worden, en vervolgens de moed tonen om genomen beslissingen op basis van ervaring opnieuw kritisch tegen het licht te houden en bij te sturen.
Noot:
Bovenstaande tekst is een extract uit mijn boek “Scrum Wegwijzer” (2016, oa. verkrijgbaar via Managementboek.nl). Dit is de Nederlandse vertaling van mijn “Scrum – A Pocket Guide” (2013, oa. verkrijgbaar via Managementboek.nl).
Announcing the “Scrum Taschenbuch”
After attending my PSM class in June 2016, Uwe Schirmer asked me whether he and Peter Götz could translate my book “Scrum – A Pocket Guide” to German. Having felt the difficulties of producing a proper-quality translation of my book in Dutch (my mother tongue) in early 2016, I warned them. To no avail. Fortunately. I am glad they persisted. In March 2017 the translated work will be released as “Scrum Taschenbuch (Ein Wegweiser für den bewussten Entdecker)” by Van Haren Publishing. Find it at their webshop or at Amazon.de.
Uwe and Peter were so kind to create following introduction, in German and in English:
(Deutsch) Es gibt eine Frage, die wohl jeder Trainer unabhängig vom Thema schon oft in seinen Trainings gehört hat: “Welches Buch kannst Du mir zu dem Thema empfehlen?“ Die Frage ist nicht immer leicht zu beantworten. Für Scrum haben wir gerne Gunthers Buch empfohlen. Mitunter kam dann die Frage „Gibt es das Buch auch auf Deutsch?“ oder „Gibt es ein anderes gutes Buch auf Deutsch?“. Die Antwort auf beide Fragen war jeweils „Leider nein.“
Als Uwe in 2016 bei Gunther in einem Train the Trainer Kurs für den Scrum Master war, musste er ihn deswegen fragen, ob eine Übersetzung in Arbeit oder wenigstens geplant war. Gunther erzählte, dass es bereits Versuche einer Übersetzung gegeben hatte, dass diese aber immer im Sande verlaufen waren. Also fragte er Gunther, ob Peter und er die Übersetzung machen dürften.
Es war eine interessante Erfahrung. Wir haben im Juli 2016 mit der Arbeit begonnen. Natürlich organisiert in Sprints mit einem Taskboard – auch wenn die Sprintlänge nicht ganz der Empfehlung aus dem Guide entsprach. Nach einigen intensiven Iterationen und inhaltlichen Refinements haben wir im Februar 2017 vom Verleger die gesetzte Fassung erhalten. Es waren 8 intensive Monate. Die Arbeit am Buch hat uns großen Spaß gemacht. Wir mussten uns nie zum Weitermachen zwingen – der gesunde Gruppendruck in unserem Mini-Team hat gereicht. Es war im Gegenteil sehr lehrreich, sich einmal auf diesem Level mit dem Thema auseinanderzusetzen und den Inhalt und die Sprache ins Deutsche zu übertragen.
Wir haben eng mit Gunther zusammengearbeitet und einige Passagen und ihre Bedeutung mit ihm diskutiert. Unsere Reviewer Thomas Barber, Jean Pierre Berchez, Dominik Maximini und Anke Scheuber haben großartige Arbeit geleistet und uns sehr wertvolles Feedback gegeben. Auch unsere professionelle Lektorin Monika Dauer konnte die Qualität des Ergebnisses noch wesentlich verbessern. Vielen Dank noch mal für Eure Arbeit und Unterstützung. Ohne Euch hätten wir nicht diese Qualität erreicht.
Wir hoffen, dass wir mit unserer Übersetzung etwas zur weiteren Verbreitung und Festigung von Scrum in Projekten und den Köpfen der Leute beitragen können. In diesem Sinne (schamlos bei Gunther geklaut): (Start or) Keep Scrumming.
(English) There is one question almost every trainer – independent of the topic at hand – will have to answer in his trainings: “What book can you recommend for this topic?” The question is not always easy to answer. For Scrum we liked to recommend Gunther’s book, which sometimes lead to the question “Is there a German version?” or “Is there another good book in German?” The answer always was “Unfortunately not”.
So when Uwe was in one of Gunther’s Scrum Master Train the Trainer courses in 2016 he had to ask him if there was a translation in progress or at least planned. Gunther said that there have been some attempts of translating the book, which had never been finished. So he asked Gunther if we (Uwe and Peter) could translate it.
It was an interesting experience. We have started work in July 2016. Of course we worked in Sprints using a task board – even though the Sprint length did not follow the Scrum Guide recommendation. After a couple of intensive iterations and content-wise refinements we have received the typeset version from our publisher. These have been 8 intensive months. Working on the book was big fun for us. We never had to force ourselves to continue working – the peer pressure in our tiny team was enough. And we also learned a lot and had many insights while working on this topic in such an advanced way, translating content and language into German.
We collaborated tightly with Gunther and discussed passages from the book and their meaning with him. Our reviewers Thomas Barber, Jean Pierre Berchez, Dominik Maximini and Anke Scheuber also did great work and gave us very valuable feedback. So did our professional editor Monika Dauer, who was able to improve the end result’s quality a lot. Thank you very much for your hard work and support. Without you we would not have been able to achieve such quality.
We hope that we can help spread and strengthen Scrum in projects and people’s heads. On that note (stolen from Gunther): (Start or) Keep Scrumming.
Introducing the Scrum Caretakers initiative
Discovering what drives me is a never-ending journey (1). Starting with eXtreme Programming and Scrum in 2003 was a life changing experience.
My work for different consulting companies (2001-2012) was spent on Scrum. I authored a pocket guide to Scrum in 2013. I went to work with the Scrum.org team and Ken Schwaber in 2013. In 2016 I decided to further my journey of Scrum on an independent basis.
Discovering what drives me is a never-ending journey (2). The stable essence is that:
I care about people. I care about Scrum. I care about helping people create better products and a more humane workplace through Scrum. I care about helping people re-imagine their organisations.
I detached myself from any fixed organisational structure. Of the tangible goals I had in mind, one was to start a community initiative for Scrum across Belgium and the Netherlands, the Scrum Caretakers.
Belgium is where some of my core insights in Scrum were created (2003-2010). Since 2010 however I have worked primarily in the Netherlands. Scrum is completely under-used in Belgium. Scrum is huge in the Netherlands, and splintered. I initiated the Scrum Caretakers community, currently already materialised as a meet-up group.
Anyone can join, from any place in the world, and have access to whatever it is we create. Actual get-togethers are organised alternately in Belgium and the Netherlands for the time being.
Start optimizing your Scrum (stop filling positions)
Scrum is a minimal, yet sufficient framework for self-governing product eco-systems to create, evolve and maintain complex products.
Scrum defines the in and the out of the system:
- The system works on ideas, suggestions and options that are converted into Product Backlog for reasons of transparency and manageability.
- The system produces a valuable Increment of product, a release candidate, no later than by the end of a Sprint.
Scrum defines 3 complementary, peer accountabilities to balance all activities required for modern, Agile product development:
- A Development Team converts the desirements ordered via the Product Backlog into valuable Increments of product in no more than a Sprint’s time, where a Sprint is no more than 4 weeks and often shorter.
- A Product Owner optimises the flow of value, balancing innovative, novel ideas against desires, wishes, suggestions and needs stated by the user base, the stakeholders, the organisation, the teams.
- A Scrum Master fosters an environment in which the Product Owner, the Development Team, and the organisation get the most out of Scrum, using many possible management techniques.
The system called Scrum might consist of multiple teams creating, evolving and maintaining one product. It shouldn’t supersede the minimalism of Scrum. The system works off of one Product Backlog and creates valuable product Increments through the accountabilities foreseen by Scrum.
The context of multiple teams creating one product is often interpreted as an obligation for every team to be a Scrum Team, and every team to be a complete and full-time feature team.
Scrum doesn’t define accountabilities as an excuse to fill positions. Scrum thrives on understanding the accountabilities rather than on blindly filling positions and claiming titles. Scrum doesn’t instruct a uniform, detailed layout of the internals of your system.
Use Scrum to optimise the whole. Optimise your Scrum. Employ Scrum to build a product with multiple teams. Your system is expected to be a feature system, a system capable of producing valuable Increments of product, no later than by the end of a Sprint, regardless the setup of the teams. The accountabilities are expected to be fulfilled, regardless the number of people it takes throughout your system.
Minimally, for n teams working on one and the same product:
- There are n Development Teams, where the composition of each team is likely to depend on your context. Ultimately, the combined teams need to be able to produce valuable Increments while maintaining the integrity of the product. They self-organise to optimise.
- There is 1 Product Owner, and most likely a distribution of product ownership. The form of the distribution depends on your context. Ultimately, the flow of product value needs to be unhampered, frequent and targeted.
- There are 1-n Scrum Master(s), depending on your context. Ultimately, the eco-system and the environment in which it operates need sufficient and sufficiently provocative support, guidance, protection and coaching.
Frameworks like LeSS, Nexus and Scrum@Scale offer diverse strategies at scale that might help in your situation if you are unable to keep your system minimal. Consider your specific needs and opportunities to optimise carefully.
Scrum, a forward looking observation (The 3rd Scrum Wave)
All events organised in Scrum are designed to be forward looking. Adaptation follows inspection. Feedback from observable results is meaningless if not applied. All assessments, evaluations and inspections we undertake in Scrum primarily serve the purpose of working on the most valuable future. Scrum inspires us to shift our perspective from solely judging the past and checking actuals towards planning and innovating for an unknown future. In short, focused iterations we reflectively shape the future while embracing unanticipated surprises.
This is the spirit through which we act. We act on forward looking observations. This is the spirit through which we can consider the future of Scrum. Rather than glorifying the past of Scrum, we anticipate the value ahead. We aim at surfing the wave. We shape the wave.
THE 3RD SCRUM WAVE IS RISING. WILL YOU SINK? BARELY SWIM? OR WILL YOU SURF?
‘Agile’ started crossing the chasm as from 2005-2006, much enabled by the increasing popularity of Scrum. The Agile way of Scrum became an accepted way of creating and delivering products. In the subsequent 1st Scrum wave a growing number of teams discovered the first-level benefits of Scrum, albeit predominantly from an IT perspective. Organisations moved away from endless sequential phases and gateways, and began exploring the advantages of iterative-incremental delivery. The 1st Scrum wave was mainly about adopting Scrum, a first encounter, the start of a journey of discovery.
In the slipstream of the 1st Scrum wave, sub-groups and derivative movements took off, new movements and methods were invented, introduced, launched, and often disbanded again. Divergence in itself is great, unless the overall result is dilution and opacity. Rather than into variety, the divergence turned into scattering, even with Scrum being the actual standard, even with the definition of Scrum being formalised by its co-creators in 2010 in the Scrum Guide. A bowling alley of problems to be addressed appeared, a wide range of pins. Some pins appeared to be left unaddressed by common Scrum implementations. Some pins were raised to challenge presumed weak spots of Scrum, challenges presented as unaddressable through Scrum. On top of this slow evolution, 2010-2011 saw a seemingly sudden desire of large organisations to transition to this ‘Agile’ thing, fast. The tone for the 2nd Scrum wave was set, a wave of diverging Scrum. Scaling became a thing. Parts of the Scrum terminology became standard vocabulary, but at the same time the tangible rules and principles underlying the Scrum framework were pushed to the back, their purpose snowed in under resurrected needs for layers, titles, roles and structures, at scale.
2016-2017. It takes time to replace the industrial views on the creative act of product delivery. Rat races continue, Scrum is underused as a way out. Too often still the organisational waste, abuse and impediments, ruthlessly highlighted by Scrum, are ignored. Yet, more people and organisations than ever continue their quest to stop more hamster wheels, to create more room to reflect, to improve, to innovate. The 3rd Scrum wave is fuelled by the desire, the drive for rhythm, focus and simplicity. Agile and Scrum are recognised as two inseparable ingredients for healthier and more humane ecosystems that deliver better products. The awareness keeps growing that it starts and ends with people, not with procedures, tools or games. People embrace the Scrum values as a catalyst to re.imagine their Scrum, to re.vers.ify their organisation. Convergence appears on the horizon, where the rage of scattering, where the tornado starts calming down.
We sow seeds. We fertilise the grounds. We help converge product delivery initiatives in a Scrum Studio. We help the shift from traditional to empirical management. We envision a future, networked structure, a nervous system of product hubs and distributed leadership. The 3rd Scrum wave is about enacting Scrum, discovering how the well-defined and clearly stated framework of Scrum leaves plenty of room for variation, a diversity of strategies to employ Scrum.
In 2016 Scrum turned 21. We have come a long way. We look forward. We walk on. We re-vers-ify. We re-imagine our organisations.
THE 3RD SCRUM WAVE IS RISING. WILL YOU SINK? BARELY SWIM? OR WILL YOU SURF?
Re.vers.ify (essential introduction)
By the end of 2016, Co-learning organised a webinar about “Re-thinking the organisation”. I feel humbled for sharing my views next to those of the other presenters James Priest (Sociocracy 3.0) and Jürgen De Smet (founder of Co-learning and collaboration architect).
I introduced “re.vers.ify“, the consolidation of over a decade of experience, ideas, beliefs and observations of Scrum. In the recording of my part you will find a fair, 15-minutes summary of my essential and current thoughts and drivers:
Re.vers.ify is an act, an act of simplicity, rhythm and focus. Re.vers.ify is a way for people to re.imagine their Scrum, intentionally emerge a Scrum Studio and -ultimately- re.imagine their organisation.
- Find my presentation at SlideShare.
- Find a blog note and the full recording at Co-learning
Speaking Engagement 2017 (re-vers-ify)
I’ve been asked to go present at some events in 2017. It got me into more clearly describing what my speaking engagement will be about. Download the PDF “2017 Speakers Topic Gunther Verheyen re-vers-ify“.
I foresee spending much of my energy on introducing “re-vers-ify” to the world, a way for people to re-imagine their organisation by re-imagining their Scrum.
There are various fascinating and -probably- valuable strategies available to scale Scrum. They are however all situational. I help people and organisations move forward, regardless how long they have or have not been adopting Scrum, or the scale at which they operate. I always introduce the simplest and most core basics of Scrum first. I highlight their purpose and how they serve business agility. I find that it enormously draws on people’s imagination but it also excites them greatly; identifying a product as the application domain of their Scrum, having a Product Owner with the ability and mandate to act as a Product-CEO, producing a Done version of product by the end of every Sprint (regardless the number of teams).
I have observed how imagination can set an organisation apart. Imagination often distinguishes innovative from lagging organisations. Any organization can be re-imagined, re-vers-ified, to exploit its intrinsic potential to innovate and lead.
The many adaptations possible through Scrum provide a safety net, actually. Scrum thus creates room for action and discovery. Organisations can re-imagine their Scrum to converge their product delivery into a Scrum Studio. Over time divisions dissipate into a structure of product hubs interconnected through purpose and distributed leadership. Creativity and innovation emerge. People, teams and the organisation prosper.
I have consolidated over a decade of his experience, ideas, beliefs and observations of Scrum in re-vers-ify. In my upcoming talks I will introduce how the deliberate emergence of a Scrum Studio is the current way forward to re-vers-ify.
Re-vers-ify is an act of simplicity, rhythm and focus. Simple, not easy.
On 23 December 2016 I lift a tip of the veil at a webinar I am participating in together with Jürgen De Smet (collaboration architect at Co-learning) and James Priest (Co-Founder of Sociocracy 3.0)
Looking forward to catching up with you in 2017.
Gunther
Agility, actually (is an organisational state of being)
Agility is an organisation’s state of high responsiveness, speed and adaptiveness. Agility is an organisation’s state of continual adaptation and optimisation, a state in which each status quo is challenged, by our own will or by external turbulence.
Agility is a state that is a natural fit for the unpredictability so common to the work of complex product delivery and to the markets that organisations operate within. However, it requires accepting that the work is unpredictable, a mental barrier to overcome. Agility is why teams and organisations adopt Agile processes. From that adoption agility increases, a new of working emerges, new organisational ways of learning, improving and constant adaptation, and restored respect for people, re-humanisation.
Scrum helps. The distinct rules of Scrum help. Scrum is actionnable. Agile and Scrum, actually, are two inseparable ingredients in a complex product delivery ecosystem. Scrum can be your foundation for agility. Sprints are at the heart of business agility in generating a regular flow of improvements, updates, learnings and various other sources of value. Organisations discover, experiment and deliver on opportunities from an end-to-end perspective in the fastest possible way. People develop new ways of working; through discovery, experimentation-based implementation and collaboration. They enter this new state of being, this state of agility; a state of constant change, evolution and improvement. Re-humanisation takes place. Innovation surfaces again.
The path of increasing agility via Scrum is inevitably bound to be a cobblestone path. It might take some time to accept that agility starts and ends with people, not with procedures or tools. It might take some time to accept that agility takes time, that agility need not be analyzed, designed and planned. It might take some time to accept that agility occurs:
- Agility can’t be planned;
- Agility can’t be dictated;
- Agility has no end-state.
A time-planned way to become (more) agile introduces unfavourable expectations. Introducing Agile methods to increase agility causes significant organisational change. Several existing procedures, departments and functions will be impacted. There is no way of predicting what needs will be encountered at what point in time, how these will be dealt with and what the exact outcome will be in order to control next steps. It is a highly complex and unpredictable journey. There is no way of predicting the pace at which the state of agility will take root and spread.
Scrum and agility are much more about behaviour than about (following) a new process. A decision to adopt Scrum is a decision to leave the old ways behind. It is not only about accepting but about celebrating the fact that agility is living the art of the possible. It requires the courage, honesty and conviction of acting in the moment, acting upon the reality that is exposed by iterative-incremental progress information. Agility is about doing the best possible at every possible moment, constrained by the means we have and facing the constraints. A time-planned way ignores the essence of Scrum and Agile, that of dealing with complexity via well-considered steps of experimentation and learning. Time-plans simply extend the old thinking. In general a plan will even slow down the overall increase of agility, because serious delays and waiting times are incorporated.
Time-plans create the illusion of deadlines and a final end-state. Agility has no end-state.
Living the art of the possible engages people and accelerates a transformation as it shapes the future, thrives upon the future and what the future might bring. It’s a bright future for organizations that have the vision, the determination and the dedication.
These basic truths must be in the hearts and minds of every person managing, guiding, facilitating, hoping or striving for agility. And even then, it takes time for agility to settle in the hearts and minds of the people impacted. After all, people have been instructed in the wrong behavior of the industrial paradigm for 15 to 20 years, or more. Agility starts and ends with people, not with tools, procedures or games.
