Scrum Day Europe 2014

As from 2011 there has been a genuine boom of Scrum in the Netherlands. And it is still going on. A virus improving the lives of many people in the fascinating world of software development. I have worked with several Dutch organizations, of which ING is probably one of the biggest, one that I documented by the end of 2012.

In March 2012 Ken Schwaber, Scrum co-creator and my working partner at, asked whether I saw room for a Scrum event in the Netherlands. Yes, and we named it “Scrum Day Europe”. We set it up with 3 co-organizing companies around the ideas of “Software in 30 Days”. The goal was not to make it just another average agile event, so we went for a smaller event, with a clear management focus and much room for interaction. It turned out a great success, so a 2013 edition was organized with some small, incremental changes. Ken and I opened the 2013 edition with a keynote on the Agility Path framework for Enterprise Scrum that we were working on.

ScrumDay4Pros-logo_whiteThis year, 2014, will see the 3rd edition of the Scrum Day Europe event. The event is now part of’s prestigious Scrum Day for Professionals series. We have limited the co-organizing companies to our partner-in-principle Prowareness and have complemented that with a more substantial involvement of the communities. Because, in the end,’s role is to serve, help and facilitate the many Scrum practitioners out there, and this event is a great way to connect people and ideas.

The theme of 2014 will be “Evidence-Based Management”, on which I recently published a whitepaper called “Empirical Management Explored: Evidence-Based Management for Software Organizations“.  Ken and I will have the pleasure of opening the event again.

I look forward to meeting with great fellow Scrum travelers at the event, hoping YOU will be one of them. Have a look at the program and the speakers. Get your ticket via the Scrum Day Europe website, or directly at

Scrum Day Europe 2014

Find all information on Evidence-Based Management at

Scrum: Tactics for a Purpose

Scrum is a framework designed to help teams create and sustain complex software products in complex circumstances through the scientific method of empiricism. Scrum has replaced the industrial, plan-driven paradigm with well-considered experimentation to better deal with the complexity and unpredictability of modern software development. And although the use of Scrum is free, its roles, artifacts, events, and rules are immutable. Implementing only parts of Scrum is possible, the result however is not Scrum. By breaking its base design it is likely that problems are covered up, instead of being revealed.

The purpose of Scrum is to help people inspect & adapt, to provide transparency to the work being undertaken, to know reality to base decisions on, to adjust, to adapt, to change, to gain flexibility. The rules, principles and roles of the framework, as described in the Scrum Guide, serve this purpose. These are the rules of the game of Scrum, the base setup to have in place.

Soccer - Rules of the game

But we distinguish principles from techniques, the what from the how, the rules of the game from tactics to play the game. It’s like in all games and sports, all players and teams play upon the same rules, yet some teams seem more successful at playing than other teams. It depends on many factors, and not all are equally controllable by the teams themselves. One factor are the tactics used by the team to play.

Soccer tactics on a blackboard

There are many tactics to use within Scrum. Good tactics serve the purpose of Scrum. Good tactics re-enforce the Scrum values, not undercut them.

I’ve previously described how practices from eXtreme Programming provide great tactics, ways to play Scrum, even when not mandatory from the Scrum perspective.

Here are some more illustrations on the distinction between the purpose of Scrum and tactics for that purpose:

The Daily Scrum questions

The Scrum Guide suggests that in the Daily Scrum meeting every player of the Team answers 3 questions (Done? Planned? Impediments?).

But the players might just formally answer the questions, limit it to a personal status update, and talk to the walls or to the Scrum Board. They just make sure that they -well- answer the 3 questions. Because the Scrum Guide tells them to, or some smart coach or Scrum Master or manager.

But is the team seeing Scrum as a methodology? Or use Scrum as a framework for discovery? It doesn’t help much if they don’t talk to each other. It doesn’t help much if they don’t surface the information to optimize their collaborative work plan for the next 24 hours against the Sprint Goal. Maybe they use the meeting only as a reporting obligation in which they make sure all their microtasks are logged, to cover against possible blame. They miss the opportunity to gain insight in the real situation, to inspect it and to adapt upon it.

Maybe Scrum should describe only ‘what’ is expected from the Daily Scrum in the time-box of 15 minutes. Although, actually, the Guide already does so by saying: “The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” We could eliminate or rephrase how this is exactly to be achieved, in turning the 3 questions into a good, yet non-mandatory, tactic.

The Definition of Done

The Definition of Done was rightfully given a lot more attention in the latest version of the Scrum Guide. However, some people wonder why it isn’t an official artefact. I did so too, even launching the suggestion to make it one. However, I got to see that the Definition of Done is an aid to transparency, and I overcame my urge to turn it into an artefact.

Here’s how the Definition of Done helps playing Scrum:

  • Scrum assumes an inspection of a working product Increment at the end of every Sprint, at the Sprint Review. The Definition of Done gives transparency to that inspection by unveiling what’s the work that has been done upon the Increment, what criteria were met.
  • The Definition of Done guides the team at the Sprint Planning to pull work into the Sprint, as the work needed to get to “Done” is likely to influence the amount of Product Backlog that can be pulled into a Sprint, as well as the estimates for that work -if the team uses any-.
  • The Definition of Done helps the team create and manage their work plan for the Sprint in getting things done, and not end up with a pile of nearly-done work at the end of a Sprint.

So, what Scrum requires is transparency. The Definition of Done is a way to provide that transparency at several levels and several occasions. It’s a great tactic that stresses the importance of seizing the opportunity to ship.

Product Backlog Grooming

Product Backlog grooming is an activity in which the Development Team and the Product Owner look at Product Backlog currently sorted for one of the next Sprints. Certainty that the included items actually are going to be implemented is growing. So teams might want to unveil dependencies or help a Product Owner understand what is useful to know from a development perspective. Grooming increases the chances to pull the work in more easily when it is presented at the next Sprint Planning.

Product Backlog grooming is not a mandatory (time-boxed) Scrum event. The ambition of Scrum is to remain simple, yet sufficient. The ambition of Scrum is to help people and teams discover additional practices that may or may not be appropriate in their specific context. Product Backlog grooming is an activity that seems to help many teams to smoothen their Sprints, and certainly limit turbulence in the first days of a Sprint. Other teams however cope without it, and perceive it as optional or even overhead if it was mandatory from the Scrum framework.

Product Backlog grooming is a great activity within a Sprint, a good tactic to collaboratively manage Product Backlog. Some can do without however.

Sprint Planning Part 1+2

Sprint Planning meeting is an opportunity to inspect the actual state of Product Backlog and identify what work is most useful and feasible at the actual point in time, with the option of pouring the work into a work plan for the Sprint.

The empiricism of Scrum assumes following for the Sprint Planning:

  • IN: Product Backlog
  • OUT: Sprint Goal & Sprint Backlog

Currently the Scrum Guide prescribes the flow of the Sprint Planning meeting:

  • Part 1: Product Owner explains highest sorted Product Backlog items. The Team discusses, evaluates and pulls in items. A Sprint Goal is crafted.
  • Part 2: the Team decomposes, discusses and designs the work.

It is however possible to respect the IN and OUT of the Sprint Planning meeting upon a different flow of the meeting. Maybe Scrum can suffice by describing only ‘what’ is expected from the Sprint Planning in its time-box without prescribing ‘how’ the Scrum Team should achieve this. Organizing it in a part 1 + part 2 might be a great tactic, but it’s probably not the only one.

Moving to the home of Scrum

Why I look forward to working with Ken Schwaber and being part of, the home of Scrum.

Less than a year ago I was wondering about rather surprising evolutions in my professional life of Scrum. I retrospected to find that some things take time, can’t be rushed, let alone be predicted. Ending up with the feeling of being carried to places one never imagined of entering.

That was June 2012. Now is April 2013.

Over the past years Ken Schwaber and I have developed, almost by accident, a great personal and working relationship. Beyond that, I have an awesome contact and understanding with the team. Both aspects contributed to my well-being, made me feel good, respected, cherished even at times. And that was just fine. It helped, it inspired me in my work, it gave me opportunities to bounce ideas off.

Very recently, my daily times and work got into turbulence, with my stress levels going red. I realized that few people understand, understand what drives and motivates me. Hmm, some would say it’s just frustration born out of stubbornness and impatience. Ken and I tightened the relationship. Until we decided to move it to a formal level. And in no more than 1 week we completely arranged for my move to the home of Scrum and become part of the team.

It wasn’t planned. It happened. It emerged from a chaotic situation of doubts, searching, thinking and many considerations.

Who would have guessed?

Being a bit of an anarchist myself, I consulted with knowledgeable dilettante people in that 1 week. Opinions were unanimous: it won’t be a picnic, it will be an adventure, highly challenging, but fascinating and brilliant. Hmm, Ken himself says it will be a walk in the park. But that’s probably because he knows of many past motions that I have gone through. And, despite some controversy and him being a mule, few people would doubt Ken is an honorable, intelligent and trustworthy person to work with.

Luckily we consider ourselves just about weird enough to work with each other. We are both impulsive, impatient. He’s a mule, I’m stubborn. We have much in common; above all we seem to share many views and values. We go for vision, focus and creativity. And I am proud to be creating a little room of the house of Scrum in Antwerp, Belgium, Europe. I’ll be joining a great team, and serve the communities of Scrum practitioners, promoters of Scrum and our Professional Scrum trainers; thriving on autonomy to work on my mastery in Scrum and Enterprise Scrum from the purpose of making this world a better place to live and work in.

Type I behavior: A way of thinking and an approach to life built around intrinsic, rather than extrinsic, motivators. It is powered by our innate need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.

Ken and I made up a little news announcement to express our excitement. Find it here: News – Ken Schwaber and Gunther Verheyen tighten relationship. Logo

Scrum Day Europe 2013

Scrum Day Europe

On 11 July 2012 the first edition of the Scrum Day Europe was organized. The theme of the day was “Software in 30 Days”, after the book that Ken Schwaber and Jeff Sutherland published in April 2012. In line with the book, our objective was to address executive people of organizations interested in or already adopting Scrum. Over 130 attendants came and made out an uncommon audience for an agile conference, turning it into not your average agile conference but with tons of energy and enthusiasm.

On 4 July 2013 the second edition of the Scrum Day Europe will be organized. The 2013 theme is “Enterprise Scrum“, after the new C-Scrum framework for Continuous Improvement that has developed. I was so lucky to be deeply involved in this great evolutionary step in the existence of Scrum. Ken Schwaber will again open the day with a keynote. Yours truly will also do a session again. The program will be further developed soon.

Be quick, seats are limited so we can unlimit energy and interaction.

Scrum Day Europe Banner

Scrum: Framework, not methodology

Scrum is not a methodology

Scrum has no exhaustive and formal prescriptions on how to design and plan the behavior of all software development actors against time, let alone how these designs and plans must be documented and stored. Scrum has no rules for upfront predictions of document types and deliverables to be produced or the time of their production. Instead of installing and thriving on hand-overs, toll gates and control meetings like software development methodologies typically do, Scrum removes them as a major source of delays and waste.

Methodologies are composed of stringent and mandatory sequences of processes and procedures, implementing predefined algorithms. As such, methodologies tend to replace the creativity, autonomy and thinking of people with components like phases, tasks, must-do practices, techniques and tools. As long as the methodology is being followed everyone feels safe, because they are formally covered, even in the absence of working results. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail.

Scrum is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems.

Is Scrum a process?

If Scrum is a process, it is certainly not a repeatable process. That’s often a challenge to explain, because the term ‘process’ typically invokes algorithmic predictable steps, repeatable actions and enforceable top-down control; the sort of expectations for a… methodology.

Scrum is not a commanding process. If referred to as a ‘process’, then Scrum is a servant process. What works best for all involved players, their working process, emerges from the use of Scrum. The players discover the work required to close the gap between an inspected intermediate result and an envisioned outcome. Scrum is a process that helps surface the real process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we prefer to call Scrum a… framework.

Scrum is a framework

Scrum as a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way. The Scrum Guide holds the definitive description of these base rules of the game. The prescriptions are minimal, but every single one of them addresses a common dysfunction of software development.

Over the nearly 20 years of Scrum, the rules of Scrum, as captured in the Scrum Guide, have gradually evolved, with small functional updates and releases. The prescriptions of Scrum, what needs to be in place to have the full benefits of Scrum, becomes more and more focused on emphasizing ‘what’ is expected in developing complex products over instructing ‘how’ to do it.

A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (the ‘how’). This obligation however has been replaced by the explicit expectation that progress on the mandatory Scrum artefacts, the Product Backlog and the Sprint Backlog, is visualized (the ‘what’). The form or format of the visualization is no longer prescribed, thereby turning burndown charts into a non-mandatory, but still good practice; a good way to play the game suitable in many situations.

Yes, it’s Scrum if the Backlogs exist and a visualization of their progress is available, accessible and clear. This may be a burndown chart with open effort. It may also be a burnup chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.

The Scrum framework leaves different options and tactics to play the game, ways that are at any time adopted to the context and circumstances. The Scrum core values give direction to the actions, the behavior and the additions to the framework. Upon that core, in a ScrumAnd way of thinking many opportunities emerge. Have a look at some illustrations of ScrumAnd.

Ways to play Scrum our Professional Scrum classes we also talk about the topics of User Stories, Planning Poker and (Daily) Stand-up meetings. Some attendants have never heard of it. Some have never practiced it. Some are convinced, or have been instructed, that Scrum says these are mandatory to do.

I have grown my own little pattern to work with a class whenever we run into one of these topics during my classes.

  1. I start by asking what Scrum actually says on the practice. In general, people don’t know or are not sure, and conclude that Scrum says nothing about it.
  2. I ask where the practice then does come from, if it’s not Scrum. Few people know that it is eXtreme Programming.
  3. I end up by saying that, despite the XP origins, we do support them in many cases as they represent good ways to play Scrum, they are good practices to chose from. And that this is the reason why we cover them in the course; to inspire people with different options to play Scrum.

But, they are not mandatory from the Scrum framework described in the Scrum Guide:

  • Extreme Programming Explained: Embrace C16614_fUser Stories, written on story cards, are the practice in Extreme Programming to hold and describe requirements from a user perspective. Bill Wake, author of ‘eXtreme Programming Explored’, suggested the ‘INVEST’ acronym as a simple way to remember and assess whether or not a User Story is well formed.
    A Scrum Product Backlog though serves to provide transparency to all work that a Scrum Team needs to do, which might be more than only functional requirements. The obligation, from Scrum, to use the User Story-format would endanger forgetting other important work to be undertaken, or it might force teams spending more time and energy on using the ‘right’ format, thus creating waste. However, for functional items on the Product Backlog, User Stories may be very good.
  • Planning Poker was invented by James Grenning during an eXtreme Programming project where he suffered from having to spend much, much time on producing estimates.
    In Scrum, estimates are to be created by the Development Team and, although not mandatory, Planning Poker is a good technique to do that. It leads to more honest estimates from a complete team. But don’t forget that the intention is to invoke an honest conversation over the estimates. Because that results in a good understanding of the work attached to implementing the discussed item.
  • Daily Stand-up are described in Extreme Programming, which recommended participants stand up to encourage keeping the meeting short.
    Scrum describes this meeting as the Daily Scrum, but doesn’t oblige to do it standing up. However, it is a good idea to do, especially to keep the time-box of 15 minutes.

That is often a relief to students, knowing that it is not mandatory. And I am glad I can help people. I am glad they see more opportunities to discover their own best way to play Scrum respecting the intentions and design of Scrum. They see better how Scrum can help teams and organizations emerge their own process. These ways to play Scrum in teams’ specific contexts turn the selected good practice into best practices.

Scrum, after all, can be called a ‘process’, but it’s a servant process, not a commanding process.

Why It Took Time (to become what I didn’t know I wanted to be)

The terrorism of an alcoholic father left me with serious damages and memories of a loveless youth. Nevertheless I graduated as Industrial Engineer in electronics in 1992, age 22. An opportunistic choice of study as philosophy or literature didn’t offer the same job certainty. Purpose?

Time for a little retrospective exercise. What has happened in the 20 years since my graduation? What has been most influential in becoming who I am today? And why did it take that time?

The formative years

I was deeply disappointed when entering the labor market as my grade created the expectation of thorough technical insights while I had hoped for some staff position, and the possibility to work with teams.

My first job was software engineering on VAX but I remember most the great times I spent in the great country of Ireland. After a little project on OS/2 I moved to a small company in 1993 to do assembler programming on Micro-PIC controllers. My 6 months trial period wasn’t too convincing but a one month prolongation did show some success in planning and purchasing, combined with Borland C++ and Paradox programming.

Blind enthusiasm and overwork burned me out so I left in 1996 to take over a bookshop of a large chain on a franchising base. A client of our shop pointed me towards Nietzsche and his ‘Beyond Good and Evil’ (and later on his other works) was an incredible eye opener. Since then I kept saying that 90% of who I am, I am due to my wife and 9% due to Nietzsche. Nietzsche revealed the bare truth to much of my struggles with life to that date. Although my wife and I had the time of our lives being all around books, and we moved to a bigger shop twice, on the last day of 1998 we had to decide to quit. The reason was the imbalance of income, social life and personal development; and being on the verge of debts.

In 1999 I started as business developer for the first Belgian e-commerce site for books and CDs, where I soon grew into a senior management position. By the end of an exciting but burning period I remember me creating a mega (no, wait, giga) analysis for a complete new back office (from IT to logistics), which was my domain to lead. It only took me 3 hours to get a team through it. Once. I don’t know whether it was that analysis or the complete renewal of our server park, but just after I resigned in 2001, I was offered the position of IT director at the company. Although I did co-write a post-crisis survival business plan for the company, I still decided to leave. I felt too young, too inexperienced and -above all- my views on the people aspect were quite different from our investors and other leading managers. I rightfully left, is my opinion still. Later that year, our first son was born.

The Years of Dedication

In 2001 I started working for a large local (Belgian) consulting company.

For my first project I did a complete functional analysis, took the lead in contracting and other negotiations and continued as ‘project manager’. Management advised me not show the estimates to the team. But I did, and it didn’t prevent the project from ending up break-even where all other fixed prices ended in major losses. But I specifically remember helping a team member through a difficult divorce situation. Without minding the actuals.

In 2003 our second son was born. He turned out to have Down Syndrome. Professionally I got called to urgently lead a new project that seemed unfeasible despite the fancy MS Project promise. It took 15 minutes for 2 software architects to convince me about eXtreme Programming. It just had all elements fixed in the method that I had -to a certain extent- tried to do in my first project: communication, iterations, feedback. In December 2003 I presented this project as the first major production XP implementation in Belgium at Javapolis.

When scaling up with the next phase of the project we added Scrum in 2004. I went well-prepared, i.e. having read his 2 books at that time, to a CSM class by Ken Schwaber. And we replaced our organizational XP practices with Scrum practices and names, but we kept doing the core engineering practices (pair programming, TDD, continuous integration, automated testing).

By the end of 2006 we had successfully delivered 2 more phases of our early Agile project, and applied Scrum + eXtreme Programming in 2 additional large website applications, incorporating extensive front-ends, back-ends, integrations and interfaces. Those projects learned me that inclusion of incremental development of even major UX-components is feasible, and even to be preferred.

Due to lack of respect for our results and for the people I decided to leave in 2007. And to date I’m still struck by the observation of an esteemed colleague and team member that I had never consciously made myself, i.e. that he loved the way I tried to turn a project into a total, 360° experience of joy, fun, energy and… results. Never satisfied with less.

Richard Dawkins deepened my Nietzsche experience by adding a genetic and memetic dimension to it. By the end of the year I started at another consulting company, led and blinded by promises of a management position. Around that time our oldest son, age 6, was diagnosed with Duchenne Muscular Dystrophy. Having read Richard Dawkins helped in surviving and dealing with the genetic flaws of our 2 children.

The empty management promises finally covered 2 years of my life in stress and agony. I fought, battled and barely survived, before returning to my Agile roots. I realized that I had never cared about any ‘CS*’ certifications or whatever career, that my satisfaction had been in working with teams and clients, joyful projects, and that I still didn’t care about careering. Therefore I was attracted by the community orientation of Ken Schwaber’s new platform, and followed and joined it from the early days in 2009.

2010 did not only see me giving consultancy a last chance at my current employer, but after 2+ years of medical uncertainty and wandering our daughter was born. No genetic problems, not even carrier of DMD. My first professional experience wasn’t too comforting, but I applied my iterative-incremental approach and turned my first project, once more, and once more against all odds, into a 360° success. In the mean time I evolved with and did the Professional Scrum Master assessments (level I and II), and decided to firmly proceed on that path. I applied for Professional Scrum Trainer for which I went to a PSM class by Ken by the end of 2010 in Zürich.

Booming Business

And then, suddenly, there was 2011. Dutch colleagues found me. I developed an internal Scrum training, which was highly appreciated and became very successful. It opened important gates at clients, caused some amazing breakthroughs and I mutated to another division. I followed the early Professional Scrum Product Owner program and soon became Professional Scrum Trainer in PSM and PSPO.

I had a boost in understanding and living Agility, not in the least through the mentoring and lessons by Ken. My perspective quickly broadened. Authors like Daniel Pink (“Drive”) and Nassim Taleb (“The Black Swan”) augmented my general world views, and greatly supported my belief to use people and empiricism to cope with the complexity of our world. I am now the global expert on Scrum at my company (120.000 people worldwide). And the end is not nearly in sight. Scrum has become a substantial part of what we do and offer. We train our consultants and our clients, we coach and guide them, we promote Enterprise Agility and we inject more and more agility into our own organization.

Soon I will be talking at the Scrum Day Europe event that initiated and that we co-organize. I will introduce how I perceive the Emergence of the Customer-Oriented Enterprise. Previous ‘confessions’ gave some insights in what might have influenced how I developed my views. Who knows what will happen next to change how I see things?

Not Future

Some things take time. Beauty. Growing flowers. Becoming what you didn’t know you wanted to be. Unlearning. Mastery. Dedication and determination.

I am still without much formal title or position. I regularly struggle with the gigantic, monstrous machines that corporations tend to be. I regularly want to flee back to the underground when balancing my personal ethics against my desire for impact. Overall however, I manage and it works out… without power games. I am epigenetically (the seeds sown in my youth) unable to play power games, but I’ve learned to use that in my advantage.

In 2012 I am even making enormous progress on my scales of valuation. In the past I usually was merely tolerated, in the best case appreciated.  Here I am now, not just being motivated, but even able to innovate.


I started writing this blog note to give people insight in what it sometimes takes, at least time, to learn and evolve. I was long in doubt whether to continue this text when I started reading Lyssa Adkins’ book Coaching Agile Teams. Having read the first chapter I decided to go for it. Because my message reflects how I became to ‘be’, not only what I ‘do’. Painful sometimes, but honest. Hoping it might help or inspire others. Hoping it helps people understand that it takes time. The path and the patience pay off. I can now go back to Lyssa’s book again and finish reading it.

Let’s make the Definition of Done a Scrum artefact

In the last Scrum Guide (July 2011) the Definition of Done was given considerably more attention. Rightfully, as the DoD is crucial in Scrum.

The Importance Of Done

The Definition of Done is essential to fully understand the Increment that is being inspected at the Sprint Review with the stakeholders. The Definition of Done implements the expectation of an Increment to be ‘shippable‘, so ideally it is comprised of all activities, tasks and work to release an Increment in production. The addition ‘potentially‘ to shippable refers to the Product Owner’s accountability to decide over the actual release of an Increment; a decision that will likely be based upon business cohesion and functional usefulness. But the Product Owner’s shipping decision should not be constrained by ‘development’ work.

The Definition of Done should be clear and concise for the Scrum Team as it will determine how much work a Development Team can reasonably take in into a Sprint during the Sprint Planning meeting.

The empiricism of Scrum only functions well upon transparency. That includes the Definition of Done. Transparency means not only visible, but also understandable. Besides being available, the content of the Definition of Done should be clear by just reading it.

A New Scrum Artefact

I suggest to make the Definition of Done an official Scrum artefact.

Because it is an adaptation of Scrum to reality, a mere formalization of an existing practice; because it is extremely important to put quality even more at the heart of what we do; because we want to clear out that little grey zone in the base Scrum framework allowing some people to doubt the formal need of a Definition of Done. With regards to the latter, it will provide additional guidance for people and organizations to improve, and investigate the next steps on the cobblestone path to Agility.

All existing Scrum artefacts support the ‘inspect & adapt cycles of Scrum; they provide accurate, up to date and transparent information to be inspected and adapted at the rhythm of the Scrum meetings (or sooner). I suggest to primarily do an inspection on the new Definition of Done artefact at the Sprint Review, along the inspection of the working Increment. This pair-wise inspection serves to get feedback and input from the stakeholders that goes beyond mere functionality and business requirements. It will invoke a collaborative conversation over quality, and requirements with regards to the quality of working software in the organization.

The Sprint Review is also the time to inspect the current state of Product Backlog, i.e. what is now Done, what was left undone in this Sprint, what was additionally turned Done. From this current state, including the latest Velocity measurement, the actual product progress is available to the stakeholders.

I suggest to lay ownership over the Definition of Done with the Development Team. A Definition of Done can’t be forced upon a Development Team. Neither can it be cut short by forces outside of the Development Team. The Development Team will obviously include functional quality expectations from the Product Owner. The Development Team will obviously include general, organizational expectations and compliance (e.g. from the engineering organization). But it’s up to the Development Team to process it in the Definition of Done. Decisions over the Definition of Done will depend on the presence of skills, authorizations and availability of external systems, services and interfaces. Probably a Development Team would include stubs and simulators for non-available systems, add this to their Definition of Done and make the impact of these dependencies clear to the Product Owner in her/his sorting of the Product Backlog. The effect on the planning horizon will no longer only be clear to the stakeholders by inspection of the Product Backlog at the Sprint Review, but also via explicit inspection of the Definition of Done accompanying the working Increment.

The inspection of the working Increment and the Definition of Done at the Sprint Review, and the related collaboration of the Scrum Team with the stakeholders, will provide the Development Team with important information to sustain, evolve and grow the Definition of Done. They will probably have a deeper conversation over it at the Sprint Retrospective. The self-organizing drive of the Development Team will include all that’s actually possible, dig deeper, taking into account the feedback from the stakeholders, and evolve it as part of their continuous improvement of quality.

This ownership is comparable to the Product Backlog ownership. The Product Owner has accountability over it. But it won’t withhold the Product Owner from taking into account the technical and development input from the team. It won’t withhold the Product Owner from taking into account dependencies, non-functionals and organizational expectations. And after all, the frequent inspection of a working Increment provides information on reality to all involved so they can incorporate that in their work via their accountability.

A Desirable Side-effect

Although it is not an objective of promoting the Definition of Done to a Scrum artefact, I do see an optional side-effect: additional transparency to the overall agile adoption.

Obviously the Definition of Done will not always immediately, from day 1 of the adoption of Scrum, hold every possible task, activity or requirement to render every Increment completely production-ready. There will be a gradual evolution in applying Scrum. This is good as it helps all players continuously exploit the possible to a maximum extent.

Promoting the Definition of Done to an artefact, that needs to be inspected and is open for adaptation, will help identify improvement areas in capturing enterprise agility. The finding of what is/is not included provides an indication on involvement of the broader organization in agile product development, even of organizational impediments. And stakeholders, in consultation with Product Owner and Scrum Master, might want to act on these from a management change perspective.

In a transformational period, including the Definition of Done as an explicit artefact in the Scrum framework will help people and organizations in the software industry to… improve from better and more realistic insights.

The Scrum Gameboard

In our Capgemini trainings on Scrum we’ve been using the Scrum Gameboard to represent all Scrum framework elements in one overview.

We’ve taken the liberty to already add the Definition of Done. Because, whether an official Scrum artefact or not, the importance can’t be overstressed.

Personal Professional Scrum

Precaution: the author (me) is lately sharing a load of personal, retrospective findings with the world (you). Must be that he’s leaving some troubles and worries behind him. Or maybe it’s just the pills he’s taking?

It wasn’t until I started doing projects upon eXtreme Programming (2003) and Scrum (2004) that I finally found my way in IT, and started feeling at ease at a personal-slash-professional level. It then still took me several years (>2011) to find a professional homebase (some call it an employer) where I could really ‘go’ for my Agile and Scrum ways.

In the early years I never cared about profile or promotion; just me, expertise & the teams. But on the cross-point of deciding yes or no to stay in IT consultancy, I decided to give it one more chance. But it would be a ‘make or break’ and it had to be Agile and Scrum. I resurrected the knowledge and experience hidden in my brain and started publishing about it again. I finally went to Capgemini (March 2010), attracted by the fact that they had co-founded the Agile Consortium Belgium.

This was around the time that saw the emergence of by Ken Schwaber. I had my CSM by Ken back in 2004 but that was it. Never even considered CSP, CSC, CST or any other CS*. My reluctance for profile and promotion, you know. I liked the feel and the why of and engaged early. Full of doubts, but I demonstrated a good understanding as Professional Scrum Master, level I and level II. Confidence grew, I applied for PSM trainer, went to a PSM course by Ken (December 2010) and qualified as trainer.

Happily invited at an early class of the new Professional Scrum Product Owner program (April 2011), I fully subscribed the program’s goal of reaching out to Business people and helping Agile Product Management emerge. I demonstrated my understanding and my training qualification was extended with PSPO.

After a little migration within Capgemini I am now in the greatest position ever of working day and night in promoting, maintaining, supporting, coaching, training and facilitating Scrum; internally as well as at customers, locally (Belgium and Netherlands) and globally. And the Capgemini Academy is rolling out a training offering for private and for external audiences that combines:

  • Our Capgemini trainings: Scrum Kickstart, Scrum for Product People and Scrum for Managers;
  • The official trainings PSM and PSPO.

Our strategy connects to the vision of in presenting Scrum as a tool for Business Agility, not as an end in itself. As from Capgemini I sincerely hope to have impact but from a positive, open and adaptive attitude. Not grumpy or bitter or aggressive. Knowing that the path to Agility will remain a cobblestone path and there will be ups and downs. Keep an eye on the overall progress trend, a burnup chart of Agile values and Agility. Make the world a better place (to work in).

Why I loved going to the PSM Course

Early December 2010 I went to a Professional Scrum Master (II) course in Zürich, taught by Ken Schwaber and facilitated by Zühlke Engineering. Already being a PSM II, I went mostly to see Ken and to look to improve my own teaching skills. And it was a very enjoyable event!

Ken and the ScrumAlliance parted in 2009 leading to Ken establishing As an outsider I don’t care about the circumstances or the rumors surrounding this. I’m only concerned with the profession of Scrum, that I have now been practicing for 7 years and for which I truly believe that Agile is finally crossing the chasm in the lowlands of Belgium and The Netherlands (and other parts of our old continent of Europe).

And I can only conclude that Ken has learned his lessons by:

  • Separating course attendance from assessment/certification;
  • Incorporating community feedback;
  • Creating a development course and for Scrum Teams in general;
  • Setting up a Product Owner program with a separate assessment;
  • Upgrading the PSM course material.

For the latter I can testify that a number of topics were already treated in my CSM by Ken in 2004, but new stuff and ideas have been included far better than in recent CSM course material that I compared it to.

What I strongly like in Ken’s teaching is his holistic perspective on Scrum, like the spirit of the Scrum Guide that he co-wrote with Jeff Sutherland. His courses go well beyond the formal mechanics of Scrum. It’s much more about why Scrum works, its psychology, the positive thinking, the social aspects. And the empirical foundation of Scrum to help us not even trying to predict the unpredictable. And beyond the theory, luckily, Ken has tons of stories and cases to share with the training participants.

This PSM course has certainly inspired me in my teaching of the Scrum Trainings that I launched at Capgemini. At a considerable scale of internal participants and geographical spread. Hoping that I can open these trainings to external audiences, and maybe even as PSM Trainer…