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.

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.

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.

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:

Commitment

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:

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.

Focus

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.

Openness

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.

Respect

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.

Courage

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.

The Value of the Product Backlog

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).

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

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: Framework, not methodology

1/ Scrum is not an acronym

The term ‘Scrum’ was first used by Hirotaka Takeuchi and Ikujiro Nonaka, 2 acknowledged management thinkers, in their ground-breaking 1986 paper “The New New Product Development Game“. They borrowed the name from the game of rugby to stress the importance of teams in complex product development. Their research showed that outstanding performance is achieved when teams are small and self-organizing units of people that are fed with objectives, not with tasks. Great teams require room to devise their own tactics to best head towards shared objectives. The well-known agile development method inherited its name ‘Scrum’ from this paper as it implements the same principles for developing and sustaining complex software products.

The Japanese authors of the paper also consider Scrum as the necessary core of any system that pretends to be Lean. But they never use the term ‘Lean’ because it has become synonymous to the Western interpretation and copy of the management practices of the Toyota Production System. And there can’t be Lean if the heart of it, ‘Scrum’ according to the authors, is overlooked. But in general this is the case, so the authors prefer to stress the need for the heart and soul of the system and take away the sole focus on the surrounding management practices. They therefore never talk of Lean, but always speak about Scrum.

As Scrum is no acronym, there is no reason to write “SCRUM”.

2/ 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.

3/ 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 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.

Few People Understand

Many people spend their time, full-time, on elbowing a career, improving their personal position, aiming at a promotion, planning a next strategic move, working on political strategies, making more money, ripping off people, whatever it takes.

Few people understand what motivates me. Few people understand:

• My drive to make our world a better place to live and work in;
• My apathy for titles and hierarchy;
• My respect for people as the core of my actions and being.

Few people understand that no promotion, no bonus, no pseudo-moral bribery, no threats have changed or will change these inner drives. Few people understand that no hierarchical layer keeps me from addressing issues, challenging the status-quo or experimenting with improvements.

Few people have the mental openness to understand that I care only about the content of my work, about working with people, about my autonomy (in team, time, tasks and tools, as described in Daniel Pink’s Drive). Don’t come to tell me what you want from me, or try to use me for power games or self-promotion. It only wears me out. I hate it and I start responding emotional and unexpected. Come to work with me and great results may emerge.

I rarely expose this inner drive explicitly because it’s not a pose. Maybe this one-time notice helps. Worst case you now know why we don’t get along or why you feel ignored. In the meantime I have the best work and personal life possible, the greatest career possible; by not minding my career.

A Servant King?

In 2012 one of the communities at my employer found a fun way to reward people. The community handed out virtual badges for specific achievements. The top badge collectors became kings. The kings recently fought a ‘battle’ to determine who would be the conqueror.

The kings had to present themselves to the battle audience with a little movie. My movie was co-created with a terrific colleague and member of El Porco, who I hold accountable for the poetic expressions that might indicate how I’m perceived. Better than any spoken statement could be.

By the way, I gloriously and graciously failed to win the battle.

Ways to play Scrum

In 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:

• User 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.

Writing Scrum Writings

On top of managing the agile offering of Capgemini (Dutch description here) as a Product Owner and mentoring our Scrum coaches and Scrum trainers I also give Professional Scrum trainings.

After my classes I send out a thank you to the participants in which I include some guidelines to prepare for the online assessment they get access to. I also point people to some background readings. Over time I have created a small library of blog notes I’ve written from which I can select some to refer attendants to for additional information on top of the courseware:

• The paper “ING: capturing agility at a large Dutch bank” that the CIO Channels of ING and I co-wrote. It was kindly published by Scrum.org at http://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/577/ING-Capturing-agility-via-Scrum-at-a-large-Dutch-bank
• A blog note on the paradigm shift that we need in our software development business: http://www.capgemini.com/blog/capping-it-off/2012/04/to-shift-or-not-to-shift-the-software-industry-paradigm/
• A blog note on what is/is not Scrum, and how this “ScrumAnd” mindset opens the road to continuous improvement: http://www.capgemini.com/technology-blog/2012/08/yes-we-do-scrum-and/
• A blog note on how to ‘plan’ agility: http://ullizee.wordpress.com/2012/09/30/agility-cant-be-planned/
• The questionable view of the Scrum Master as ‘impediment hunter’: http://ullizee.wordpress.com/2012/11/11/impediments-and-where-to-find-them/
• The anti-collaborative concept of fixed price bids: http://ullizee.wordpress.com/2012/10/07/fixed-price-bids-an-open-invitation-to-bribe-cajole-lie-and-cheat/
• For the Lean specialists that attend the class and who are in general quite impressed by the lean-ness of Scrum: http://ullizee.wordpress.com/2011/12/18/how-scrum-blends-the-philosophies-of-lean-and-agile/
• Assuring people that they are welcome in the warm ‘House of Scrum’: http://ullizee.wordpress.com/2011/10/22/the-house-of-scrum/
• The bottom-up thinking when the scaling of Scrum is required: http://www.capgemini.com/technology-blog/2012/05/scaling-scrum/
• The differentiation between the rules of the game of Scrum and ways to play the game: http://ullizee.wordpress.com/2013/01/17/ways-to-play-scrum/

I always pick some of following topics to add:

• A short RSA animated movie to illustrate Daniel Pink’s scientific research on what truly motivates people: http://www.youtube.com/watch?v=u6XAPnuFjJc
• The original “The New New Product Development Game” paper (1986, Takeuchi and Nonaka) that has been an important inspiration in the development of Scrum.
• Why I recommend the book “Coaching Agile Teams” by Lyssa Adkins to Scrum Masters: http://ullizee.wordpress.com/2013/01/06/take-it-to-the-team/

Fyi. have a look at the most beautiful location I have ever trained in.