Le parole di Scrum (Italian version of the Scrum glossary)

I am excited to announce that Michael Forni is working on an Italian translation of my book “Scrum – A Pocket Guide”. We aim at releasing “Scrum – La Guida Tascabile” (working title) in 2018, hoping it brings value to many Italian Scrum practitioners.

I took the opportunity to revisit my original text (dating from 2013). It resulted in small revisions and an update to my Scrum Glossary. Michael and I hereby share the translation of the latter as “Le parole di Scrum“. We are more than happy to evaluate any suggestion you might have.

Note: in the translation process of the Scrum vocabulary and definitions, besides the obvious care in avoiding to change or alter the well-consolidated words of Scrum, we also considered the well-spread wording among the Agile community and the Italian version of the Scrum Guide.

Nota: per la traduzione della terminologia Scrum, ferma restando l’inopportunità di modificare o storpiare i consolidati sostantivi caratterizzanti del framework, si è tenuto in debito conto il lessico oramai d’uso comune tra i praticanti di Scrum, nonché le traduzioni delle varie versioni in italiano de “La Guida a Scrum”.

  • Daily Scrum (sost. m.): evento a cadenza giornaliera limitato nella durata (time-boxed) a non più di 15 minuti – o meno – necessario a ri-pianificare il lavoro di sviluppo durante uno Sprint. Questo evento serve al Development Team per condividere i progressi giornalieri, pianificare il lavoro delle 24 ore successive e per aggiornare lo Sprint Backlog di conseguenza.
  • Definizione di “Fatto” (Definition of Done): insieme di elementi attesi e qualità che un prodotto deve dimostrare di avere affinché lo rendano rilasciabile, ad esempio compatibile ad un eventuale rilascio agli utenti del prodotto.
  • Development Team: gruppo di persone responsabili di organizzare e realizzare tutto il lavoro di sviluppo incrementale necessario per creare un Incremento rilasciabile non più tardi del termine di uno Sprint.
  • Durata dello Sprint: Durata, limitata nel tempo (time-box), di uno Sprint. Può essere di massimo 4 settimane o inferiore.
  • Emersione (Emergence): processo che porta alla luce o mette in risalto elementi non previsti, oppure la conoscenza di un fatto non precedentemente noto o diventato visibile inaspettatamente.
  • Empirismo: tipo di controllo dei processi nel quale le decisioni sono basate sull’osservazione di risultati, esperienze e sperimentazione. L’empirismo prevede di implementare ispezioni ed adeguamenti regolari, basati sulla trasparenza che, così facendo, viene ulteriormente rafforzata. È anche noto come “controllo empirico dei processi”.
  • Grafico “Burn-down”: rappresentazione grafica che mostra la progressiva e cumulativa diminuzione del lavoro rimanente rispetto al tempo.
  • Grafico “Burn-up”: rappresentazione grafica che mostra l’aumento di un parametro (ad esempio il valore) rispetto al tempo.
  • Impedimento: Qualunque intralcio o ostacolo che blocca o rallenta il lavoro del Development Team e che non può essere risolto attraverso l’auto organizzazione del Development Team. Deve essere segnalato non più tardi del primo Daily Scrum disponibile. Lo Scrum Master é responsabile della sua rimozione.
  • Incremento: set di lavoro potenzialmente utilizzabile che si aggiunge agli Incrementi precedentemente creati e coi quali forma – nell’insieme – un prodotto.
  • Previsione (Forecast): anticipazione di un trend futuro basato sull’osservazione del passato. Tipicamente selezione di determinate parti di Product Backlog ritenute consegnabili durante lo Sprint corrente o in quelli futuri, anche in relazione al Product Backlog futuro.
  • Product Backlog (sost. m.): elenco ordinato sempre in evoluzione di tutto quanto è ritenuto necessario dal Product Owner per poter creare, consegnare, manutenere e sostenere un prodotto.
  • Product Owner (sost f./m.): persona responsabile dell’ottimizzazione del valore espresso da un prodotto, attraverso la gestione incrementale del Product Backlog, nonché l’esplicitazione di tutte le aspettative e idee in esso contenute; referente unico dello Scrum Team verso tutti gli Stakeholders.
  • Affinamento (Refinement) del Product Backlog: attività portata avanti con continuità  durante lo Sprint, attraverso la quale Product Owner e membri del Development Team aggiungono granularità al Product Backlog, in continua evoluzione potenziale.
  • Scrum (sost. m.): (1) framework semplice per il rilascio di prodotti complessi; (2) framework semplice per la gestione di problemi complessi.
  • Scrum Master (sost f./m.): persona responsabile di favorire e sostenere un contesto Scrum attraverso attività di guida, addestramento, insegnamento e facilitazione di uno o più Scrum Team, nonché del loro sviluppo nella comprensione e corretto utilizzo di Scrum.
  • Scrum Team: combinazione delle responsabilità in capo a Product Owner, Development Team e Scrum Master.
  • Sprint (sost. m.): evento della durata massima di 4 settimane o meno, che funge da contenitore di tutti gli altri eventi Scrum. Punta a realizzare un sufficiente ammontare di lavoro, assicurando regolari ispezioni, riflessioni e adattamento a livello di prodotto e di strategie. Gli unici altri eventi ammessi in Scrum sono: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
  • Sprint Backlog (sost. m.): visione d’insieme – materializzata in varie forme ed in continua evoluzione – di tutte le attività selezionate dal Product Backlog da parte le Development Team e relative allo sviluppo necessario alla realizzazione dello Sprint goal.
  • Sprint Goal (sost. m.): affermazione sintetica che esprime l’obiettivo generale di uno Sprint.
  • Sprint Planning (sost. m.): evento della durata massima di 8 ore o più breve, che segna l’inizio del nuovo Sprint. L’evento è funzionale allo Scrum Team per ispezionare gli elementi del Product Backlog ritenuti in quel momento di maggior valore, nonché per determinarne la pianificazione all’interno di uno Sprint Backlog tenendo in considerazione lo Sprint Goal generale.
  • Sprint Retrospective (sost. f.): evento della durata massima di 3 ore o più breve, che segna il termine dello Sprint; l’evento è funzionale all’ispezione – da parte di tutti i membri dello Scrum Team – dello Sprint che si sta per concludere, nonché per decidere come lavorare nello Sprint successivo.
  • Sprint Review (sost. f.): evento della durata massima di 4 ore o più breve, che segna il termine dello sviluppo relativo allo Sprint. L’evento è funzionale all’ispezione – da parte dello Scrum Team e degli Stakeholders – dell’Incremento, del progresso generale e dei cambiamenti strategici, per permettere al Product Owner di aggiornare il Product Backlog.
  • Stakeholder (sost. f. / m.): persona esterna allo Scrum Team 1) portatrice di specifiche conoscenza e/o 2) rappresentante di un interesse per un prodotto, necessari per l’ulteriore evoluzione del prodotto.
  • Standard di sviluppo: l’insieme di standard e pratiche che un Development Team identifica come necessarie per creare Incrementi di prodotto potenzialmente rilasciabili non oltre il termine dello Sprint.
  • Time-box (sost. f.): contenitore temporale limitato, caratterizzato da una durata massima e potenzialmente fissa. In Scrum tutti gli eventi sono caratterizzati da una durata massima, ad eccezione dello Sprint, che ha una durata fissa.
  • Valori di Scrum: set di 5 valori e qualità fondamentali il framework Scrum: impegno, focalizzazione, apertura, rispetto e coraggio.
  • Velocity (sost. f.): indicatore molto diffuso che misura l’ammontare medio di Product Backlog trasformato in un Incremento, potenzialmente rilasciabile durante uno Sprint da parte di uno specifico (o dalla composizione di uno) Scrum Team. La Velocity rappresenta essenzialmente un utile supporto alla previsione del lavoro rilasciabile (forecast) a disposizione del Development Team, parte di uno Scrum Team.

On a personal note I want to share that I regularly get requests or suggestions for translations. Few get to the point of actually starting. I thank Michael for his commitment and wish him the persistence it takes for such a hard and complex endeavor. Rather than making a simple word-by-word translation, it involves adaptations, interpretations and redirections requiring affinities in English, Italian and Scrum​.​ This is far from trivial.

Scrum Vocabulary (updated)

Driven by the prospect of an Italian translation of my book “Scrum – A Pocket Guide” I decided to revise it slightly; minor tweaks of words and terms, although a lot of them.

As part of my revision, I also updated the Scrum Vocabulary of my book:

  • Burn-down Chart: a chart showing the decrease of remaining work against time.
  • Burn-up Chart: a chart showing the increase of a parameter, e.g. value, against time.
  • Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves for the Development Team to share the daily progress, plan the work for the next 24 hours and update Sprint Backlog accordingly.
  • Definition of Done: a set of expectations and qualities that a product must exhibit to make it fit for a release in production.
  • Development standards: the set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.
  • Development Team: the group of people accountable for all incremental development work needed to create a releasable Increment no later than by the end of a Sprint.
  • Emergence: the process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.
  • Empiricism: the process control type in which decisions are based on observed results, experience and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as ’empirical process control’.
  • Forecast: the anticipation of a future trend based on observations of the past, like the selection of Product Backlog people believe they can deliver in a Sprint or in future Sprints for future Product Backlog.
  • Increment: a candidate of releasable work that adds to previously created Increments, and – as a whole – forms a product.
  • Product Backlog: an ordered, evolving list of all work deemed necessary by the Product Owner to create, maintain and sustain a product.
  • Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.
  • Product Owner: the person accountable for optimising the value a product delivers by incrementally managing and expressing all product expectations and ideas in a Product Backlog; the single representative of all stakeholders.
  • Scrum (n): a simple framework for complex product delivery (1); a simple framework for complex problem management (2).
  • Scrum Master: the person accountable for fostering an environment of Scrum by guiding, coaching, teaching and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.
  • Scrum Team: the combined roles of Product Owner, Development Team and Scrum Master.
  • Scrum Values: a set of 5 fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
  • Sprint: an event that serves as a container for the other Scrum events, time-boxed to 4 weeks or less. The event serves getting a sufficient amount of work done, while ensuring timely inspection, reflection and adaptation at a product and strategic level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
  • Sprint Backlog: an evolving overview of the development deemed necessary to realize a Sprint’s goal.
  • Sprint Goal: a concise statement expressing the overarching purpose of a Sprint.
  • Sprint Planning: an event marking the start of a Sprint, time-boxed to 8 hours or less. The event serves for the Scrum Team to inspect the Product Backlog considered most valuable and design that forecast into an initial Sprint backlog against an overarching Sprint Goal.
  • Sprint Retrospective: an event marking the closing of a Sprint, time-boxed to 3 hours or less. The event serves for the Scrum Team to inspect the past Sprint and establish the way of working for the next Sprint.
  • Sprint Review: an event marking the closing of the development of a Sprint, time-boxed to 4 hours or less. The event serves for the Scrum Team and the stakeholders to inspect the Increment, the overall progress and strategic changes in order to allow the Product Owner to update the Product Backlog.
  • Stakeholder: a person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further incremental evolution of the product.
  • Time-box: a container in time of a maximum duration, potentially a fixed duration. In Scrum all events have a maximum duration only, except for the Sprint itself which has a fixed duration.
  • Velocity: popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of a) Scrum Team. Serves as an aid for the Development Team of the Scrum Team to forecast future Sprints.

I look forward to the Italian version seeing the light of day in 2018. I translated my book (2013) to Dutch in 2016 as “Scrum Wegwijzer“. It was published in German as “Scrum Taschenbuch” (translated by Peter Goetz and Uwe Schirmer) in 2017.

You can still find the Scrum Glossary of those editions on my blog.

The T-Shape Deception

I have never worked with a single person who mastered no more than a single skill. Every individual I worked with had the intrinsic capability to perform in more than one type of work. Every individual I worked with had the intrinsic ability to join forces with people that master other areas of expertise.

Every individual is naturally T-shaped. Ultimately, people can unite to form collectively T-shaped eco-systems, entities, often teams.

I have never worked with a single person who mastered every possible skill needed to perform any type of work that might arise when dealing with complex challenges. The demand for people to be able to do just that, is absurd. Yet, it is how the T-shape metaphor is abused. The idea that a cross-functional entity can only be composed of fully cross-functional individuals.

Every individual is naturally T-shaped. People are impeded or blocked from employing their intrinsic T-potential rather than being unwilling to do so. Common causes are function descriptions, hierarchy, systems, structures, procedures, instructions, incentives, rewards and other HR processes, enterprise career pressure.

The message that external forces need to mould people into T-shapes is an
expression of distrust and disbelief in the potential of people. People are not resources or an assembly of ‘skill’ parts. People don’t need to be deconstructed, disassembled, reconstructed or amended for any preferred shape, like parts forged to fit a pre-empted construction. Systemic impediments need to be removed that prevent people from exploring and discovering their needs and interests, from growing their talents and potential.

Rather than judging people for the expertise they (don’t) demonstrate, focus on creating a context, an environment in which people can unleash their motivation and their multi-skilled potential. An environment where people can bring in their multi-skills and expertise to leverage a cross-functional and multi-skilled entity (like contributing to T-shaping a team). In the end, problems in the Complex Novelty space go beyond any individual’s problem-solving capabilities, T-shaped or not. They need T-shaped teams and eco-systems to be an integral part of. And -ultimately- a context in which cross-fertilisation happens; people extending their skill sets through peer collaboration and peer learning.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(Principle #5 from the Agile Manifesto)

The purpose of the Scrum framework is to establish essential boundaries of such an environment of self-organization and intrinsic motivation thriving on the professional drive of people to create excellent products. Scrum Master, as a modern manager, is accountable for fostering such an environment of Scrum. A safe environment where people can demonstrate traditionally unsafe behavior, like going beyond the limitations of their function descriptions.

Creating opportunities to deliver value (as an Independent Scrum Caretaker)

I have wandered the fascinating realms of IT, technology and software development since graduating in 1992, except for the years of running a bookstore (1996-1999). I discovered an Agile way of working through eXtreme Programming and Scrum in 2003. It became my purpose, my belief and my core; spreading the Agile paradigm to help people create better products and humanize their workplace.

After a career as a consultant (2001-2013) and spending 3 years working exclusively at Scrum.org as partner to Ken Schwaber, in 2016 I decided to further my path as an independent Scrum Caretaker; a connector, writer, speaker, humanizer.

I’ve come to accept the difficulty of grasping what this holds. I understand the difficulty when people offer me positions and assignments, assuming I am desperate (for money, status, work). Regardless, through my self-chosen ‘title’ I consider the areas through which to deliver value to the world, to help that world become a better place to live and to work in.

  • Classes“: Facilitating people’s knowledge and insights in Scrum through Professional Scrum Master and Professional Scrum Product Owner classes, and custom workshops.
  • Events“: Attending and speaking at events.
  • Writing“: Creating papers, a new book and blog notes (reproduced at some other channels).
  • Consulting“: Working with teams and organizations, upon the non-negotiable requirements that it must be personal, about Scrum and serious.

Every activity involves plenty of hours of devising the right words and even many more hours of silent reflection, travelling mental cobblestone labyrinths. I don’t look for money for every single activity in every single service area. Context prevails.

From my standard offer of services:

Through my work I have come to appreciate the uniqueness of every person, team, department and organisation. It has inspired me to move away from fixed approaches. (…) I don’t require specific task descriptions. I require no title. I don’t post my assignments or expose the name of your organisation, unless you explicitly allow or ask me to do so.

Through the initiative of the Scrum Caretakers meetups, I see my experience confirmed that it is not easy being a Scrum Caretaker. It takes quite some intrinsic motivation, belief and dedication (a purpose) to give up (paid) time for mere collaboration on open-ended topics that rarely serve a commercial purpose. It did get me in touch with a lot of non-usuals suspects, outside of the threaded paths of ‘Agile’. The sheer beauty of that experience makes up for a lot of the sacrifices.

I am gratified for the opportunities I stumbled into through my years at work. It served me well in becoming what I didn’t know I wanted (or was able) to be. Most dots only got connected in retrospect, still making it seem as if there was a plan. There wasn’t. In general I had no clue. I still haven’t. But becoming an independent Scrum Caretaker did help me shift towards creating opportunities to deliver value, and help more people deliver value. Reciprocity.

Inside of the whirlwind (The third Scrum Wave)

Scrum is a simple framework that supports people in making the most of complex challenges. Organizations are re-discovering the sophisticated simplicity of Scrum. The third Scrum Wave is rising. Will you sink? Swim? Or will you surf? Shape the wave, shape the future?

TALC – the Technology Adoption Lifecycle

The Technology Adoption Lifecycle (TALC) describes the adoption stages of technology products or services, disruptions and discontinuities in hi-tech innovation. The TALC was created by Geoffrey Moore as an expanded version of the adoption cycle of more traditional products and product lines. Every stage has typical adopter types.

Moore added a “Chasm” period after the phase of Early Market. It is a period of stagnation, a period where adoption stalls. Some unknown time passes by before the next phase of adoption is entered, the Bowling Alley. The Chasm is unpredictable in length, but also in outcome. Some products never get out of this stand-still and simply disappear.

AALC – the Agile Adoption Lifecycle

The term ‘Agile’ became part of the software development lingo in 2001 with the publication of the Agile Manifesto. Before that time, it was just a plain English word that -in short- is synonymous to ‘adaptive’. In a way, it still is.

New technological products that follow the Technology Adoption Lifecycle could be developed applying Agile techniques and principles. Agile in itself however is also a new, and clearly disruptive, game on the technology market and is therefore subject to the Technology Adoption Lifecycle as well.

2001 marks the start of the Early Market phase. At this stage Agile was mainly recognized and promoted for its potential value by early adopters; pioneers, visionaries, enthusiasts, innovators. Early adopters included individuals, teams and organizations.

During the preceding ‘avant la lettre’ phase several approaches and techniques that later became ‘Agile’ were being explored by various ‘creators’. Important milestones are 1995 and 1996, the genesis of Scrum and eXtreme Programming. They were 2 well-defined new approaches to software development in which many of the core ideas of what became ‘Agile’ can already be discerned.

A much broader audience discovered Agile as from 2005-2006. For many organizations the traditional way of working, the industrial paradigm, had been stretched far beyond its limits. There was nothing to stretch anymore. It created mental openness for a very different paradigm. Early Pragmatists discovered the advantages of the new paradigm, of ‘Agile’, and believed its problem-solving capabilities to exceed those of the existing ways. They were looking for solutions that might work. They had no need for widely documented evidence, but settled for the growing amount of anecdotal evidence. Agile crossed the chasm.

Although the TALC typically describes the succession of the Bowling Alley and Tornado adoption phases, the post-Chasm years of Agile primarily showed many back-and-forth movements. There was a lot of pull-back from the traditional, industrial paradigm. Still, a viable market formed.

It is probably too soon to distinguish the Bowling Alley from the Tornado yet. I mainly observe a strong whirlwind that Agile goes through.

Inside of the whirlwind – The 3 Scrum Waves

Regardless the inability to distinguish the transition from Bowling Alley into Tornado at the current point in history already, Scrum has been the dominant definition of Agile post-Chasm. Scrum is the gorilla that emerged.

Inside of the whirlwind, three waves of Scrum have manifested.

The first wave of Scrum, rising with Agile crossing the chasm in 2005-2006, was a reconnaissance wave for many. Organizations faced obvious problems in the IT and software delivery domain that could no longer be patched through the industrial ways. Scrum was adopted as the new IT development process.

The second wave of Scrum built on the first wave when in 2010-2011 large organizations -often in the aftermath of the financial crisis- discovered they were at the end of the old ways of working too. In the slipstream of this ‘success’, sub-groups and derivative movements took off, new movements and methods were invented, introduced, launched, and often disbanded again. Divergence and scale were the ruling themes, on top of the common use of Scrum’s terminology and the shared desire to deliver working software in Sprints.

The third Scrum Wave (2016-2017) is fuelled by the desire, the drive for rhythm, focus and simplicity. Too much organizational waste, neglect of people and embedded complexity remain, fundamental impediments unresolved by the (often complex) solutions of the second wave. Organizations renew their acquaintance with Scrum. They appreciate that it is a well-defined and clearly stated framework that creates room for diversity, in it that Scrum can wrap a variety of strategies and techniques to be employed.

Convergence appears on the horizon, where the rage of scattering, where the whirlwind might start calming down. Agile professionals worldwide sow seeds, and fertilize the grounds for many organizations to start bearing fruits, to start enacting Scrum. Join the bigger movement.

 

Closed-loop feedback control with Scrum

Scrum is a simple framework to manage complex challenges. Software delivery is a complex challenge. Software delivery encompasses a multitude of complex activities to create and evolve complex products in complex circumstances. Scrum embraces and emphasizes the complexity of software delivery by implementing the only process type that fits its complexity, empirical process control.

Complexity

There are many variables that have an impact on delivering software; requirements, skills, experience, people, teams, technology, integrations, market conditions, company strategies, budgets, regulations and dependencies, to name just a few. Not all known variables are controlled by the people doing the work, although they have to incorporate the impact on the work. For some known variables too much detail is needed to fully comprehend them. Even if a variable is known, its behavior -now or in the future- may be unknown, or different from what is anticipated.

Products are created by people with cognitive capacities. People are not robots, or replaceable pieces of machinery. The outcomes are hard to describe in an exact and detailed way; before, at the beginning or even as the work advances. Every product created is unique and what is appreciated can only be established when released. The activities to be undertaken aren’t predictable with any degree of high precision. They have not been performed before, in the same way, under the same conditions, several times. The environment evolves constantly. And, most annoying, not all variables are known. There is a high degree of unpredictability.

The degree of dynamism of a challenge requires the right process to be in place in order to have control:

Open-loop systems

An open-loop system is designed for execution of a series of preempted steps to result in a defined outcome in a single run. Such a system assumes a near-perfect predictability of the variables that influence the process as well as of the process activities themselves.

For larger problems, typically a chain of open-loop subsystems is created. The output of a subsystem is the input to the next subsystem. Although theoretically risks should be confined to the smaller subsystems, in practice the whole system’s vulnerability increases exponentially. In situations of turbulence and change, deviations and variances accumulate across the various subsystems, e.g. in timing and quality. It is not uncommon for the accumulated problems to surface only at the end of the final subsystem.

Predictive plans and hand-overs of work between separate functional groups are implementations of open-loop thinking. Predictive plans can only include known variables, their known details and their anticipated behavior, creating the illusion that no unknowns exist. Open-loop thinking invites lengthy upfront consideration of all elements of the plan, and ultimately attempt to foresee the unforeseeable.

An open-loop system is -by design- unable to cope with the amount of disruptions and unknowns typical for complex challenges like software delivery.

Closed-loop systems

Closed-loop systems implement frequent opportunities for inspection so adaptations can be implemented. The actual outcome of the system is compared in a timely fashion against a desired outcome. Desires may change. Variances or undesired results are eliminated or corrected in the next or in future runs. Not all variables and parameters need to be known precisely and in detail, as the process is self-correcting. The system requires and creates transparency. Reality is inspected, and exposed, so that appropriate adaptations are undertaken. The people performing the inspections have clear and agreed standards in place to inspect-and-adapt against. Inspection for reporting and status purposes is pointless. Inspection without adaptation is pointless.

Closed-loop feedback control with Scrum

Scrum embraces and stresses the complexity of software delivery by implementing empirical process control. Scrum replaces the open loops of traditional, phase-gate, staged or similar processes with closed-loop feedback. Scrum defines regular opportunities to inspect and adapt. Scrum enables players to halt the traditional rat race. The players are enabled to stop, reflect, learn from inspections, gather feedback over the output and change course, re-organize, update priorities, improve, adapt. Scrum brings reality back in the game. Scrum brings transparency. That is pleasant when all is progressing well. That is crucial when all is not progressing as hoped for. It allows re-positioning and correction.

In Scrum all work is organised in Sprints. Sprints are time-boxed to assure timely inspection and adaptation. A Sprint forms an ‘inspect and adapt’ cycle of a few weeks at most that wraps the 24-hours ‘inspect and adapt’ cycle of the Daily Scrum:

  • At the Daily Scrum the people doing the work inspect their progress, and identify their most important work to do next within the container of the Sprint. They use the Sprint Backlog, the Sprint Goal and a progress visualization to self-organize within the Sprint. The daily cadence assures they never get out of sync for more than 24 hours.
  • A Sprint is a cycle that starts with identifying and interiorizing the most important ideas instantiated on Product Backlog. Sprints end with an inspection of the product Increment that was actually released or could be released, as well as how it was built, the process, the interactions, the technology at play. As with all inspections, they are forward-looking. They serve the purpose of adapting.

All events of Scrum set a frequency for the inspection and adaptation process, where the artifacts contain the information to be inspected and adapted. Scrum describes the accountabilities needed to perform the inspections and adaptations.

Organizing work in Sprints allows people to take a breath, to break with the traditional rat races, and work at a sustainable pace. Explicit reflection moments are introduced that are crucial for humans to thrive in cognitive, creative work of high complexity, like software delivery is. Within a Sprint, additional feedback loops are created, e.g. through agreed work and development standards.

Note: above text is adapted from my book “Scrum – A Pocket Guide (A smart travel companion)”. If you have more time to spend, consider reading it.

Scrum and universal truths

An update to the Scrum Guide will be released on 7 November 2017. In a webinar the principal co-creators of Scrum, Jeff Sutherland and Ken Schwaber, will introduce the changes relative to the previous update. The previous update was released on 6 July 2016 and encompassed the addition of the Scrum Values.

Although language and words matter, I imagine the difficulty of the rewording involved in updating the Scrum Guide. The Scrum Guide holds the single definition of Scrum for countless practitioners across the world, all employing Scrum in unique environments and varying situations. I imagine the discipline of updating the Scrum Guide knowing that many people will not read it. Most of all, I imagine the difficulty of updating the Scrum Guide knowing that many will micro-dissect the texts to identify the tiniest of changes. Many over-think individual words upon the (false!) assumption of traps, tricks and hidden messages. Many still look for methodological exactness and universal precision.

Regardless, the fact that Scrum has a clear and documented definition is priceless. The Scrum Guide provides clarity and purpose, albeit not the perfect precision that many seem to look for.

Scrum is a tool. Useless unless employed. The Scrum Guide intentionally has no universally applicable, detailed instructions or tactics that in the end only work in specific circumstances. The Scrum Guide describes how the tool works, the rules and roles that apply, the behaviors that make the tool work; not the tactics to apply the rules. Scrum, by design, offers room and breathing space, inviting people to conceive an approach specific to their context upon the empirical foundation of Scrum. Scrum is a framework, not a traditional IT methodology. The Scrum Guide describes the framework, the minimal boundaries within which people deal with complex challenges and create complex solutions in complex circumstances.

All exact decisions within those boundaries depend on people, tools, technology, business domain, organizational environment, market situation, and many other aspects.
What is the availability of people? Their skills, experience? How well do teams gel? Do they work remotely, or co-located? How long have they been working together? How much multi-tasking does a team or team members have to do? How well are teams facilitated by the environment? What technology is being used? Which version? What dependencies are at play? What development practices does a team have in place? What tools and infrastructure are at the teams’ disposal? How long are the Sprints? How is the connection with product management? What is the competition doing?

The Scrum Guide does not have the false pretence of offering universal truths, universal answers that apply in every single situation. Scrum essentially invites people to regularly match the actual state of their work against reality, in order to re-align and adapt to new circumstances and incorporate new insights. Scrum is a simple framework for complex product delivery.

The Scrum Guide offers the simplicity needed, without being simplistic about the unique challenges that teams face. I notice how many people struggle with this deliberate imprecision when they try to improve their understanding of Scrum. They look for detailed instructions. They ask universal questions and demand exact and precise answers.
How long should Sprint Planning be? And the other events? How much time does the Product Owner role take? Is the Scrum Master role a full-time job? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? How many business analysts are needed in the team? How should we calculate utilization? How can we measure productivity? Should the Product Owner and the Scrum Master understand the technology? What if… ?

No document, no matter its size, can provide exact answers to these questions for all Scrum practitioners around the globe. It requires courageous professionals (Scrum Masters, trainers, and otherwise) to build on the language and words provided by the Scrum Guide and explain intent and purpose. It requires skilled professionals to help teams, organizations, and students grow an understanding of how Scrum supports them in empirically dealing with the diverse, complex challenges they face in their real-life complexity. Such professionals understand that what works today might not work tomorrow. Exact instructions lead people astray, undermine their ability to think autonomously in terms of Scrum.

My personal stance, as a trainer, a friend, a trusted advisor, a whatever in Scrum, is to facilitate people in understanding the purpose of the rules and the roles of Scrum. I consider it the only viable way for people to devise their own solutions employing Scrum. No external instance, expert or otherwise, can or should do that for them. It may be tempting. It is certainly highly convenient. It might make a person appear knowledgeable. But it promises certainty where there isn’t. That is unprofessional. It ignores context and complexity. It ignores people’s intelligence and creativity.

I am extremely wary of being seen as an ‘expert’ providing universal solutions. Consider me an eternal novice instead.

Every case of Scrum is unique. There is no copy-paste. There are no universal truths in the complex novelty space. The definition of Scrum requires no methodological precision. There is no future in ignoring complexity.