Posted on 3 Comments

Inspection without adaptation is pointless in Scrum

People are naturally Agile. Our personal lives require us to demonstrate our ability to adapt more than our professional environments often allow us to do. Scrum, much like life, is all about adaptation. Scrum sets opportunities for professionals to regularly inspect in order to adapt. Inspection without adaptation is pointless. An act of futility.

The simplest word that might adequately define “agile” is “adaptive”. Adaptiveness, the ability to adapt, is more than ever needed in our world of complexity, creativity, fierce competition and unpredictability. Hence, the criticality of agility, not the illusion of agility that many Agile transformations result in. Agility is reflected in an organization’s unique way to respond to change, absorb important disruptions, capitalize on unforeseen opportunities and -ultimately- cause innovative change.

Scrum is all about inspection and adaptation, and therefore a way to become more Agile, to increase the ability to adapt. The framework of Scrum is a foundation upon which to increase the agility that emerges from frequent inspections and adaptations. Scrum sets no more than boundaries to elevate self-organization with frequent reminders for all players involved to adapt upon observations (inspection) of reality, new insights, acquired experience, changing expectations.

Scrum re-inserts some common sense of life back into a professional environment.

The process of inspection and adaptation, and therefore Scrum, thrives on a dualistic relationship with transparency. The process of inspection and adaptation requires as well as creates transparency. Adaptations that are not based on observations of reality, but of some faked reality, make no sense. They even have the danger of worsening a situation, and increase obfuscation rather than enhance transparency. On the other hand, Scrum also makes reality highly visible, at least at each event. This transparency offered by Scrum is easily cheered and embraced when progress and results are as hoped for, but not so much when that is not the case.

Inspection and adaptation are inseparable acts. Adaptation is a conscious decision about the nearby future.

Even the decision to keep a certain way of working in place, actually, is an adaptation, when taken consciously. For a decision of adaptation to be an informed decision it is best based on inspection, i.e. an act of observation and consideration. Adaptation without observation and reflective inspection misses direction. It is likely no more than a shot in the dark, rather than a deliberate evolution. Inspection without adaptation, in our world of complexity, creativity, fierce competition and unpredictability, makes little sense. It makes little sense to gather information about the past without considering how to deal with that information next. In Scrum, inspection without adaptation is a futile act that serves pretend-agility at most.

The artefacts of Scrum are dynamic placeholders holding essential information that serves the process of inspection and adaptation. Every event in Scrum is an opportunity to inspect and adapt upon this evolving information. The purpose, time-boxes and frequency of the events allow people, the inspectors, to balance focus on getting work done and openness for change.

Inspection for the mere sake of inspecting, without the ambition to adapt, is pointless in Scrum. All Scrum events are intended to be forward-looking, as opportunities to shape the future. None of these events were designed for reporting or status purposes. In the world of high dynamism that leads to deploying a work process based on Scrum it would be very strange if teams did not capitalize on new information and insights that improve their work life as soon as possible. Scrum makes sure it happens never later than at the foreseen events. Scrum assures that the art of empiricism is performed no later than at the time of these events.

Within a Sprint, as an overarching event, development standards and practices provide additional feedback loops. Across multiple Sprints, where a Sprint is a completely defined cycle in time, forecasts can be made, and growth tracked, towards goals and ambitions. Scrum helps you inspect and adapt your way to unpredictable destinies.

In complex and changing environments adaptation is key. These are the environments that demand the adoption of a framework like Scrum. Inspection without adaptation is pointless in Scrum. It is an act of futility and pretend-agility.

(Thank you Higher View and Jellylab for the videos and for the graphics)

Posted on 2 Comments

Challenging Sprint Retrospectives

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted on 5 Comments

Agile (What’s so funny about peace, love and future dreaming?)

The Agile Manifesto, and the movement that stemmed from it, has hugely improved the world. I believe in continuing the Agile dream and create an even better world (rather than focus on the inevitable downsides of the success).

In February 2001, seventeen software development leaders gathered at the Snowbird ski resort in Utah (United States) to discuss their views on software development. Those were times of failing waterfall and heavy-weight RUP projects (‘Rational Unified Process’). These 17 people were following different paths and methods; Scrum, eXtreme Programming, Adaptive Software Development, Crystal, Feature Driven Development, etc.

Much to their own surprise they found an agreement over a set of common principles, beliefs and viewpoints, published as the „Manifesto for Agile Software Development“. The adjective ‘Agile’ became the label to describe the views described in the Manifesto.

Even more to their surprise ‘Agile’ turned into a success, with many people signing the Manifesto and -albeit gradually- Agile taking over the world. A new paradigm was born, in the realm of the software industry. A movement stemmed from it, with Scrum as distinct definition of Agile heading the pack. Over time, Agile seeped into other domains of work and activities, beyond software and product development.

Today, the balance of society incessantly keeps shifting from industrial (often physical) labor to digital (often virtual) work. In many domains of society, the unpredictability of work increases, drastically and continually. The industrial paradigm is rendered useless, definitely. The need for the Agile paradigm is bigger than ever. Scrum is the new reality, now and in the foreseeable future. Actually, Agile and Scrum are inseparable ingredients.

The success of Agile was unplanned, unpredictable, a huge gamechanger and… undesirable (to some).

It deeply saddens me to read, hear and feel the scorning, the resentment, the cynicism. It deeply saddens me that people find little other purpose in life than to make a day job out of negativity, out of pointing at flaws (real or imagined), perceived shortcomings and the incompleteness of Agile. It deeply saddens me to hear people that still are not over the feeling they should have been invited to the Utah event.

Agile as described in the Manifesto, indeed, is imperfect and purposefully leaves room for ambiguities. And, yes, Agile partially turned into a business in itself with forms of bastardization into marketing and moneymaking schemes. And, maybe, there are people and organizations that don’t „get it“ and demonstrate a lack of ‘true’ understanding. That might mean we have not done a good job of helping them discover the value of Agile (in which case a new name will not solve the problem). It might just be in the eye of an ignorant beholder or self-acclaimed experts alike. Who are we to judge?

Regardless, Agile was and is a huge improvement to the world. I am grateful that those 17 people provided us with an amazing foundation upon which to build, discover even better ways to do our work, and keep creating a better world to live and work in.

And, yes, I am wary of the new cult too, the Big gestures and the beatification. I also see the hunts for adoration, name and fame. I observe ideas being stolen, ripped and degraded. All speaking against the Agile and Scrum Values, I know. In avoiding falling into the trap of scorning myself, I have no other choice than to remain with my belief that Agile is not about comic figure-like stereotypes and dress-up routines. Agile is not about massive tap dancing crowds or cheerful ticker tape parades. Agile is not in your title, not in how you look. Beyond being in what you say, Agile is primarily in what you do, how you act.

Still, Agile is a choice, not a must. Nobody needs to join me on my path of continuing the dream. I like to think I am open for any other new, deviant, disruptive idea that introduces more improvements and further humanizes the workplace. In the meantime, I’ll stick to trying whatever I can do to demonstrate the value of Agile, with the Scrum framework as favourite toolbox in my backpack. I can only suggest others to allow their ideas to speak for their positive selves. I am sure blaming Agile (for its broad adoption) is hardly helpful in that regard.

Warm regards
your independent Scrum Caretaker

(Thank you, Higher View, for your professional expertise in video creations)


Posted on 1 Comment

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.

Posted on 4 Comments

Releasable in Scrum, actually

Scrum asks for a releasable Increment of product to be available ultimately by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter. A releasable Increment might be available sooner than by the end of a Sprint, not later.

The purpose of this rule of Scrum is to provide the Product Owner with the opportunity of bringing an updated, improved version of product to market every 1-4 weeks, or more frequent. It is how Scrum implements the first principle of Agile software development:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (source: Principles of Agile Software Development)

Replacing the past wording of ‚shippable‘ by ‚releasable‘ reduced the room to avoid the rigor of releasing to the market frequently, but just shipping an Increment within the organization, the avoidance that abates the benefits and agility needed. The Scrum Guide adds the prefix ‚potentially’, to clarify that Scrum does not say that every Increment must be released. I prefer to leave this prefix out, because ‚releasable‘ in itself is clear enough. Otherwise “Released” would be required as the Increment’s state by the end of the Sprint.

Scrum lays the actual release decision with the Product Owner, as the representative of all (i.e. internal and external) stakeholders. The Product Owner’s decision is not to be limited by technical or engineering aspects. The product Increment is useable. If released, it does not break. That is the accountability of the Development Team. The Product Owner is accountable for assessing whether the Increment is functionally useful.

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)

A Product Owner, being an entrepreneur, understands that no release means no feedback from the market place, no feedback from actual product usage. It means no validation of the assumptions built into the product, reduced learning, postponement of much anticipated improvements. In a way, it blindfolds development.

If a Product Owner decides to release an Increment, it is released. Preferably instantly. No additional work remains to do so. All work that mirrors ‘releasable’ is captured in a definition of Done. Defining “Done” creates transparency:

  • Transparency when forecasting work deemed feasible for a Sprint
  • Transparency when inspecting an Increment
  • Transparency over development progress
  • Transparency regarding the daily work required to have the software in a state of Done

Scrum, as a framework, can wrap various development strategies that increase the capability of creating a releasable (“Done”) version of product in a Sprint; pair programming, test-driven development, ATDD, BDD, Continuous Integration, DevOps, Continuous Delivery, Continuous Deployment. (note: Scrum promoting the Product Owner as the gatekeeper to release might influence how Continuous Deployment is organized.) Feature toggling is certainly an architectural choice that enables higher Product Owner dynamism.

Software being releasable, no later than by the end of a Sprint, is Scrum’s gateway to (business) agility. By the end of every Sprint, or sooner, an updated, improved product can be released to its users and consumers. Feedback can then be gathered to be incorporated into the Product Backlog, and ordered against all other product ambitions.

In Scrum, actually… releasable means all work done to release to the market. Instantly.

The Scrum Values

With Scrum, a framework is created upon which people and organizations develop a working process that is specific and appropriate to their time and context. The rules and principles of Scrum all serve empiricism, or empirical process control, offering closed-loop feedback control, as most optimal for dealing with complex challenges in complex circumstances.

There is however more than the rules and the principles. Scrum is more about behavior than it is about process. The framework of Scrum is based upon five core values. Although these values were not invented as a part of Scrum, and are not exclusive to Scrum, they do give direction to the work, behavior and actions in Scrum (when understood appropriately against the background of complexity and empiricism). Values drive behavior.

Scrum is a framework of rules, principles and… values.


The general definition of ‘commitment’ is “the state or quality of being dedicated to a cause, activity, etc.”. It can be illustrated by a team’s trainer stating “I could not fault my players for commitment” (although they might have just lost a game).

This describes exactly how commitment is intended in Scrum. Commitment is about dedication and applies to the actions and the intensity of the effort. It is not about the final result, as this in itself is often uncertain and unpredictable for complex challenges in complex circumstances.

Yet, there was a widely spread misinterpretation of the word commitment in a context of Scrum. This originates mainly from the past expectation expressed in the Scrum framework saying that teams should ‘commit’ to a Sprint. Through the lens of the traditional, industrial paradigm this was wrongly translated into an expectation that all scope selected at the Sprint Planning would be completed by the end of the Sprint, no matter what would happen. ‘Commitment’ was wrongly converted into a hard-coded contract.

In the complex, creative and highly unpredictable worlds that Scrum helps us navigate, a promise to deliver an exact output or scope against time and budget is not possible. Too many variables influencing the outcome are unknown or may behave in unpredictable ways.

To better reflect the original intent and connect more effectively to empiricism, ‘commitment’ in the context of scope for a Sprint was replaced with ‘forecast’.

However, commitment still is and remains a core value of Scrum:

The players commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best they can, every day again. Commit to the Sprint Goal. Commit to act as professionals. Commit to self-organize. Commit to excellence. Commit to the Agile values and principles. Commit to create working versions of product. Commit to look for improvements. Commit to the definition of Done. Commit to the Scrum framework. Commit to deliver value. Commit to finish work. Commit to inspect and adapt. Commit to transparency. Commit to challenge the status-quo.


The balanced but distinct accountabilities of Scrum enable all players to focus on their expertise.

The time-boxing of Scrum encourages the players to focus on what’s most important now without being bothered by considerations of what might stand a chance of becoming important at some point in the future. They focus on what they know now. YAGNI (‘You Ain’t Gonna Need It’), a principle from eXtreme Programming, helps in retaining that focus. The players focus on what’s imminent as the future is highly uncertain and they want to learn from the present in order to gain experience for future work. They focus on the work needed to get things done. They focus on the simplest thing that might possibly work.

The Sprint Goal gives focus to a period of 4 weeks, or less. Within that period, the Daily Scrum helps people collaboratively focus on the immediate daily work needed to make the best possible progress towards the Sprint Goal.


The empiricism of Scrum requires transparency, openness, and honesty. The player-inspectors want to check on the current situation in order to make sensible adaptations. The players are open about their work, progress, learnings and problems. But they are also open for people, and working with people; acknowledging people to be people, and not ‘resources’, robots, cogs or replaceable pieces of machinery.

The players are open to collaborate across disciplines, skills and job descriptions. They are open to collaborate with stakeholders and the wider environment. Open in sharing feedback and learning from one another.

They are open for change as the organization and the world in which they operate change; unpredictably, unexpectedly and constantly.


The broader Scrum ecosystem thrives on respect for people, their experience and their personal background. The players respect diversity. They respect different opinions. They respect each other’s skills, expertise and insights.

They respect the wider environment by not behaving as an isolated entity in the world. They respect the fact that customers change their mind. They show respect for the sponsors by not building or keeping functions that are never used and that increase the cost of the product. They show respect by not wasting money on things that are not valuable, not appreciated or might never be implemented or used anyhow. They show respect for users by fixing their problems.

All players respect the Scrum framework. They respect the accountabilities of Scrum.


The players show courage by not building stuff that nobody wants. Courage in admitting that requirements will never be perfect and that no plan can capture reality and complexity.

They show the courage to consider change as a source of inspiration and innovation. Courage to not deliver undone versions of product. Courage in sharing all possible information that might help the team and the organization. Courage in admitting that nobody is perfect. Courage to change direction. Courage to share risks and benefits. Courage to let go of the feint certainties of the past.

The players show courage in promoting Scrum and empiricism to deal with complexity.

They show courage to take a decision, act and make progress, not grind. And even more courage to change that decision.

They show the courage to support the Scrum Values.


This description of the Scrum Values has been translated in 20+ languages. The combined international descriptions of the Scrum Values are available as a free download (PDF): The Scrum Values (International versions) -Oct 2019.

Previous versions of the document can be found at:

A poster of the Scrum Values is available as a free download (PNG): The Scrum Values (poster).

Posted on 1 Comment

Traces of my presence at events (Selected Recordings 2012-2017)

I go to speak at events without commercial or monetary intentions. I primarily go to meet people and share ideas and connect with the Agile communities and Scrum practitioners. On my YouTube channel I have uploaded all recordings of my sessions that are available.

Following is a selection (so far):

2012 – Entering the public domain

In March 2012, at a trainer event, Ken Schwaber checked with me on the possibility of a yearly event about Scrum in the Netherlands. We moved it forward and the first Scrum Day Europe event happened on 11 July of that same year in Amsterdam. My session, “The emergence of the Customer-Oriented Enterprise”, wasn’t recorded, but you can check out my rehearsal of the presentation at the mentioned March trainer event.

Find the presentation at Slideshare.

Note: At the heart of the concepts presented (2012) is the belief I expressed in my book “Scrum – A Pocket Guide” (2013) and the ideas I am building on again in my “re-vers-ify” narrative (2017).

2013 – Scrum for the enterprise

At Capgemini I had already  worked with Ken Schwaber on Agile transformation ideas and Scrum at the enterprise level. As I entered as director for the Professional Series in June 2013, that was our first priority to elaborate on. We presented a first set of ideas at the second edition of the Scrum Day Europe event on 4 July 2013 in Amsterdam.

2014 – Evidence-Based Management

We started focusing more on the inspection part of “Agility Path”. We separated it into “Evidence-Based Management (of software)”. The plan was to present it jointly as the opening keynote of Scrum Day Europe 2014. However, as Ken had visum troubles, I presented it alone.

I had already written a paper about the core ideas of the concept presented. As ideas keep evolving, I started using the term ‘Empirical Management’ and am tending towards using ‘Exploratory Management’ nowadays.

2015 – Scaled Professional Scrum with Nexus

Our focus shifted from organizational transformations back to helping people and teams to employ Scrum. A lot of concerns existed around employing Scrum in the large. Figuring that ‘Scaled Scrum is still Scrum’ we probably ignored the need for too long. We created the Nexus framework, and described it in the Nexus Guide. I presented our approach to Scaled Professional Scrum with the Nexus framework as the opening keynote at Scrum Day Europe 2015.

2016 – The Future Present of Scrum

Scrum has been around since 1995. In the spring of 2015, Ken and I discussed how “Done” was a much misunderstood and certainly undervalued purpose of Scrum. Having created some blog notes about it, I used the 21st anniversary of Scrum (2016) to make it my core speaking topic, as “The Future Present of Scrum (Are we Done yet?)”.

2017 – re-vers-ify

In 2016 I continued my journey of Scrum as an independent Scrum Caretaker. The opportunity to work with diverse organisations and teams helped me consolidate over a decade of ideas, observations and beliefs of Scrum. I realized that all ideas I had been working on before and -certainly- after 2012 were connected. I created a narrative called “re-vers-ify”, or “re-imagining your Scrum to re-vers-ify your organization”.

Too often still the organisational waste, abuse and impediments, ruthlessly highlighted by Scrum, are ignored. Meanwhile organizations grasp for rhythm, focus and simplicity. Re-vers-ify shows a positive path forward, without falsely predicting the end result.

It became my speaking topic for 2017. I presented it as the opening keynote at the first ever Scrum Day Ukraine event in Kyiv on 11 March 2017.

Since 2003 countless people have told me I limit myself by ‘just’ doing Scrum. After 14 years, still, every day is like my first day of Scrum. Every day again Scrum turns out not a limitation but a gateway to options and possibilities to help people, teams and organizations.

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.


Posted on Leave a comment

Polish version of the Scrum Values poster

While developing my book “Scrum – A Pocket Guide” (2013) I described how there is value in the Scrum Values. In 2016 the Scrum Values were added to the Scrum Guide.

I am gratified that Krystian Kaczor delivered the work for a poster of the Polish version of the Scrum Values, available as a free download (PNG): The Scrum Values (Polish poster).

Krystian previously created the Polish translation of the full text for the international Scrum Values PDF (September 2018). Stay tuned for an update of the document by the end of 2018.


Polish version of The Scrum Values: Wartości Scrum

Scrum jest frameworkiem, na którym ludzie i organizacje rozwijają proces pracy, który jest specyficzny oraz odpowiedni do ich czasu i kontekstu. Wszystkie reguły i zasady Scrum służą  empiryzmowi, albo inaczej empirycznej kontroli procesu, który jest najbardziej optymalnym sposobem radzenia sobie ze złożonymi wyzwaniami w złożonych okolicznościach.

Jednak jest coś więcej niż te reguły i zasady. Scrum skupia się bardziej na zachowaniu niż na procesie. Framework Scrum jest oparty na pięciu kluczowych wartościach. Chociaż te wartości nie są wynalezione jako część Scruma, ani nie są unikalne dla Scruma, nadają one kierunek pracy, zachowaniom i czynnościom w Scrum. Scrum jest frameworkiem reguł, zasad i    wartości.

Zaangażowanie (‘Commitment’)

Ogólna definicja “zaangażowania” to “stan lub cecha bycia oddanym sprawie, aktywności, itd. .” Można to zilustrować stwierdzeniem trenera zespołu “Nie mógłby zarzucić moim graczom braku zaangażowania” (chociaż mogli właśnie przegrać mecz).

To dokładnie opisuje jak zaangażowanie jest rozumiane w Scrumie. Zaangażowanie dotyczy akcji i intensywności wysiłku. Nie dotyczy ostatecznego rezultatu, ponieważ ten jest zwykle niepewny i nieprzewidywalny dla złożonych wyzwań w złożonych okolicznościach.

Jednak mylne zrozumienie słowa zaangażowanie było szeroko rozpowszechnione w kontekście Scruma.. Wzięło się to z dawnego oczekiwania frameworku Scrum, który mówił, że zespoły powinny “zobowiązać się” do Sprintu. Także w języku polskim słowo “commitment” ma dwa tłumaczenia, zaangażowanie i zobowiązanie. [przyp. tłum.]  Przez pryzmat tradycyjnego, przemysłowego paradygmatu było to błędnie tłumaczone jako oczekiwanie, że cały zakres wybrany na Planowaniu Sprintu będzie bezwzględnie ukończony do końca Sprintu. “Zaangażowanie” zostało błędnie zamienione na twardy kontrakt.

W złożonym, kreatywnym i wysoce nieprzewidywalnym świecie wytwarzania nowych produktów obiecywanie dokładnego zakresu w czasie i budżecie jest niemożliwe. Zbyt wiele zmiennych wpływających na rezultat jest nieznane lub może zachowywać się w nieprzewidywalne sposoby.

Żeby lepiej odzwierciedlić oryginalne zamierzenie i bardziej efektywnie połączyć z empiryzmem, słowo “commitment” w kontekście zakresu dla Sprintu zostało zamienione na słowo “forecast”, czyli prognoza.

Jednakże, zaangażowanie nadal istnieje i pozostaje kluczową wartością Scruma:

Gracze angażują się w zespół. Angażują się w jakość. Angażują się we współpracę. Angażują się w uczenie się. Angażują się w robienie co mogą każdego dnia na nowo. Angażują się w Cel Sprintu. Angażują się w działanie jak profesjonaliści. Angażują się w samo-organizację. Angażują się w doskonałość.. Angażują się w wartości i zasady Agile. Angażują się w tworzenie działających wersji produktu. Angażują się w szukanie ulepszeń. Angażują się w Definicję Ukończenia (Definition of Done). Angażują się we framework Scrum. Angażują się w skupienie na wartości. Angażują się w kończenie pracy. Angażują się w sprawdzanie i dostosowywanie. Angażują się w przejrzystość. Angażują się w podważanie status quo.

Skupienie (‘Focus’)

Zbalansowane a zarazem wyraźne odpowiedzialności w Scrum umożliwiają wszystkim graczom skupić się na ich kompetencjach.

Ramy czasowe Scruma (time-boxing) Scruma zachęca graczy do skupienia się na tym, co jest najważniejsze teraz bez przejmowania się rozważaniami na temat co mogłoby stać się ważne kiedyś w przyszłości. Skupiają się na tym, co teraz wiedzą. YAGNI (‘You Ain’t Gonna Need It’), czyli Nie Będziesz Tego Potrzebował, to zasada z Programowania Ekstremalnego (eXtreme Programming), która pozwala utrzymać skupienie. Gracze skupiają się na tym co jest najbliższe, gdyż przyszłość jest wysoce niepewna i chcą uczyć się z teraźniejszości, żeby zyskać doświadczenie do dalszej pracy. Skupiają się na pracy potrzebnej do ukończenia rzeczy. Skupiają się na najprostszej rzeczy, która prawdopodobnie może zadziałać.

Cel Sprintu daje skupienie na okres 4 tygodni lub mniej. W ramach tego okresu, Codzienny Scrum pomaga ludziom wspólnie skupić się na niezwłoczne,j codziennej pracy potrzebnej, żeby umożliwić postęp w kierunku Celu Sprintu.

Otwartość (‘Openness’)

Empiryzm Scrum wymaga przejrzystości, otwartości i uczciwości. Gracze, którzy dokonują sprawdzania, chcą ocenić aktualną sytuację w celu dokonania sensownych dostosowań. Gracze są otwarci na temat swojej pracy, tego czego się nauczyli i problemów, które napotkali. Oprócz tego, są też otwarci na ludzi, pracę z ludźmi i zauważenie, że ludzie to ludzie, a nie “zasoby”, roboty, tryby czy zamienne części maszynerii.

Gracze są otwarci, żeby współpracować wskroś dziedzin, umiejętności i opisów stanowisk pracy. Są otwarci, żeby współpracować z interesariuszami i szerszym środowiskiem. Otwarci w dzieleniu się informacją zwrotną i uczeniu się od siebie.

Są otwarci na zmianę, kiedy organizacja i świat, w których działają zmieniają się; nieprzewidywalnie, niespodziewanie i stale.

Szacunek (‘Respect’)

Szerszy ekosystem rozwija się dobrze na gruncie szacunku dla ludzi, ich doświadczenia i osobistej przeszłości. Gracze szanują różnorodność. Szanują inne opinie. Szanują nawzajem swoje umiejętności, kompetencje i spostrzeżenia.

Szanują szersze środowisko przez to, że nie zachowują się jak odcięta od świata jednostka. Szanują fakt, że klienci zmieniają zdanie. Okazują szacunek sponsorom przez to, że nie budują ani nie utrzymują funkcji, które nie są nigdy używane albo takich, które zwiększają koszt produktu. Okazują szacunek przez to, że nie tracą pieniędzy na rzeczy, które nie są wartościowe, nie są docenione albo i tak mogą nigdy nie zostać zaimplementowane ani użyte. Okazują szacunek użytkownikom przez naprawianie ich problemów.

Wszyscy gracze szanują framework Scrum. Szanują odpowiedzialność w ramach Scruma.

Odwaga (‘Courage’)

Gracze okazują odwagę przez to, że nie budują rzeczy, których nikt nie chce. Odwagę w przyznaniu, że wymagania nigdy nie będą doskonałe i że żaden plan nie może uchwycić rzeczywistości i złożoności.

Okazują odwagę, żeby rozważyć zmianę jako źródło inspiracji i innowacji. Odwagę, żeby nie dostarczać nie-ukończonych wersji produktu. Odwagę w dzieleniu się całą możliwą informacją, która może pomóc zespołowi i organizacji. Odwagę w przyznawaniu, że nikt nie jest doskonały. Odwagę, żeby zmienić kierunek. Odwagę, żeby dzielić się ryzykiem i korzyściami. Odwagę, żeby odpuścić <fałszywe> pewniki z przeszłości.

Gracze okazują odwagę w promowaniu Scruma i empiryzmu do radzenia sobie ze złożonością.

Okazują odwagę do wspierania Wartości Scrum. Odwagę, żeby podjąć decyzję, działać i robić postępy, zamiast stać w martwym punkcie. Nawet więcej odwagi, żeby zmienić tą decyzję.

Posted on Leave a comment

Russian version of the Scrum Values (including a poster)

While developing my book “Scrum – A Pocket Guide” (2013) I described how there is value in the Scrum Values. In 2016 the Scrum Values were added to the Scrum Guide.

I am gratified for sharing that:

  • The Scrum Values (Russian poster)Konstantin Razumovsky from (Belarus) created a Russian version of the Scrum Values. Find Konstantin’s full text below. 
  • Mikhail Vyazankin (text), Levon Goncharov (text & visualisation) and Kseniya Panteleeva (translation) from Agileverse (Russia) delivered the work for a poster of the Russian version, available as a free download (PNG): The Scrum Values (Russian poster).

Other translations are being created. They will be combined into a downloadable PDF soon. Stay tuned.

Russian version of The Scrum Values: Ценности Scrum

Scrum – это фреймворк, опираясь на который, люди и организации вырабатывают конкретный рабочий процесс, подходящий для их контекста в данный момент времени.

Все правила и принципы Scrum служат эмпиризму (эмпирическому управлению процессом), как наиболее подходящему способу решать запутанные (complex) проблемы в запутанной среде.

The Scrum Values (Russian)

Однако, кроме правил и принципов, есть кое-что еще. Scrum – это больше про поведение, чем про процесс. Scrum фреймворк базируется на пяти ключевых ценностях. Хотя эти ценности и не были изобретены вместе со Scrum и не являются эксклюзивными для Scrum, они задают направление работе, поведению и действиям в Scrum.

Scrum, таким образом, это фреймворк, включающий правила, принципы и… ценности.

Обязательство (‘Commitment’)

Общее определение термина обязательство (‘commitment’) это “состояние или качество, характеризующее преданность какой-либо цели, деятельности и т.д.” Можно проиллюстрировать это примером, когда тренер спортивной команды заявляет: “Я не могу упрекнуть своих игроков, они полностью отдали себя игре” (хотя, возможно, они не смогли победить). Это в точности отражает значение слова ‘обязательство’ в Scrum. Обязательство – это про преданность и характеризует действия и интенсивность усилия. Это не про итоговый результат, поскольку сам по себе он часто является неопределенным и малопредсказуемым в случае запутанных (complex) проблем в запутанных обстоятельствах.

Тем не менее, существует широко распространенное заблуждение относительно термина ‘commitment’ в контексте Scrum. Оно главным образом происходит из старого описания фреймворка Scrum, который говорил, что команды дают обязательство на Спринт. Через призму традиционной индустриальной парадигмы это было неверно интерпретировано как требование любой ценой выполнить к концу Спринта весь объем работ, выбранный во время Sprint Planning. ‘Commitment’ было ошибочно истолковано как жестко прописанный договор.

В запутанном, креативном и малопредсказуемом мире разработки новых продуктов невозможно давать обещание выполнить точно зафиксированный объем работ с заданными сроками и бюджетом. Слишком много переменных, влияющих на конечный результат, являются неизвестными или могут вести себя непредсказуемым образом.

Для того чтобы лучше отразить изначальные намерения и более эффективно связать их с эмпиризмом, слово ‘commitment’ в контексте объема работа на Спринт было заменено на ‘forecast’ (прогноз).

Однако, обязательству по-прежнему есть место в Scrum и оно остается его ключевой ценностью:

Все игроки дают обязательство действовать как команда. Обязуются обеспечивать качество. Обязуются сотрудничать. Обязуются учиться. Обязуются наилучшим образом выполнять свою работу – и делать так каждый день. Обязуются стремиться к Цели Спринта. Обязуются действовать как профессионалы. Обязуются самоорганизовываться. Обязуются стремиться к совершенству. Обязуются следовать ценностям и принципам Agile. Обязуются создавать работоспособные версии продукта. Обязуются искать усовершенствования. Обязуются следовать Definition of Done. Обязуются следовать Scrum фреймворку. Обязуются фокусироваться на ценности. Обязуются доводить работу до конца. Обязуются инспектировать и адаптировать. Обязуются поддерживать прозрачность. Обязуются подвергать сомнению статус кво.

Сфокусированность (‘Focus’)

Все игроки имеют возможность сфокусироваться на том, в чем у них больше опыта благодаря тому, что Scrum предоставляет им уникальный, но сбалансированный набор ответственностей .

Ограничение по времени (time-boxing) в Scrum стимулирует игроков фокусироваться на том, что наиболее важно в данный момент, а не беспокоиться про то, что имеет шансы стать важным в какой-то момент в будущем. Они фокусируются на том, что знают сейчас. YAGNI (‘You Ain’t Gonna Need It’, ‘вам это не понадобится’) – это принцип из экстремального программирования, который позволяет поддерживать сфокусированность. Игроки фокусируются на том, что неизбежно, поскольку будущее крайне неопределенно и они хотят извлечь уроки из настоящего, чтобы приобрести опыт для будущей работы. Они фокусируются на работе, которая необходима, чтобы довести дело до конца. Они фокусируются на самой простой вещи, которая может сработать.

Цель Спринта дает фокус на период в 4 недели или меньше. В пределах этого периода Daily Scrum помогает людям совместно фокусироваться на непосредственной ежедневной работе, необходимой чтобы наилучшим образом двигаться к Цели Спринта.

Открытость (‘Openness’)

Эмпиризм в Scrum требует прозрачности, открытости и честности. Игроки-инспекторы хотят проверять текущую ситуацию, для того, чтобы логичным образом выполнять адаптацию. Игроки открыты относительно своей работы, прогресса, извлеченных уроков и проблем. Но также они открыты для людей и работы с ними, признанию того, что люди – это люди, а не ‘ресурсы’, роботы, шестеренки или расходные детали механизма.

Игроки открыты к сотрудничеству, пересекающему границы разных дисциплин, навыков и должностных инструкций. Они открыты к сотрудничеству с заинтересованными лицами и более широким окружением. Открыты к обсуждению обратной связи и извлеченных уроков друг с другом.

Они открыты к изменениям, необходимым поскольку организация и мир, в котором они работают, постоянно изменяется: непредсказуемо, неожиданно и постоянно.

Уважение (‘Respect’)

Экосистема Scrum в широком смысле опирается на уважение к людям, их опыту и личным особенностям. Игроки уважают непохожесть (‘diversity’). Они уважают разницу во мнениях. Они уважают навыки, опыт и идеи друг друга.

Они уважают требования внешней среды и не ведут себя так, как будто в мире ничего кроме них не существует. Они уважают тот факт, что заказчики могут изменять свое мнение. Они демонстрируют уважение к спонсорам, не создавая и не сохраняя функции, которые никогда не используются и увеличивают затраты на продукт. Они демонстрируют уважение, не тратя деньги на вещи, которые не являются ценными, полезными или которые могут быть никогда не реализованными или использованными. Они демонстрируют уважение к пользователям, устраняя их проблемы.

Все игроки уважают Scrum фреймворк. Они уважают распределение ответственностей в Scrum.

Смелость (‘Courage’)

Игроки демонстрируют смелость, не создавая вещи, которые никому не нужны. Смелость в признании того, что требования никогда не будут совершенными и никакой план не сможет отразить реальность и запутанность.

Они демонстрируют смелость, чтобы смотреть на изменения как на источник вдохновения и инноваций. Смелость, чтобы не поставлять неготовые версии продукта. Смелость делиться всей необходимой информацией, которая может помочь команде или организации. Смелость признать, что никто не совершенен. Смелость поменять направление. Смелость делить риски и выгоды. Смелость отказаться от иллюзорной определенности старых подходов.

Игроки демонстрируют смелость в продвижении Scrum и эмпиризма для работы с запутанностью. Они демонстрируют смелость в поддержке Ценностей Scrum. Смелость принять решение, действовать, продвигаться вперед, отказываясь от совершенства. И еще больше смелости, чтобы поменять и это решение.