The Tao of Scrum (complete)

Posted on 08. Apr, 2010 by in Agile, Coaching, Reflections, Teams

Following was inspired by the Tao Te Ching (Dao De Jing). I was preparing to teach a new Agile team and wanted a simple version of the rules of Scrum. I started with the Scrum Guide, which I distilled down into 15 basic rules and 53 sub-rules. The basic rules, in this Taoist-like format, are a kind of Ri (expert or master) version of Scrum.  This post contains the third and final installment, with all 15 rules included (go to the bottom for the third set not previously published).

The Underlying Tao

The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.

The basis of Scrum is that it is transparent:  to the people who pay for development, to management, to customers and users, to the team itself. Of course, this sounds good, but in fact people often hate it. It is hard to give up old ways, to be exposed in our comfy habits. So we don’t always take full advantage of transparency. We want transparency of some things, but not others.

Then, given that we have transparency, we are now in a position to inspect what actually happened. Did our plan work out? Did the change to greater detail in our stories actually make a difference? Were we able to get QA more involved this sprint?

Finally, when we see the results clearly, it is incumbent upon us to make changes, to adapt. If QA did not get more involved this sprint as we wished, what happened? How did we fail? What can we do differently? The questioning mind is an open mind. In the beginners mind there are many options, in the expert’s there are few.

The Tao of People

The Product Owner decides the ‘what’ of the Way.

With only one person making decisions on what to work on (and why), teams are able to get very clear and move very fast. With inspection, everyone  sees whether those ‘what’ decisions actually worked out. The Product Owner is likely to either love or hate this arrangement. If we know where we want to go–and are able to adapt quickly to feedback–it is wonderful to be the driver. On the other hand, if our success has been due to maneuvering around accountability, this will be an unhappy path with which we will likely find fault.

The Team decides the ‘how’ and ‘how much’ of the Way.

In regards to the Product Owner’s direction, the Team decides both how to accomplish the ‘what’ and how long it will take. To do otherwise will tip the scales of power unwisely, in ways that do not reflect reality accurately. Teams feel the integrity of the process when this dictum is upheld. It conveys respect and professionalism.

The Scrum Master serves the Way, and tells others when the Way has been lost.

Ultimately, the Scrum Master must serve the Way itself. For Scrum, the Way is embodied in its rules and in its essence. At times, the Scrum Master may feel like a voice in the wilderness, trying to be heard above the din of ‘deadlines and demos.’ But if she serves the Way truly, her voice will eventually be heard. If it is about his ego (or results), the Scrum Master will fail, both himself and the Team. This is hard for the new Scrum Master to learn. We have been trained that we must be responsible for the team’s results. Ultimately, attempting to do so will compromise our allegiance to the Way of Scrum.

The Tao of Events

Release Planning defines what users of the Way will find of value, and by when.

Release Planning may remind us of the old days, when management asked for dates (and commitments) that we could not give, or could not keep. It can be tempting to skip over Release Planning, especially for a new team. But having a view of where we are going gives us confidence, and helps us know when we have lost our way. Release Planning is not about dates (though everyone wants them), but about sequence and size. Release Planning might be best done during the first Sprint, after we have the chance to get our mind on straight as a team.

Sprints are the Way of the Team, and do not vary in length.

Sprints are the heartbeat of a Scrum Team. They provide the rhythm and backbone on which ritual can form, rituals that teams need as human systems. The Sprint cycle provides a beginning and an end, creating a familiar comfort against which to remember where we are, where we are going, and how we can do better the next time around. Over time, the Sprint may get shorter, but do not let it get longer.

Sprint Planning defines the Way for this week, and for next.

The Sprint Planning meeting begins the cycle. It says this is a new day, we can do anything, together. It lets the business customer tell their story and the team ask their questions. It gives the team their marching orders, and the Product Owner, hope for the immediate future. It is the project community’s central ritual, along with the Sprint Review. It should be adjusted to fit the community, whether with food, music or anything that connects people’s hearts.

The Daily Standup helps the team Adapt to the Way, for today.

The standup is the place where accountability within the team becomes real. Those embarasssed to ask for assistance will be stuck on the same task, day after day, while declaring ‘no impediments.’ Some will be vague when declaring what they will do today, unsure of themselves and of their support. For others, the standup is a celebration of how well they work together and how much they can conquer as a team. If everyone does not learn something during the standup, there is either a lack of real listening, or the team is talking only from rote. Perhaps there is a lack of trust?

The Sprint Review helps the users of the Way Inspect what has been done in two weeks time.

We come back to inspection. The Sprint Review is for the project community–as many of them as possible–to come together and see what has been done. Real feedback is essential: the good, the bad and the controversial. Senior leaders are sometimes reluctant to attend. That is a shame. This is where the ‘real’ work gets done. Perhaps they haven’t heard?

The Retrospective helps the team decide the Way forward, by Inspecting the Way that is past.

The Sprint Review is to the project community what the Retrospective is to the team: it is their inspection (and introspection) process for themselves. Did they get better this Sprint? Did they accomplish all they could as a team? Did they have fun and feel relaxed? Where is their cutting edge? And how can they get over it?

The Tao of Things

The Product Backlog is the Way, in order.

The Backlog is a garden that must be weeded and watered. Sometimes we only develop as much Product Backlog as the team will need for the next Sprint or two. This may work for a time, but we need to plant more seeds. The thinking that creates the Backlog should be allowed to run its course, or the Way will be inarticulate. A finished Backlog is an oxymoron: this is not the goal. Do plant more seeds.

Likewise, the Backlog may be relatively full, but not in order. This is like weeds in our garden. The Backlog must be nurtured each Sprint by the Product Owner, and by the Project Community.

The Sprint Backlog is the ‘How’ of the Way, for two weeks time.

The Sprint Backlog is to the team what the Product Backlog is to the project community.  It too must be nurtured every day. Do we have all the tasks? Are we keeping track of where we are? It is easy for us to get lost in our own tasks and forget the big picture, but ‘seeing from the whole’ is what makes us truly a team. If we don’t see, the Scrum Master will.

The Product Burndown shows the Way of the Product Backlog.

The Product Burndown can be tedious. Who wants to calculate all that’s been done and all there is left to do? But seeing how much value is left, and how much effort it will require, is what keeps us honest about business decisions: is this still the most valuable product to pursue?

The Sprint Burndown shows the Way of the Sprint Backlog.

The Sprint Burndown can seem annoying to update every day, even pointless, especially after 12 Sprints. But the burndown is not just for the team: it is for the stakeholders, patiently trusting that the team is making progress, silently biting their lip so as to not interfere, now they have been told they are ‘chickens.’  Try seeing what the pattern of your burndowns are over 5 Sprints. What do they tell you? How could you get better?

The Tao of Endings

The definition of Done must be agreed upon by all who follow the Way.

Deciding the rules for when we are finished — with a task, a story, the Sprint, or even the product — should be decided at the beginning, but discussed repeatedly. Were we really done with this task? Did our team think so? Did we use too much effort to finish this story? What do the tests say? Have we gotten as much value as we need, for now?

Are there greater horizons ahead?

How can we get even better?

Bookmark and Share

12 Responses to “The Tao of Scrum (complete)”

  1. Tobias MayerNo Gravatar

    11. Apr, 2010

    Michael, I like this very much. It is beautiful to read and gives another dimension with which to view Scrum. It gets to its essence.

    There is only one thing I take issue with here, in the second to last item:

    > …But the burndown is not just for the team: it is for the stakeholders
    If you are referring to a task burndown I strongly disagree, and think that is a dangerous idea. It encourages the stakeholders to peer into the sprint, and therefore start pushing when things are apparently not going well. The sprint (task) burndown should be ONLY for the team, if used at all. If you are referring to a story burndown, I take no issue. Stakeholders seeing which stories are completed, and when is useful. Please clarify.

    > now they have been told they are ‘chickens.’
    Too bad you had to introduce this term. It is unnecessary, and confusing without the back story. Any chance you can rephrase this, and help all of us move past that outdated metaphor?

  2. Roy HaleNo Gravatar

    15. Apr, 2010

    Tobias, I have to disagree that the sprint burndown should be ‘ONLY for the team’.

    I am of the opinion that the sprint burndown is just as important to the stakeholders as it is to the actual development team. if not then you have already violate the first Tao, ‘The Way is Transparent’.

    For us we feel it’s important that ANYONE should be able to see just how well, or not, the actual sprint is going. It’s the Scrum Master’s job to see to it that the stakeholders do not interfere with the sprint but they sure should be able to see how it’s going.

  3. Michi TysonNo Gravatar

    15. Apr, 2010

    Tobias – I somewhat disagree with your comment about the “chickens”. I have used this term (including the background story, as I do agree that this is essential) many times with internal and external clients and not only does it get the message of stakeholder’s boundaries within a Scrum environment across, it has also helped people to understand whether or not they are, in fact, ‘chickens’ or if it’s really their bacon on the line and they should therefore be more involved in the process than originally anticipated.

  4. Eric LaraméeNo Gravatar

    15. Apr, 2010

    Thanks for post!

    Being a fan of Chris Corrigan’s Tao of Open Space” I was obviously drawn to this perspective of Scrum

    Tobias,

    Sprint burndowns should be highly visible and for all to see, including stakeholders. I insist on having the Sprint burndown in the background during our daily Scrums and stakeholders are permitted to attend quietly. My hope is that “flat lining” burndown will encourage anybody involved to ask : Can we do anything to help? If that isn’t the automatic reaction and the room is filled with
    Scrum Hawks , which is often the case; it can help the ScrumMaster identify quickly the smell and act on it.

    As a Scrum, we need to build up the courage to be fully transparent and stakeholders need to develop “the ability to hear unwelcome news” (Esther Derby) and react appropriately. Thankfully all teams have experienced ScrumMasters to ensure that this happens 😉

    Cheers!
    Eric Laramée
    Agile Coach

  5. Michael SpaydNo Gravatar

    15. Apr, 2010

    Thanks everyone for your comments. Good discussion! I note that although Tobias is on break from expressing his opinions this week, his previously expressed ones still provoke controversy ;-). That’s why we love you, Tobias!

    Yes, I did mean the Sprint Burndown is for all to see. And, I certainly agree with Tobias’ point that it could encourage those outside the team to ‘help’ unbidden. What I teach my teams, Scrum Masters and managers is that the information within the Sprint is for the team, because they control what happens during that time. The Scrum Master as sheepdog should be nipping at the heels of those stepping over that line.

    On the other hand, it is the job of management to reflect back–from outside of the team–how the process appeared to go and the results obtained, during the Sprint Review or other appropriate time. I help managers see that this reflective, potentially challenging, role is part of their job. NOT to take back control from the team, but to coach and challenge and inspire the team to its own greatness. A team sees itself more clearly precisely by having a reflection from outside of itself. Management is well suited for that in Agile. See my presentation on What Manager’s Should be Doing for their Teams (https://docs.google.com/viewer?url=http://collectiveedgecoaching.com/wp-content/uploads/2009/08/WhatManagersShouldbeDoingforAgileTeams.pdf)

  6. Cristian George RapauzuNo Gravatar

    15. Apr, 2010

    Very inspired one-liners, almost haiku-like. Excellent.

    In order to help the Team:
    – navigate the waters of ‘how’ and ‘how long’
    – connect the Release- and Sprint-Planning
    – connect the Product- and Sprint-Backlog
    I thought a mini-guideline for the evaluation process of Stories might be useful.

    It has 3 dimensions: Value, Effort, Risk (VER) with scales from 1 to 3, under the control of 3 roles. The Client (Product Owner) marks the Value of the Story.
    The Developer (Team member) marks the Effort needed for the Story.
    The Architect (Team member with deeper knowledge of the system) marks the Risk of the Story (i.e. how disruptive to current architecture).

    The VER triplets could better inform the choice of candidate Stories to be transfered from the Product Backlog to the Sprint Backlog.

    With the caveat:
    Plans are worthless. Planning is essential. (Eisenhower)

  7. Pierre NeisNo Gravatar

    15. Apr, 2010

    Sorry Guys,

    I agree with Tobias according to the fact that “Sprint” is Team’s Job.

    Stakeholders just check out at the Sprint Review when the Sprint Work is DONE.

    Stakeholders haven’t to loose their time with (impediment?), their wishes are A GOOD PRODUCT IN TIME… nothing else.

    For the rest, great Metaphor…. I ever thought that SCRUM is some Management FENG SHUI….

    scruming yours

    Pierre

  8. Don GrayNo Gravatar

    15. Apr, 2010

    When will be poster be available for purchase? Every team room should have one.

  9. Jack MilunskyNo Gravatar

    15. Apr, 2010

    Loved this post. Very well written. Michael, I would love to be able to republish this post on my blog. I am not sure if you’d be ok with this. I would obviously give you full attribution etc. I would be love for my readers to get to see this post. Let me know.

    Thanks
    jack

  10. Marcelo CostaNo Gravatar

    16. Apr, 2010

    Very good writing. This leads us to think always in the paths we choose and not get lost in the face of obstacles we face is how Scrum Master, team member or Product Owner

  11. […] Spayd has written a brilliant distillation of Scrum, as The Tao of Scrum. It boils Scrum down to its soul and essence. (Yes Sandy Scrum does have a […]

  12. Dave NicoletteNo Gravatar

    14. Jul, 2015

    An interesting and entertaining analogy. IMO from a taoist point of view the ScrumMaster wouldn’t “tell” people things, but would (maybe) “show the way.”

    Also not crazy about locking in a two-week sprint length. IMO sprint length, and even the use of a time-boxed delivery interval, are steps on the “way” and not the destination.

Leave a Reply