Happy Scrum Year

I hope your beginning of the year 2014 was as good as mine was. I wish you a great future no matter!

Crossing from one year to another is often a time for some retrospective introspections. It is a time where we more naturally step away from the daily, monthly and quarterly rush to look back and learn in the face of the upcoming times. As a result, but even besides it, it is also a good time to reground ourselves. Obviously we should retrospect and reground more often, but let’s say that this is a good time to absolutely do it.

My life has much to do with Scrum (below picture has some 2013 highlights). Here are some simple foundational aspects of Scrum I’ve ingrained over the years. They have often helped others to keep grounded or reground. These are bare basics that may seem non-essential at first sight. They have little value when respecting them. However, they become more essential when not respecting them. Not respecting them diminishes credibility in the communities, and it damages how Scrum is seen outside of the communities.

  • Stop calling Scrum a ‘methodology’. It is not. It is a framework. Note that we have even overcome the perception of Scrum as a method for ‘Agile project management’, and the Scrum Master as an ‘Agile project manager’. Focus on the software product, continuous discovery and value.
  • Stop writing Scrum in capitals (“SCRUM”). Scrum is not an acronym, nor an abbreviation. Write “Scrum”.
  • Cherish that Scrum is incomplete. It is by design. This is not a restriction nor a dysfunction. It takes away the illusive and deceptive certainty that from the method itself every possible answer, for every possible situation, at any possible time can be deduced. It applies to any method but Scrum makes it explicit. Use Scrum as a foundation, and apply the ScrumAnd thinking to address your specific problems and situation.

Happy Scrum Year (2014)

Illustrations of ScrumAnd

Although Scrum has an acknowledged body of knowledge, the Scrum Guide, it is -by design- incomplete. Scrum is a framework, not a methodology. With Scrum, an empirical foundation is created from which the details and specifics of the actual working processes emerge. And while the actual working processes keep evolving, the foundation of Scrum provides stability.

Scrum needs the continuous selection, application and revision of good practices, strategies and tactics to be really effective. The rules in themselves provide foundational guidance. The effective benefits an organization gets from Scrum largely depend on how the game is played. Ultimately the benefits gained from Scrum will vary with the implementation, usage and application of Scrum; from roles, rules, players, and principles to techniques, practices, strategies and tactics.

Doing Scrum, and doing it properly, is only the beginning. Yes, you do Scrum if you have the formal elements in place. And from that much more beauty comes within reach. We refer to this idea as ScrumAnd.

Yes, We Do Scrum. And

There is a ScrumAnd for a myriad of elements included in or attached to the use of the Scrum framework. I will illustrate the ScrumAnd potential to augment the fun, energy, and benefits from Scrum upon 3 elements only:

1. The Product Owner role

Yes, you do Scrum if you have a Product Owner. And you will do even better depending on how the role is fulfilled:

Yes, We Have A Product Owner. And

Scrum is at first often implemented as the new IT-process, or is started within the IT-departments exclusively. So, a business analyst is put in the role. In organizations suffering from the traditional Business-IT dichotomy, it is often much later that business comes into play; forcing themselves in or being invited to do so.

  • A (business) Analyst in the role has limited benefits. But development organizations feel like securing control over the process with an analyst as Product Owner; just because it is an IT-person (‘Can’t trust business people!’). However, for many decisions the analyst doesn’t have the answer, needs to revert to product management, look at the project manager, wait for an external decision, get an upfront approval from a steering committee. Every time the Development Team is halted, must wait, pick up other work, restart previous work, park work for a longer time. No flow, no value.
  • A proxy for the business, like an account manager or other gap bridging alternatives, is slightly better. Control remains with IT (‘Still can’t trust business people!’) but IT puts a person in the role who is closer to the business, who is more connected to the business. It creates less delays, less waiting time, less hick-ups; although many of those remain.
  • Often the business gets a smell of the role and sees the fun and advantage of it, or the organization just opens up to broader collaboration. A person is sent in from a business or product management department to fulfill the role. It is another improvement. There is more direct availability of functional knowledge and stakeholder expectations. Yet, still much waiting time for decisions by the real authorities, as the business representative often has limited autonomy in his representation of product management aspects to the development organization.
  • It works better if the person is not only from business, but also has the trust and the mandate to take decisions (on the spot). A mandate is a signal that the role is taken more seriously. Often the person in the role is allowed to spend more time on it. Less hick-ups, less context and task switching, largely improved flow. The Development Team can focus more, and get things done.
  • It is great if the Product Owner is a mini-CEO over the product, a real owner of the product (what’s in a role’s name, right?), a business person with full (functional and budgetary) responsibility over the product and knowledge over all product management aspects (marketing, competition, users, legal, finance). The person’s professional life is dedicated to the well-being of the product. They don’t come much better than this.

2. Releasable software

Yes, you do Scrum if you have a definition of Done. And you will do even better when it reflects ‘releasable’ and all work for it can be done within a Sprint (not post-Sprint):

Yes, We Have A Definition Of Done. And

Scrum has no exact prescriptions for software development practices. However, the empiricism of Scrum thrives on transparency. A part of transparency lies in common standards and agreements, to drive inspection and adaptation. Engineering standards are a crucial part of that. Engineering standards guide the definition of Done, give focus to a team in getting stuff done, help a team in forecasting Product Backlog for a Sprint, define quality, create accountability.

  • Development (here as synonymous to ‘programming’) is quite essential in the wonderful world of software development. Without it, no result, right? And although the importance of it is often even underrated (think of the separation of design from development in separate, upfront phases), programming in itself is hardly enough. Although code aspects like clear code, self-explanatory code, naming conventions, refactoring are very important, it is only the start. But for sure, without development (‘coding’), no progress as there can’t be any working software, the primary measure of progress.
  • Code requires testing. And if all testing is to be done within a Sprint, testing skills are required in the Development Team and testing becomes part of the development activities. Testing is minimally needed at a technical unit and at a functional level. It gets even better if this part of development can be done first, can be automated as much as possible and is performed progressively within the Sprint, not just toward the end of the Sprint.
  • The releasability of an Increment, produced by the end of a Sprint, takes a giant leap if all integration, regression testing and alike work is done within the Sprint, and within the Sprint across multiple teams working on the same product or dependent products. It does help additionally if also this work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint.
  • Teams can do better if they not only have the skills, access and mandate to perform QA work in the Sprint, but are also facilitated by organizational guidelines for quality, designs and architecture. No rework arising from QA on earlier Increments disrupts a current Sprint, or must be added to the Product Backlog. It does help additionally if any QA work can be automated and is done progressively in the Sprint, if quality is built in into the product and not just verified toward the end of the Sprint.
  • Even when doing Scrum, many organizations foresee additional stabilization time to prepare an Increment or a set of Increments for an actual release. Imagine the gain if this work can be done within the Sprint. Every 2-3 weeks a truly potentially shippable Increment of software is available, that can be brought to the market without additional costs or work. A good time to start thinking about continuous delivery.

3. A Collaborative Team

Yes, you do Scrum if you have a Scrum Team with a Development Team, a Product Owner, and a Scrum Master. And you will do even better when the team can improve its relationships and collaboration, often by remaining stable:

Yes, We Are A Team. And

Self-organized team work is the corner stone of Scrum. Teams however cannot be built or constructed like a mechanical object. With support, cherishing and nurturing, a collaborative team might gradually emerge.

  • A team gets formed by bringing a group of people together, preferably -but not always- in a shared workspace. Most of them are in observing mode, are keeping some distance. Formal arrangements and agreements get made, possibly including team agreements, engineering standards, a definition of Done, team values, meeting timings. And the team formally starts following them. Gradually people start expressing deeper thoughts, ideas and concerns.
  • A team goes through some storming as the team members get to know each other better and start expressing options and ideas that don’t match exactly. They sort the differences out. At first they might take it personally only to find out later that they are not used to the others’ gestures, tone of voice and facial expressions. They find out and they build a sense of trust.
  • The group of people jells better and better. The whole becomes equal to the sum of the parts. They become co-operative, they better align their individual work with the work of the others. They adjust their individual expectations to their team peers. They find a productive way to deal with conflicting ideas.
  • The team is really starting to know each other, even share more personal backgrounds. They have grown confidence in understanding each others’ remarks, stop taking comments personally. They stop looking for blame and stop covering up. A solution becomes the goal. As there is trust, and openness and honesty arising from it, they develop shared goals and are committed to these shared goals and objectives. Individual benefits are being sacrificed for the good of the whole.
  • The team has become a smooth, collaborative unit. Everyone’s focus is on the whole. The team members have passionate debates, engage on opposing ideas, look for the best possible outcomes and get their satisfaction from being part of the group. What used to take them hours and hours to sort out now only takes them a smile and a wink.

Organizations tend to overlook the scaling potential in the way Scrum is being played. Take advantage of these options first, enjoy the cumulative effect of multiple ScrumAnds and avoid the additional complexity that arises from volume-oriented scaling like adding people, adding teams, adding roles, adding phases.

Measuring Success, Measuring Value

The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable. Yet, I do believe it is imperative to think in terms of value in software development and therefore overcome some fluffiness attached to ‘value’. If we don’t find actionable ways to deal with ‘value’ it might remain meaningless; another buzz word, another way of getting people to think it’s time to move on to the next hype. It is not only difficult to quantify value, it is not even necessary, maybe even undesirable. It is better to measure whether we are delivering value (effectively).

What we thought defined success

For many years we were tricked into believing that software development can be considered a success if we meet 3 criteria: deliver (1) all promised requirements (2) within the planned time (3) for the allocated budget. It is reflected in the famous iron triangle of software development.Iron Triangle of Software Projects

That in turn tricked us into believing that, in order to be successful, we had to exhaustively analyze, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual programming can be done. The underlying motivation is to secure the first element of what we were told defines success, the ‘requirements’.

This beforehand gathered information then becomes the input to careful and exhaustive calculations for the delivery part, often with the addition of some ‘contingency’. The underlying motivation is to set and fix the other two elements that we were told make out success, time and budget.

The result is poured into a plan, often complemented by risk mitigation strategies and other exception procedures. When this plan and all its components and clauses are approved and signed off, implementation can -finally- start. And then, obviously, it is just a matter of following the plan to be successful. Deviations from the plan, seemingly happening sometimes, are unlikely to cause any real problems, because it’s what ‘change request’ instances are for (meetings, documents, approvals, and sign offs).

Unfortunately, this was (and at many places still is) believed to be the only way we can ensure the ‘success’ of software development.

Yet, things aren’t that easy. The installments of the mentioned extra safety nets are already an indication that, despite our firmness, this approach isn’t really giving us the certainty it claims to have. And despite the safety nets, the detailed preparations and the seemingly perfect plans, many projects are plainly cancelled (29% according to the Chaos Report by the Standish Group of 2011) or in the end still fail in meeting the widely accepted success criteria of scope+time+budget (57%).

Some however are actually successful in delivering according to the three predictions (14%). But then, success doesn’t take into account that often quality was lowered to unacceptable levels in order to live up to the success criteria; reason why it’s good to add that as a fourth variable to the iron triangle (see figure). Success doesn’t take into account that the elapsed time might be according to plan, but may business-wise be extremely slow. Note that it is not unusual for projects to deliver software no sooner than 12-24 months after the start! Success doesn’t take into account that by the time the software actually becomes available for use, nobody really sees much ‘value’ in the features anymore; at all rendering them useless or in the functional way the features are implemented. More innovative ideas for them have emerged, or improved technological ways to implement them are discovered. It connects to the finding that 64% of features, produced in this way, are rarely or never used.

The three factors they told us defined ‘success’, fail in doing exactly that. And even if they are met, they still only reflect how successful the ‘delivery’ of the software to the market is, not how the software is being received or appreciated on the market place, let alone that the approach helps us addressing changes or new requests from the market place. The three factors fail in showing how valuable the software is; it only says that a version of software got out the door at certain predicted conditions.

What we say determines success

Agile overcomes the fallacy of traditional, upfront predictions and descriptions with collaboration, communication, incremental progress and continuous improvement. All risks taken are limited in time through time-boxed iterations. Time-boxing allows adaptation and adjustment within the process.

Agile Value Delivery (general)

The agile movement stresses the importance of active business involvement as part of cross-functional development work. The agile movement stresses the need for frequent releases to the market place to learn what actually is appreciated. There is no better risk mitigation than regular feedback from actual users.

Scrum, as leading framework for agile software development, is designed upon the foundation that software development is too complex for a predictive approach. Scrum implements empiricism in software development, thriving on frequent inspections to decide on the best possible adaptations. Inspections however are pointless if the inspected information is not fully known, opaque instead of transparent, and if the inspection is not done against known and agreed standards and definitions.

The target of the adaptations is not only the software being produced, it is also about the tools, the engineering practices, the relationships, the process and the three elements they told us define success, i.e. budget, scope and time. Scrum does not care about the abused notion of ‘project’. The concept of ‘project’ generally only serves the idea that success is possible if software is delivered on time, within budget and has all the predicted features. Scrum focuses on the software product (having a role and an artefact for its owner and its backlog) and incremental sustenance of the product.

The foundational belief to this is that the success of software development is defined by the capability to satisfy and impress the consumers of the features, at a reasonable price, at a cost that has an effective return, with creation happening in a way that is sustainable for all people in the ecosystem of the product.

Yes, we can… measure

The success of an organization, in terms of survival, prosperity and leadership, increasingly depends on their ‘agility’, i.e. their overall capability to deliver value in a context of constant change, evolution, innovation, improvement and re-invention.

The difficulty in establishing the value of software or software requirements is that it depends on context, time, technology, market, business domain. It also cannot be reduced to one parameter only. Predicting value doesn’t make much sense either, since it can only be validated by the market place.

But if value defines success, how can we then measure whether we are successful?

Scrum.org has developed the Agility Path framework to help organisations increase their agility and move toward a value-driven existence.

Agility Path Circle

Agility Path focuses not on the illusive goal of calculating and predicting value or similar magic. With Agility Path the outcome of an organization’s work is measured with metrics to help them think about the way that outcome is achieved. Organizations get a clear indication on whether they are delivering value or not. If from the metrics it seems they are not, they have many areas and domains to inspect further, and do adaptations by installing, removing or improving practices, tools and processes. It is how the Scrum framework is used to manage the change process, the transformation of an organisation required to increase their agility.

The metrics provide the transparency needed to identify the areas where adaptation has the most impact. Think in terms of business metrics like employee satisfaction and customer satisfaction, revenues, investment in agile, etc. Think in terms of delivery capability metrics like cycle time, release frequency, defects, etc.

All metrics are consolidated into an overall Agility Index for the organization. This Agility Index is an indication of how effective the organization is in delivering value. One Agility Index is bound to time, place and context. The exact figure is of no importance. The evolution is of importance. The underlying set of metrics is of importance. The insights gained from the metrics, as a source of improvement, are of importance.

No magic, just hard work

There is no magical formula to calculate value, and even when trying to calculate value to steer development priorities, it is a prediction, an assumption that remains to be validated (or contradicted) when you actually go to market. You can never be sure.

The best we can do is to capture the results of our actions with metrics, and do those measurements regularly. We detect trends and patterns (and prefer that over a naked, singular figure). We relate that back to how we work, change how we work, and measure the change in outcome of that assumed improvement. We do that endlessly and relentlessly. We continuously improve by learning and adapting. We get the most out of what we do.

This flexibility primarily helps organizations respond better and faster to change, it implements openness to change over ignoring or blocking it. Once the thinking gets ingrained and new ways of working are installed, organisations discover that there may be different options to respond, thereby embracing change as a source of information. And, finally, organisations start innovating, be ahead and cause change (for the others to follow). Thus an agile approach harnesses change for the customer’s competitive advantage, and the organization’s agility.

The Potential of Agility

A smart travel companion to Scrum

Scrum is not a goal in itself, Scrum is a mean. Scrum is a path that a person, a team, an organization takes toward increased competitiveness, higher responsiveness, more learning, more creativity, optimistic opportunism, a sustainable way of working, restored respect for people. Scrum is a journey toward increased… agility.

I have written a book about Scrum, published on 4 November 2013.

Scrum - A Pocket Guide (A Smart Travel Companion)As Scrum is designed to help people, organizations and teams embark on a journey, my book is a smart travel companion for that journey. My book is a pocket guide that can help you prepare, take off, and get going. And while on the road you can always have a quick peek again to find your way or re-orient.

My book is completely focused on Scrum. It was an explicit choice to stick to the topic, Scrum. And to be essential about that. As David Starr, Agile craftsman at Microsoft, said upon reviewing an early version, it is “without a drop of hyperbole“. Ken Schwaber, my fellow-traveller at Scrum.org and co-creator of Scrum, says it is plainly the best description of Scrum currently available. Ken has also written the foreword, summarized as “An outstanding accomplishment that simmers with intelligence.

The book has 4 chapters:

  1. The Agile paradigm. This chapter adds background and perspective to the movement that started with the “Manifesto for Agile Software Development.”
  2. Scrum. This chapter describes the roots of Scrum, the basic rules, roles and principles of the game, and the values underpinning the Scrum framework.
  3. Tactics for a purpose. This chapter introduces some common ways to play the game of Scrum. They are presented as tactics that are not formally prescriptions of the Scrum framework, not part of the rules of Scrum.
  4. The future state of Scrum. This chapter holds a look into the future and some evolutions I expect to happen.

Other appreciated reviewers were Ralph Jocham, Agile professional and Professional Scrum trainer, and Patricia Kong, director of partners at Scrum.org. Ralph says this is the book he will advise his students, coachees and organizations to read in order to learn the essential Scrum. Patricia says she would have loved to have this book when she entered the world of Scrum. Because she didn’t find one at the time.

The book, “Scrum – A Pocket Guide (A Smart Travel Companion)” will be published by Van Haren. My gratitude goes out to their team that has made this possible!

Pre-order your copy at Amazon (UK) or at the publisher’s webshop.

Scrum Unpuzzled

Scrum seems to puzzle some people. Oddly enough most of them are puzzled by the simplicity of Scrum, yet find it difficult to implement all elements of Scrum. There is some weird logic in play saying that it can’t be that simple, so elements of Scrum are replaced with much more and preferably highly complicated structures, procedures and processes.

Scrum has 3 roles, 3 artefacts and 5 events. It is enough to empirically solve the complex puzzle of software development, but all are required to cover all accountabilities in software development. Complete simplicity is the key. It doesn’t make it easier to play the game, but it does help to focus on the problem, and not on the difficulties that the structures themselves cause.

Following jigsaw representation of the Scrum framework (1) shows all elements that formally make out Scrum, and (2) it helps seeing that Scrum isn’t complete when you don’t have all the pieces in place:

Jigsaw Scrum

I hope it helps unpuzzle your mind over Scrum, a little bit.

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.

There’s value in the Scrum Values

Scrum is not a methodology. Scrum is a process, but of a non-repeatable kind. Scrum is a framework of rules, roles and principles. The framework helps people and organizations discover what works best for them. Their real process emerges, and is specific and fitting to their time and context. Scrum can wrap existing product development practices or render them superfluous. The benefits of Scrum are greater when complemented by improved or revised engineering, product management, people and organizational practices. The prescriptions of Scrum have been limited to the essence. Every element of Scrum has a goal. Changing the core design of Scrum, leaving out elements, not playing the game by its base rules, covers up problems and limits the benefit of Scrum and any additions on Scrum, up to the level of making it utterly useless.

Less known than the process of Scrum and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based: Commitment – Focus – Openness – Respect – Courage. These values relate to the ethics of Scrum, thereby -from a social point of view- turning Scrum into a value system.

Scrum Values

Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.

I have found it very useful to bring these more out in the open, as a way to assess the desirability our actions and activities. It’s even a great help in thinking about applying the Scrum framework itself. It is possible to do Scrum as if it was a methodology; organize the meetings, direct all players on every possible detail for every possible action within the framework. But is the framework then being used for what it’s designed for? Won’t it leave the individual, the team and the organization with limited improvements?

A good illustration is how I’ve observed some teams doing their Daily Scrum. Everybody answers the 3 questions (Done? Planned? Impediments?), in a slightly spontaneous way or -worst case- when asked for by a Scrum Master-pretend. But does the team use the meeting to share information, to collaborate in re-planning their work for that day, making sure they don’t get out of line with one another for more than 24 hours, to get the most out of the Sprint, in moving forward to the Sprint goal? Or do they talk to the board instead of to each other? Do they only use the meeting to make sure that the board holds all their micro-tasks so their work is logged?

Here’s some detailed view on the values, and how they can guide our actions and behavior in a Scrum context:


There is a widely spread misinterpretation of the word commitment in a Scrum context. This originates mainly from the past expectation of Scrum for teams to ‘commit’ to the Sprint Goal and the selected Product Backlog items. Upon the old, industrial thinking (that ruled software development for too many years) this was wrongly turned into the expectation that all scope would be delivered, no matter. ‘Commitment’ was wrongly turned into a hard-coded contract although it was always intended as an indication that the team would do the maximum possible effort in the Sprint and be completely transparent about progress. And in the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.

And the definition of the word, according to Oxford Dictionaries, describes exactly how it was originally intended in Scrum:

Definition of Commitment

So, commitment is about dedication and applies to the actions, the effort, not the final result.

Yet, in the Scrum Guide we replaced commitment as a result of the Sprint Planning with forecast. Because of the relationship with scope it helps getting explicitly rid of the wrong interpretation. And fortunately ‘forecast’ greatly aligns with the empirical nature of Scrum too.

Still, commitment is and remains a core value of Scrum.

We commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best we can, every day again. Commit to the Sprint Goal. Commit to be professional. Commit to self-organize. Commit to excellence. Commit to the agile principles. Commit to create working software. Commit to look for improvements. Commit to the Definition of Done. Commit to the Scrum framework. Commit to focus on Value. Commit to finish work. Commit to inspect & adapt. Commit to transparency. Commit to challenge the status-quo.


An iterative-incremental approach like Scrum and the time-boxing of Scrum allow us to focus. We focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important. We focus on what we know now and YAGNI (You Ain’t Gonna Need It) helps retaining that focus. We focus on what’s most nearby in time as the future is highly uncertain and we want to learn from the present to gain experience for future work. We focus on the work to get things done. We focus on the simplest thing that might possibly work.


The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations. We are open about our work, our progress, our learning and our problems. But we are also open for people, and working with people; acknowledging people to be people, and not resources, robots or replaceable pieces of machinery as software development -after all- is still the work of humans. We are open to collaborate across disciplines and skills. We are open to collaborate with stakeholders and the wider environment. Open in sharing feedback and learn from one another. Open for change as the organization and the world it operates in change unpredictably, unexpectedly and constantly.


We show respect for people, their experience and their personal background. We respect diversity (it makes us stronger). We respect different opinions (we might learn from it). We show respect for our sponsors by not building features that nobody will use. We show respect by not wasting money on things that are not valuable or might never being implemented or used. We show respect for users by fixing their problems. We respect the Scrum framework. We respect our wider environment by not behaving as an isolated island in the world. We respect each other’s skills, expertise and insights. We respect the accountabilities of the Scrum roles.


We show courage in not building stuff that nobody wants. Courage in admitting requirements will never be perfect and that no plan can capture reality and complexity. Courage to consider change as a source of inspiration and innovation. Courage to not deliver undone software. Courage in sharing all possible information (transparency) 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 promote Scrum and empiricism to deal with complexity. Courage to let go of the feint certainties of the past. We show courage to support the Scrum Values.

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

The Value of the Product Backlog

Grafx - Scrum Gameboard (non-branded)Scrum is a light-weight framework with a minimal set of rules. The rules help people to empirically make the most out of every single day of creating software products. Next to 3 roles and 5 events, Scrum requires no more than 3 artefacts:

  • Product Backlog
  • Sprint Backlog
  • Increment (Potentially Shippable -)

Product Backlog holds desirements

It is often said that the Product Backlog must capture all requirements. However, the Product Backlog is not a replacement for the old requirements list. This would limit it to a new name for an old habit. The value of the Product Backlog lies not in precision, in detail or in perfection, like the requirements lists pretended.

The Product Backlog is an ordered list of ideas, features and options to bring an envisioned software product to life or sustain and grow it. The list may include fixes, maintenance work, architectural work, or requirements for security, scalability, stability and performance. Each item on the Product Backlog seems at some point in time valuable for a customer. Every item on the Product Backlog holds just enough detail to make clear what it represents, but the item is also intentionally incomplete to invoke additional and explicit conversation over it. Even the definition of ‘just enough’ varies over time; items on the Product Backlog that are far away in time (ordered low) need even less detail than items that are nearby in time (ordered high).

Gradual Product Backlog Refinement

I like the term ‘desirement’ for a Product Backlog item. The level of description and detail of the item lies somewhere between what used to be a desire and what used to be a requirement; where a ‘desire’ is too fuzzy to work on and a requirement is over-specified and over-detailed. And over-specification impedes an optimal use of technology, blocks capitalizing on synergies between different functions and is a waste of money in situations of even minimal turbulence or change.

As life progresses and the earth keeps turning, Product Backlog in Scrum gets refined, adjusted and updated. The list is continuously sorted and re-sorted by the Product Owner, who thereby looks to balance the needs of all stakeholders. And by continuously keeping to ‘just enough’ descriptions and designs of the work, i.e. leaving out unnecessary details, no excessive money and time is wasted when the item in the end doesn’t get created or is implemented in a different fashion.

Product Backlog is all the plan you need

Desirements move upon their ordering from Product Backlog via Sprint Backlog into Increments of working software. To know their cost, each is assigned an idea of the effort to get it done. The cost is generally expressed as the relative size of the item. Based upon the empirical past that showed how much work on average could be transformed into a working Increment during a Sprint, an expectation can be created on when an item on the Product Backlog might become available in the evolving product. It gives predictability, yet not transgressing into predictions given that any such expectation is constrained by today’s knowledge and circumstances.

  • In a traditional plan all requirements are gathered, listed, described, analyzed, estimated and decomposed upfront. All tasks for all requirements are elaborated, sequenced and resource-wise assigned. This way the total time is determined it will take to build the plan, where ‘follow the plan’ determines the success. Dependencies are handled via the detailed tasks, their sequence and their mutual impact.
  • In the ‘just enough’ approach of Scrum however, there is no need to plan all tasks for all ‘requirements’ upfront. Desirements are gradually discovered and refined, and they are only converted into development work when included in a forecast for a particular Sprint. The forecast is based upon the relative size indication and the past progress.

Product Backlog is all the plan you need, its desirements hold all the information needed for predictability about scope and time (if that’s what you need).

There is value in value

Priorities in traditional approaches are, besides ease of work and loudmouths, mostly based upon effort and risk. This is a focus on the internal process.

An important principle of agile however is “to satisfy the customer through early and continuous delivery of valuable software.” While the ordering of Product Backlog items happens upon a complex combination of factors like dependencies, priority, cohesion and consistency, most interesting is the required addition of a notion of (Business) Value. Without it, a Product Owner has no idea on how much value a feature, an idea or a feature set presumably brings to the customer whom he/she represents to the Scrum Team. The value can be indirect, in it that not picking up a Product Backlog item might undercut the value of the system or even the organization, or produce negative value.

The notion of (Business) Value also helps Product Owners and their stakeholders move away from the (false idea of) perfection of a total product that must be completely built before releasing. Focus shifts to a minimal marketable product release, the minimal work it takes to bring as much value as possible as soon as possible to the marketplace. Techniques like leveling up can be used to group Product Backlog items into cohesive feature sets.

The value of the Product Backlog

Above all, the value of the Product Backlog lies in transparency, in making clear what work needs to be done in order to create a minimally viable and valuable product (or product Increment). The Product Backlog brings out in the open all work, development, compliances, and constraints that the team has to deal with to create releasable software.

However, too often (and especially in traditional software development environments) the sequence of implementation is based upon priorities like MoSCoW, thus leading to opaque, large clusters of requirements, loss of focus and heavy releases. Therefore, to build valuable stuff, there is value in defining, considering and adding value to Product Backlog items. A Product Backlog item needs the right attributes to be ordered, more than just prioritized.

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