A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done):

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de Scrum.org  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.


Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.


Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.

Introducing Scaled Professional Scrum – Nexus

Scrum is a framework for complex systems development.

  • Professional ScrumScaled Scrum is any instance of Scrum involving more than one team creating and sustaining a product or system.
  • Scaled Professional Scrum is any instance of scaled Scrum that thrives on Scrum’s formal rules and roles, complemented by software development professionalism, and Scrum’s values and principles.

The Scaled Professional Scrum framework of Scrum.org provides guidance to organizations engaging in efforts to scale their product development done through Scrum. The framework cohesively integrates practices, experience and insights gained from efforts to scale Scrum worldwide, including the substantial efforts that involved Ken Schwaber and Jeff Sutherland, co-creators of Scrum.

At the heart of Scaled Professional Scrum is a Nexus, an ‘exo-skeleton’ for Scrum. A Nexus employs the Scrum process to inter-connect 3-9 Scrum Teams building one product.


The Scaled Professional Scrum framework holds 40+ practices. Each of these practices, if chosen and used against context, augments the operation of the Nexus.

The whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF) is now available through the Scrum.org website.

At the “Scrum Day Europe” event of July 2 in Amsterdam I introduced the Scaled Professional Scrum framework of Scrum.org and the Nexus in my opening keynote. Find the presentation at SlideShare. The recording of the session is available at YouTube.

Traces of Scrum (Scrum Days Poland)

On May 28 and 29 the first Scrum Days Poland were organized. A great team made it happen, gently directed by two friends of the Scrum.org trainer community, Kate Terlecka and Tomek Wlodarek. Kate and Tomek were so kind to invite me for two sessions at the event:

  • In the executive track I spoke about ‘Empirical Management’. Find the slide deck at SlideShare.
  • For the main event I was asked to do the closing keynote, which was about ‘Scaled Professional Scrum’. Find the slide deck at SlideShare.

Apart from these sessions, I was asked for some thoughts on Scrum by different people:

1/ On behalf of the organization, Paweł Feliński checked in with me on some topics with regards to Scrum, and the adoption of Scrum:

2/ Leszek Pietrzkiewicz went around asking some people, including myself, to ‘describe’ Scrum in one word:

3/ Leszek Pietrzkiewicz asked me ‘Why do Scrum?’

4/ Andy Brandt, another Polish Professional Scrum Trainer, asked me some questions about Product Ownership, questions he typically gets from the attendants of his PSPO classes:

I applaud the local organizers for setting up such a great conference. I am grateful for being at the conference, meeting people and expressing the above thoughts. Traces of Scrum.

Celebrating two years at Scrum.org (#frwrks)

March 2013, Amsterdam. Ken Schwaber and I semi-simultaneously express the thought that there is likely more value in us engaging in a close partnership. We already have a pretty intense collaboration at the time. I decide to leave consulting, a well-known environment that I have been in for twelve years. I take some time off, do a couple of Professional Scrum classes, and lay the foundation for my book „Scrum – A Pocket Guide (A smart travel companion)“.

June 1 2013, Boston-Antwerp. I embark on this somewhat unexpected journey of working at the home of Scrum, Scrum.org.

Over these past two years a three-fold pattern of activities emerged being part of the Scrum.org team:

  • Shepherding the Professional series. Developing and sustaining Professional Scrum assessments and courseware, training trainers, working with the global community of Professional Scrum experts and within the small-ish, creative organization of Scrum.org.
  • Representing Ken and Scrum.org in Europe. Visiting partners and friends of Scrum.org, and taking up speaking and learning engagements.
  • Teaming up with Ken. Engaging in all sorts of interesting development activities, with the most important thread probably being the road from Agility Path to Scaled Professional Scrum and the Nexus.

Not working for a traditional enterprise turned out such a relief, the end of thinking and acting in terms of money and commercial motives only. No hour-based work, no office hours, working (mainly) from my home office, no timesheets. Instead mission-driven efforts, autonomy and valuable goals. Money is obviously important, up to the level of being able to pay our people a decent salary and to invest in the community. Beyond that however our goal is to support people, teams, organisations, with resources for assessment, improvement, maturing Scrum, growing professionalism, improving the profession of software development. It is not the most common model for a business, but it is what we do.

The two years at Scrum.org have shown me that there IS an alternative to the traditional way to run a business, an alternative that is financially viable, yet doesn’t revolve exclusively around financials.

Over these two years I’ve maintained mental stability, remained sane. No different than in every other environment I’ve worked in before, I’ve had my crises, my identity doubts, my ups and downs. I’ve come to terms with aspects of me that used to confuse me in the past, often in my past positions as Scrum Master. I’ve come to terms with blending in and still not fitting in. The best and most fascinating relationships are developed by not fitting in. It took me years to accept that, let alone exploit that. It’s a solid basis to continue my journey, my remarkable cobblestone path.

I wish you all the best. I thank you for all the inspiration. I am proud to be able to continue serving many Scrum professionals around the globe.


Shepherding the Professional series

Ullizee -Seal 2104Scrum.org-Logo_with_tagline

Done is a crucial part of Scrum, actually

If Scrum was to be reduced to one core purpose, and one only, that purpose would be the creation of a releasable Increment of product in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.

Done Increments are THE way to achieve agility through the empiricism of Scrum. 


The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.

The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.

The definition of Done serves empiricism

The definition of Done should be shared, explicit, clear and concise.

A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.

The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.

No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.

Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.

Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.

At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.

Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.

Done is a crucial part of Scrum, actually

Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.

In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.

Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.


The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.


(moving houses, gardening, and new dimensions)

Early 2001. I decide to resign. My wife only asks me to pursue an occupation that keeps me challenged for more than two years. A reasonable request. After all, since graduating in 1992 I worked less than one year as a software engineer (on VAX), less than three years as a hardware and software engineer (C++ and micro-assembler), and we had a bookshop for about three years.

MagnoliaAnd, well, my two years with this start-up e-commerce were pretty turbulent too. An unaspired climb to ‘senior manager’ (layered titles are part of working with former McKinsey people). Bribed into a stock option plan (brilliantly devalued through the e-com bubble burst, draining the very little savings we had made since our bookshop days). Franticly favoring people over structures. Fourteen hours working days (commuting not included). IT and back-office manager (titles being what they are). In the end, endless disagreements with the manager-founders. Over which I quit (despite my emotional investments). To be pulled back by the investors, and end up as a dehumanized puppet in strategic schemes. Once our company survival plan takes shape, I leave anyway, disgusted by the offer of IT Directorship.

I enter the unknown territory of consulting to spend six years at one company (a world record, truly), only to discover true joy again (almost at the level of the bookshop) through eXtreme Programming and Scrum in 2003. I grow my small 10-person company within the company, a chapter ending with a top-down inspired mutiny early 2007. Before the mutineers are struck down by depressions and other forms of nervous breakdowns I had set sail again. Recover, move on.

After two adventures of less than three years I leave consulting in 2013. I had just been upgraded to ‘principal consultant’ (titles, again, not work). I had put my heart, soul and passion in Scrum at these companies. It dropped dead. I felt highly miserable over that. Until people pointed out how it had influenced many, many individuals, and inspired a few enterprises. Just not the consulting company’s structures.

Having intensely collaborated for some years, mostly as a Professional Scrum Trainer, I move to the home of Scrum to join Scrum.org and partner with Ken Schwaber in 2013.

Spring 2015. These past two years Scrum has been the focal point of whatever it is I do. I even wrote a book on it, which seems to be well received by those who read it. I realize I have traveled. Happy not getting anywhere. Traveling is what we do, still.

Cherry BlossomOur horizon expanded from the smallest thinkable village in Belgium to Belgium itself, to the Netherlands and Europe, to working with people around the planet. An enlightening and humbling journey. Full of things that take time. Beauty. Growing flowers. Becoming what I didn’t know I wanted to be. Unlearning. Mastery.

I remain in doubt. A constant state. I am good at searching. I am terrible at finding. But gradually I grow less ashamed.

My family is my stability. We lost people (some dear, some not). We gained liberty. We have three kids (two have disabilities). We cope. We prosper. We bought a house we didn’t know we wanted. We are close. We travel. Too.

I have found I have personal values. They have served me well on my traveling. They helped me decide to resign. They help me look beyond a career, beyond scoring off other people, beyond lies, beyond backstabbing.

I am writing this to share. There is nothing but the world to share it with. I am cleaning the house. I am writing this to find out. Maybe I will stop reading mails for a year and 3 days. I am good at trying. I won’t succeed. That’s fine. That is beauty. I am grateful. I discover. Serendipity.

Music. Reboot.