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. 

Empiricism

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.

 and

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.

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 Scrum.org, 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 Scrum.org’s prestigious Scrum Day for Professionals series. We have limited the co-organizing companies to our Scrum.org partner-in-principle Prowareness and have complemented that with a more substantial involvement of the communities. Because, in the end, Scrum.org’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.org.

Scrum Day Europe 2014

Find all information on Evidence-Based Management at ebmgt.org.

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 Scrum.org, 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 Scrum.org 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 Scrum.org 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 Scrum.org 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.

Scrum.org 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 Scrum.org 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

Scrum.org-Logo-CirclesIn 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.