Posted on Leave a comment

Daily Scrum Pocketcasts

Ever since the accidental creation of my book Scrum – A Pocket Guide (A Smart Travel Companion) in 2013, and its deliberate evolution in 2019, I frequently receive inquiries about the availability of an audiobook version.

Although I see value in the idea, I have not been able to make it happen so far.

Given the current pandemic storm, forcing many friends of Scrum to remain at home, I decided to implement upon the audio idea in a slightly adjusted form.

Starting Tuesday 24 March 2020, I have planned a first series of five “Daily Scrum Pocketcasts.” In subsequent daily broadcasts I will read my Scrum Pocket Guide front to back. I will do a reading session on working days at 3 pm CET (Central European Time), with each session continuing were the previous session ended. The sessions are open for 100 attendants. Registered attendants can send me questions about the book, or parts of it. I plan to read for 30-45 minutes every day after which I hope I can address questions related to the chapter(s) of the day. Every daily session will be time-boxed to a total of 1 hour.

I plan to also record the sessions and make them available via my YouTube channel. I hope to collect the questions and my (written) answers in a document that, if all works out, I will share for free with everyone.

I have no idea where this will take us, how long it will last, or how the idea and its emerging implementation will unfold. Of one thing I am sure, it won’t all be smooth. Come find out with me, and register on Zoom (or copy following link to your browser Note that each session requires separate registration.

Warm regards
your independent Scrum Caretaker

Posted on Leave a comment

Minimal measures for minimal stability in a complex world (that will help you optimize your Scrum)

Scrum, in its more general definition, is a simple framework to help us address complex challenges. Product development is the subset of complex problem domains where Scrum took root first; by explicitly acknowledging software and new product development to be complex work, serving to deliver complex products in complex circumstances.

Scrum is increasingly being discovered as a simple framework to address complex problems and situations other than software and product development. More and different people, teams and organizations ask for guidance and support on their journey of Scrum, no matter the nature of their problem. Organizations discover that fighting complexity with complexity is not helping. Too much waste, organizational redundancy and fundamental impediments remain unaddressed by the overly complex approaches that organizations use. No sustainable agility is achieved. Organizations discover that they have been seeking for (or were pointed to) universal truths where there are none.

Complex work, of which software and product development are good examples, does not have the high degree of predictability to apply the old approaches that build on linearity, causality and predictive management.

One aspect of ‘complexity’ are the parameters, variables and events that influence an activity and its course. Think of your work, make a list. Consider how predictable the listed variables are, how much control you actually have over them and how sure you are that you listed all of them. However, it is not only the number of known parameters that is important, but also the available as well as the required knowledge over these parameters. What is the level of detail required to comprehend a variable as well as the future behavior of that variable? How long does it take to gather that information? How stable is that information, once collected? Even if a parameter is known, the level of detail may be too deep to be able to manage and control it. And then, of course, the behavior of the parameter is still not necessarily predictable. A known variable may still behave completely different compared to what was planned or expected to happen. And, do not forget that all variables, known and unknown, are related and impact each other, typically in non-linear ways.

‘Complexity’ is also dependent on the nature of the work itself. The combined steps, tasks and activities that make out complex work are not predictable with any degree of high precision. They have not been performed before, or not in the same way or context. They are not repeatable. New insights, techniques and approaches emerge, even while the work is already taking place. Also, the exact and detailed outcomes of complex work are hard to describe and predict before or even at the beginning of the actual work. Expectations change. Markets evolve. Competitors surprise you. And, complex work typically requires the cognitive and creative capabilities of people performing the work. The engagement and involvement of people is dependent on more circumstances than we comprehend, let alone can control.

Complex work is actually more unpredictable than it is predictable. Complex problems are dynamic, not static. The degree of dynamism of a problem or activity requires the right forms of process and stability to be in place in order to have some form of control. Stability in complex work performed in a complex world comes not from fixing requirements, outputs, timelines or plans. These are destined to be unstable and will change. Stability is not about certainty or predictability. Stability is about an environment and boundaries within which to explore and experiment, within which to continually diverge and converge towards incremental solutions answering your complex needs.

Too many organizations end up in total chaos when they experience how the old elements of stability no longer work, but fail to replace them with the minimal measures that would help them optimize their Scrum to better address their complexity:

Start with identifying your problem (product).

In a typical Scrum setting, the problem is developing complex solutions, often a product or a service.

Define and identify your product first. Then organize your Scrum, or re-imagine your Scrum, to optimally tackle your problem or serve your product.

I have observed too many many organizations form Scrum Teams within existing specialist silos and departments, doing little more than renaming existing titles and functions to Scrum terms,
certainly not minding the scope of their Scrum, let alone capitalizing on synergies that exist across those individual Scrum Teams, like the fact that they actually all work on the same product. Disconnectedness is not resolved. The complex problem is not adequately tackled. Parts or components of product are being built, rather than integrated, cohesive product versions that provide end-to-end value.

Have dedicated teams working in dedicated team spaces.

Complex problem-solving requires focus, interaction, communication, collaboration, cross-fertilization and collective intelligence. It requires dedication.

Teams should not be all over the place in terms of getting dragged to external meetings regularly or having to work in multiple teams or on multiple projects at the same time. Your teams should be able to primarily dedicate their time maximally on the problem/product at hand, self-manage their work in Sprints and even figure out and establish their own team size and team composition. I have observed too many teams that were really jelling and achieving a highly collaborative state, until being pulled apart by people external to the team; resource managers, departments heads, project management offices. Each one of those teams ultimately plummeted, demotivated.

Teams definitely need a dedicated team space to get the most out of their collaboration, conversations and interactions. Open offices kill innovation and creativity, even more when combined with clean wall policies. People dare not speak up or need to move to separate meeting rooms to do so. Open offices are good for… office work, not for intense and collective problem-solving.

Benefit from the consistency that the Scrum events provide without industrializing your Scrum to death.

Scrum by default offers stability and consistency by suggesting to keep Sprint length stable over a substantial period. It allows people to, often unconsciously, grow an intuition of what is (not) possible, which is extremely helpful in forecasting Sprint and Product Backlog work. It offers minimal stability. It is why Sprints, as container events, have a fixed time-box. Sprints don’t end sooner or later than the set time-box, while the other events can end sooner. Sprint is a stable container event that provides overall rhythm and cadence to the opportunities for inspections and adaptations foreseen within a Sprint; Sprint Review, Daily Scrum, Sprint Review and Sprint Retrospective.

I am astonished however how organizations dictate a fixed Sprint length to all teams across the organization, regardless of their problem, technology, business domain, product. Organizations tend to industrialize their Scrum, rather than standardize on Scrum. Scrum can be introduced and adopted, allowing all within an organization to speak the same language, without eliminating the option of tuning your Scrum to a specific context.

Scrum only defines that Sprints should be no longer than 4 weeks. Within that range every complex product development endeavor can decide over its own right-size Sprint length. This right-size stability factor is not necessarily the same for all products. This brings us back to the necessity of identifying your product or service first, and then organizing your Scrum to optimally serve your product (including considering the Sprint cadence for all teams serving the product).

Posted on Leave a comment

Announcing the book “97 Things every Scrum practitioner should know”

During the fall of 2019, I got totally consumed (and sometimes drained and overwhelmed) by an exciting new Scrum book project. Having finalized the manuscript I finally feel comfortable sharing more information about it.

O’Reilly Media envisioned adding a book about Scrum to their “97 Things” series and got in touch with me (through Dave West of By the end of August 2019, we decided to get started. I had the honor of curating the initiative. We agreed on calling our new book “97 Things every Scrum practitioner should know.” The goal was to compose a book consisting of 97 essays with diverse angles and perspectives on the Scrum framework from contributors globally.

I had no idea what I was getting into, or how much 97 actually is (a lot, I discovered), or where it would take me. But I liked the challenge. Once into it, I liked it so much that I decided to make it my main focus, holding off most other work request and re-ordering my existing plans. It turned out an exciting and insightful experience. I had the pleasure of collecting, editing and ordering essays about Scrum from seasoned Scrum practitioners across the planet on behalf of the many seeking Scrum practitioners out there.

In a few incremental waves, we ended up inviting 129 people to contribute, not minded by their title, organization or position. We invited potential contributors for their insights, past or on-going, and the potential value of sharing them with fellow practitioners. In the end, 69 authors accepted our invitation and delivered one or more articles (indeed, an average of 1.406 articles per author). I cannot thank them enough for going through the effort of writing down their thoughts, perspectives and experience, and their willingness to make them available for Scrum practitioners worldwide.

Find an overview of them, alphabetically sorted, in the PDF “97 Things every Scrum practitioner should know (Contributors).” Or try to recognize them on following overview:

In the current version of the manuscript, the 97 essays are grouped and ordered* along following themes:

  • “Start, Adopt, Repeat.” holds 11 Things.
  • “Products Deliver Value.” holds 11 Things.
  • “Collaboration Is Key.” holds 10 Things.
  • “Development Is Multi-faceted Work.” holds 12 Things.
  • “Events, Not Meetings.” holds 10 Things.
  • “Mastery Does Matter.” holds 12 Things.
  • “People, All Too Human.” holds 8 Things.
  • “Values Drive Behavior.” holds 6 Things.
  • “Organizational Design.” holds 9 Things.
  • “Scrum Off Script.” holds 8 Things.

I also owe a huge thank you to O’Reilly Media for the trust and the collaborative partnership, specifically to Chris Guzikowski and Ryan Shaw for initiating this endeavor and to Corbin Collins for sustaining it. More than being a king of punctuation, Corbin has impressively improved the language and clarity of quite some, if not all, of the 97 Things.

I look forward to keeping you updated on the publication date, which we will derive from our actual progress. It is not expected to be later than July 2020, and will probably be sooner. As we speak, O’Reilly and I are working really hard to turn my manuscript into a book available for you, dear reader.

I believe we will be able to connect the world of seasoned practitioners to the world of seekers through “97 Things every Scrum practitioner should know.”

Warm regards
Gunther Verheyen
independent Scrum Caretaker
December 2019
(updated February 2020)

Posted on 1 Comment

Can you say ‘yes’? (10 questions about your Scrum)

I call myself a  Scrum Caretaker. I aspire inspiring people using Scrum. I prefer showing that I care by sharing positive experiences and cases that demonstrate how amazing working with Scrum can be, what problems can be tackled and how to, the level of excellence we can build into our products, how Scrum can engage people. Ultimately I hope to help people employ Scrum to re-humanize their workplace.

But then it regularly dawns on us — the many, many misconceptions that exist over Scrum. We feel provoked to try to correct the recurring and worrying interpretations of Scrum that are out there. Sometimes that is fun. Often it is not. It can be energizing. In general it drains us. A few lifetimes can be spent fighting that battle. We limit the energy spent fighting to make room for constructing. 

A good place to start is reminding people of what ought to be in place according to Scrum. It provides clarity over what is mandatory in Scrum (and therefore, what is not).

Unlocking the benefits of Scrum requires however a lot more than just knowing what Scrum consists of. Scrum is the foundation to a complex adaptive system (‘CAS’) producing results that cannot be attributed to its individual components separately. Unlocking the benefits of Scrum depends more on the way the whole of Scrum is being used, through the rules that bind its constituent parts together. Unlocking the benefits of Scrum depends even more on what the people practicing Scrum do, more than what they know or say in the name of theory. It depends on how people interact within the framework, the conversations they have.

Here are 10 questions to help you assess what you do with the 11 elements of Scrum. Can you say ‘yes’?

  1. The accountabilities of Product Owner, Development Team(s) and Scrum Master are identified and enacted?
  2. Work is organized in consecutive Sprints of 4 weeks or less?
  3. There is an ordered Product Backlog?
  4. There is a Sprint Backlog with a visualization of remaining work for the Sprint?
  5. At Sprint Planning a forecast, Sprint Backlog and a Sprint Goal are created?
  6. The result of the Daily Scrum is work being re-planned for the next day?
  7. No later than by the end of the Sprint a Done Increment is created?
  8. Stakeholders offer feedback as a result from inspecting the Increment at the Sprint Review?
  9. Product Backlog is updated as a result of Sprint Review?
  10. Product Owner, Development Team(s) and Scrum Master align on the work process for their next Sprint at the Sprint Retrospective?

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions, meanwhile collaboratively exploring different  If you don’t overthink your way of working along that road of evolution, you might find Scrum to be of a bare essence actually.

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions.

If you don’t overthink your way of working along that road of expansion and evolution, you might find Scrum to be of a bare essence actually. Do know that understanding that Scrum requires 11 elements to be in place is only the beginning. My 10 questions might help you better understand how they relate to each other. Find yourself at the beginning still. Understand how all of them serve empiricism, the act of regular inspection and adaptation, and how inspection without adaptation makes no sense in a world of Scrum. Separate rules from tactics to play the game. Use empiricism also to explore different tactics

My Scrum Gameboard not only represents the 11 mandatory elements, but also 3 principles underlying Scrum. Understand how the Scrum Values drive behavior.

Keep learning.
Keep improving.
Keep… Scrumming.

Warm regards
independent Scrum Caretaker

Posted on Leave a comment

The Scrum Glossary and the Scrum Values are now also available in Tamil

Thanks to the hard work of Mohammad Umar Farooq and Balachandhiran Sankaran, the international versions of the Scrum Glossary and the Scrum Values have been expanded with Tamil.

Download your PDF of the Scrum Glossary, your PDF of the Scrum Values and your poster of the international Scrum Values. Share and use them as you see fit.

The descriptions are now available in more than 20 different languages, thanks to all volunteers that worked hard to create these gifts.

  • Arabic: Rasheed Raya
  • Belarusian: Vasili Shymanski
  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia
  • Danish: Rasmus Kaae, Mikkel Toudal Kristiansen
  • Dutch, English: Gunther Verheyen
  • Filipino: Shirley Santiago, Warren Yu
  • French: Fabio Panzavolta, Mohamed Gargouri
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Greek: Thodoris Bais, Nikolas Friligkos
  • Hindi: Punit Doshi, Hiren Doshi
  • Italian: Michael F. Forni
  • Persian: Mehdi Hoseini
  • Polish: Paweł Feliński, Krystian Kaczor
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin, Pablo Bernardo
  • Tamil: Mohammad Umar Farooq, Balachandhiran Sankaran
  • Turkish: ilkay Polat, Lemi Orhan Ergin
  • Ukrainian: Andrii Glushchenko
  • Vietnamese: Khoa Doan

Posted on Leave a comment

“Scrum – Um Guia de Bolso” is now widely available

As I was working on the second edition of my pocket guide to Scrum in 2018, Rodrigo Silva Pinto and Leonardo Bittencourt proposed to create a Portuguese translation of my book. It was the start of a collaborative endeavour towards self-publishing the translation.

I am humbled and honoured for announcing that the result is now available as Scrum – Um Guia de Bolso (Um companheiro de viagem inteligente)“, in Kindle and in paperback format via Amazon.

(note: the primary market for the Kindle version is Brazil which allows me to keep the price affordable. The paperback’s primary market could not be set to the same so I had to set that to the US. Both versions however are available through all market places of Amazon.)

I wish all Portuguese speaking friends of Scrum much joy reading my translated thoughts, beliefs and considerations of Scrum, that simple framework to address complex challenges. I feel forever indebted to Rodrigo and Leonardo for making my book available for all Portuguese readers, and to Barbara Knijff of Jellylab for creating the cover.

Loving regards
independent Scrum Caretaker

Here is how Rodrigo and Leonardo introduced their work in the book:

Rodrigo Silva Pinto, Agile School, junho 2019

Tenho a oportunidade de formar centenas de pessoas todos os anos em treinamentos de Scrum que vão dos fundamentos a conteúdos mais avançados. Um pedido comum entre os alunos é a indicação de literatura do gênero. Mas a resposta por muito tempo era não satisfatória: “O livro Pocket Guide do Gunther é o melhor, mas só está disponível na língua inglesa”. Havia uma lacuna, faltava uma boa referência literária do Scrum para os falantes de língua portuguesa.

Cansado de esperar, resolvi fazer parte deste projeto, propagando um conteúdo de altíssimo nível e me associando a um dos autores mais influentes do tema, depois dos próprios criadores do framework.

Espero que as horas dispendidas em “Scrum – Um guia de bolso”, possam contribuir com a comunidade Ágil e o mercado brasileiro para juntos construirmos produtos com alto índice de profissionalismo e que gerem impacto necessário para mudar o mundo.

Leonardo Bittencourt, Principal Lean/Agile Consultant, junho 2019

Tive o prazer de conhecer o Gunther pessoalmente durante Agile Tour Vilnius em 2017. Posteriormente colaborei com a tradução de dois de seus trabalhos para Português, o Glossário Scrum e os Valores do Scrum. Indubitavelmente ele faz juz ao que se auto-intitula, Zelador do Scrum (Scrum Caretaker).

Nesta obra, Gunther usa uma linguagem simples que vai direto ao cerne do Scrum, aborda os pontos cruciais e clarifica o framework Scrum de uma forma cirúrgica. Este livro lhe ajudará a evitar armadilhas, equívocos e adoção de um Scrum mecânico. Você compreenderá o propósito do Scrum Framework bem como os porquês de cada elemento que o compõe.

Manter o conteúdo sem distorções e com a mesma clareza, onde as palavras usadas na versão original foram minuciosamente pensadas, trouxe uma boa dose de desafio extra.

Indico este livro para quem está iniciando e para quem já tem experiência com Scrum. Lhe garanto que durante sua leitura – ou releituras como no meu caso – sempre haverão novas descobertas.

Não perca tempo. Boa leitura e Scrum on!


Posted on 7 Comments

Velocity in Scrum, actually

In complex and uncertain environments, more is unknown than is known. There is much we don’t know. What we know is subject to change. Only what we have achieved is known (unless we prefer to cover up). Progress is in what we have done, more than in what we plan to do. What we plan to do are assumptions that need validation by emerging actions and decisions. We make and incrementally change decisions based on what is known.

In Scrum it is considered a good idea for teams to know about the progress they have been making. It is one parameter (of several) to take into account when considering the inherently uncertain future.

From the Scrum Guide (Sprint Planning):

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

Teams express this Scrum Guide guidance of ‘past performance’ often as ‘Velocity’. Although not a mandatory concept, it is a good tactic to apply in Scrum and for many teams even useful to increase their proficiency in self-management.

Painful problems arise however if Scrum gets managed through the distorting lens of the old, industrial paradigm. Purpose gets lost and ideas get corrupted. No more than an illusion of agility is created. One such case is when Velocity becomes an indicator of volume (of tasks and features produced) and is measured for external justification (i.e. beyond the team boundaries).

Although Scrum can be employed to address any complex challenge, Scrum is foremost applied as a framework for complex product delivery. For many organizations the availability and usage of their products and services is life-critical. They adopt Scrum because they need to act with more agility against that life-critical purpose. Scrum is designed to deliver agility to these organizations under the form of releasable versions of products, called Increments. The purpose is to enable organizations in having an effective impact on the market place no later than by the end of each Sprint. This is a crucial trait of agility for organizations that are highly product or service-dependent.

Against that purpose it is not helpful to not have a releasable product version by the end of a Sprint. We allow even what we have done to remain full of unknowns. We undermine the only base we have for making decisions. We undermine the solidity of our already fragile decision process even more. In terms of real progress, Velocity is actually… zero.

In the face of the purpose of increased agility through Scrum, it doesn’t add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint. There are probably more serious problems to address first. There are more important challenges than measuring how many points were burned. Let alone the completely futile attempts to standardize, normalize, industrialize, or equalize Velocity across an organization.

In the absence of teams’ capability to effectively produce releasable Increments, such discussions do no more than distract from the more serious problems. Velocity becomes an obfuscating indicator. The definition of Done provides the real transparency for inspection and adaptation. The definition of Done shows what is lacking to increase product quality up to the point of Increments being releasable. In the face of the urgency of agility, the question of what is defined as Done is much more important than registering the amount of unreleasable work produced.

You can obviously measure the Velocity at which undone work is created, and be more predictable in creating even more undone work. It will not help you make progress towards increased agility and having an impact.

Rather, at the Sprint Review ask yourself “What is our impact on the market? What is our ability to go to market?” It will steer the conversation in very different directions than merely reporting how much tasks were completed. Take the findings to your Sprint Retrospective to figure out what is needed to improve on the possibility to go to market next Sprint. Have the ambition of going through an engaged retrospective, rather than one of unfocused fun. Aspire to start creating valuable Increments with a demonstrable impact, no later than by the end of your next Sprint. Nobody external to the team will care about your Velocity, as an external indicator of progress, anymore.

In the face of the purpose of increased agility through Scrum, Velocity, actually, only makes sense if a measure of a team’s capability to create releasable Increments of product, no later than by the end of a Sprint.

Posted on Leave a comment

Invitation for Scrum Day India 2019

The 2019 edition of Scrum Day India is happening on Saturday 20 July 2019, in Gurgaon (Delhi NCR).

Sanjay Saini, owner of Agile WOW (“Agile Ways of Working”), kindly invited me, as an independent Scrum Caretaker, to open and close the event. I hope many Scrum practitioners register at and join the event. In the end, only eager attendants can turn events into insightful experiences!

Sanjay and I agreed on the theme for the 2019 edition of Scrum Day India to be “Beyond Deceptive Agility“.

Many organizations embark on an Agile journey, a journey to increase their agility. We find that the result is often quite deceptive, in terms of business outcomes as well as to the teams, leaders and user bases of these organizations. As we inspect to adapt in Scrum, we want to explicitly move beyond merely detecting this unfortunate situation. We hope to share some insights and stories about moving beyond deceptive agility.

As a personal note I want to add that I am not just excited for visiting India for the first time ever. I see my visit as a way to express my support not only to the Scrum practitioners in India, but also to local experts. Beyond helping organizations in their adoption of Scrum, Sanjay is a Professional Scrum Trainer, licensed by to teach Professional Scrum classes. Check out all Professional Scrum classes in India!






Posted on Leave a comment

The Scrum Glossary and the Scrum Values are now also available in Belarusian and Vietnamese

Thanks to the hard work of Vasili Shymanski and Khoa Doan, the international versions of the Scrum Glossary and the Scrum Values have been expanded with Belarusian and Vietnamese.

Download your PDF of the Scrum Glossary, your PDF of the Scrum Values and your poster of the international Scrum Values. Share and use them as you see fit.

The descriptions are now available in more than 20 different languages. I am extremely grateful for all the volunteers that worked hard to make this happen and created these gifts.

  • Arabic: Rasheed Raya
  • Belarusian: Vasili Shymanski
  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia
  • Danish: Rasmus Kaae, Mikkel Toudal Kristiansen
  • Dutch, English: Gunther Verheyen
  • Filipino: Shirley Santiago, Warren Yu
  • French: Fabio Panzavolta, Mohamed Gargouri
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Greek: Thodoris Bais, Nikolas Friligkos
  • Hindi: Punit Doshi, Hiren Doshi
  • Italian: Michael F. Forni
  • Persian: Mehdi Hoseini
  • Polish: Paweł Feliński, Krystian Kaczor
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin, Pablo Bernardo
  • Turkish: ilkay Polat, Lemi Orhan Ergin
  • Ukrainian: Andrii Glushchenko
  • Vietnamese: Khoa Doan

Posted on Leave a comment

Re-imagine your Scrum to firm up your agility

Many of today’s enterprises are hardly fit to play a leading role in today’s world. They are designed on the past-world premises of stability and high predictability, of repetitive work with easily scalable results. They experience profound difficulties having to navigate the predominantly uncertain and unpredictable seas of today’s world. An increase in agility is needed. They adopt Scrum. Rather than updating their past-world structures while introducing Scrum, they twist Scrum to fit their current organization. No more than an illusion of agility is created as a result.

Imagine they would re-imagine their Scrum and re-emerge their organization to firm up their agility…

Organizations, certainly if they have been around for a while, grew into very complicated and extremely interdependent internal structures. These structures are often the root of the problems organizations seek to resolve by adopting Scrum. Work is essentially seen and organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required to produce and deliver even the smallest chunks of work.

Organizations naturally revert to familiar recipes when facing the need to become more Agile, including mass-production and cascaded approaches, separate transformation projects, copy-pasting what other organizations do or blindly following blueprint prescriptive models.

Individuals are grouped into ‘teams’. The teams are ‘coached’ into complying with standard sets of practices and processes, unified Sprint lengths and electronic process tools. This is uniformly done across the whole organization, regardless business domain, expertise or technology at play.

The existing organizational constructs are not touched, or touching them is cleverly obstructed, if not sabotaged. Teams (often micro-sized) are typically established within existing departments or other forms of functional separations. Higher-up optimizations, like synergies across teams and departments, are ignored in the same way they were before. The systemic disconnectedness that used to inhibit collaborative problem solving between individuals now inhibits collaborative problem solving between micro teams.

More Agile teams does not make a more Agile organization.

Practitioners worldwide turned Scrum into the most applied definition of Agile. Despite Scrum being the new reality, most organizations continue struggling with Scrum. They struggle as they think teams can be constructed. They struggle as they try to map Scrum’s accountabilities on existing functions. They struggle to understand that inspection without adaptation is pointless in Scrum. They struggle to understand how Scrum can wrap a variety of practices, allowing each expression of Scrum to be tuned to a specific context without fundamentally altering the framework. They struggle to re-invent their organization around Scrum to inject agility in their internal structures, although this will ultimately be reflected in their business outcomes. Organizations lack the imagination to picture how Scrum can work for them, mentally blocked to think beyond their current set-up.

Can you imagine Scrum being employed as designed and intended, regardless your current organization? Do you have the will to deeply reflect? Go back to the ‘why’ of your Scrum? Face your clear and apparent urgency? And take action? Recover, reboot, re-imagine?

In order to firm up their agility, courageous seekers re-imagine their Scrum to start re-emerging their organization. They leave behind past attempts, choices and approaches (all that didn’t work). Over-ambition, magnitude anxiety and deflation angst are mitigated by downsizing to small again and subsequently growing iterative-incrementally. They go through incredibly hard work when they:

1/ Re-consider what the ‘product’ is for the implementation of Scrum (or select another clearly bounded and meaningful initiative). Slicing the initiative if it is too BIG.

2/ Re-imagine Scrum for the selected product/initiative/slice.

    • Use Product Backlog as the single plan, holding all development work, whether technical, functional or non-functional. Establish what it means for product Increments to be releasable.
    • Reset the accountabilities to Product Owner, Scrum Master(s) and Development Team(s), full-time dedicated to the initiative and optimizing for the whole rather than for titles, positions and utilization. The eco-system, this newly established Scrum zone, is facilitated with tools, infrastructure and space.

3/ Create coherent, small and tasteful sashimi releases, no later than by the end of each Sprint, through a controlled and automated deployment pipeline.


Courageous seekers take a few Sprints before expanding to a next product/initiative while still improving the existing initiative(s) and relentlessly removing all impediments to the envisioned state of product delivery. Is an environment in place where people are willing to demonstrate the undiluted accountabilities of Scrum? Are teams self-organizing toward delivering releasable Increments providing start-to-finish value, no later than by the end of a Sprint? Are the teams fully equiped with all skills needed, a dedicated team space, all tools, infrastructure and authorizations?

It takes quite some persistence and belief to keep fighting the past-world tendency to control individuals. Remind yourself (or welcome others reminding you) that value is in the outcome of the work, not in the volume produced. At the Sprint Reviews, consider the value a team has potentially created in a Sprint, and align with them on what seems most valuable to work on next. Move away from judging individuals for their hours spent on individual tasks. Team Engagement is the key.

People who are engaged actually care a lot more about customer outcomes and profitability.

Continue re-thinking your internal constructions as initiatives grow, new initiatives spin up and start delivering value. Solve further organizational issues and inadequate policies as you run into them. Start re-emerging the organization upon conscious acts of re-imagining Scrum; funding, HR policies, rewards and incentives, governance, quality assurance, sales and marketing, legal and regulatory compliance. Unleash a way of working that will sometimes lead you to quite unpredictable destinies.

It is hard work. It is a path of learning, experimenting, falling and getting back up. It is transforming how you work, not adding work and complexity to what you already do. It is gradually re-merging your organization towards a networked system of self-sustaining product hubs. A product hub grows or shrinks as needed (following product ambitions and market needs). A product hub is added or disappears as needed (when spinning up or exiting a product). Embed the empirical approach of inspection and adaptation in your managerial practice and in your organizational set-up.

Use Scrum to grow Scrum.