Tobias Fors

Category: Scrum

  • Rolling Out Scrum – How Hard Can It Be?

    Rolling Out Scrum – How Hard Can It Be?

    The belief that an idea like Scrum can be easily and predictably rolled out in an organization is still wide spread. It’s a tempting fantasy and a potent recipe for problems. Scrum is not about installing best practices – it is about activating curiosity, using all of the brains we do have, and giving experience and reflection some room to work their magic.

    – ”This shouldn’t be too hard”, said more than one of my prospective clients. You’ve probably heard it too. After all, how hard can it be to ”roll out Scrum”? Isn’t it just about having regular planning sessions, a backlog, and maybe a retrospective every now and then?

    Well, to begin with, Scrum is much more than meets the eye. Beyond the seemingly simple practices hide lots of challenges. Take the idea of having a single prioritized backlog. Sounds like common sense, right? Now imagine succeeding with this when you have five different managers who all want to have their stuff done first.

    So, before you proudly proclaim that you’re rolling out Scrum across the organization, my advice would be to think of Scrum not just as a way of working, but as a idea virus. Embedded in the practices of Scrum are values of openness, partnership, mastery, service to others, self organization, and much more. Once released into the open, these ideas will affect your organization.

    In a way, starting with Scrum is more like starting up the engine of your car. You still have to decide where to go, and how to get there. Then you have to keep driving and navigating, constantly staying aware of what is happening around you and in you. And you absolutely can not fall asleep at the wheel. Or to be more precise, you can, but since you don’t want to crash and die, you really shouldn’t.

    If the people in your organization are secretly longing for the values hiding behind the Scrum practices, those ideas will start to take hold. When this happens, changes start to foment in more places than you might have first imagined. What started out looking like just another development process for the software people turns out to affect everyone from CEO to coder. Better to be prepared for this than be caught be surprise.

    This is an excerpt from a book I’m very slowly working on, called Pitfalls of Scrum. In it, I hope to capture some of the common misunderstandings and mistakes I’ve seen in organizations aiming to use Scrum. Maybe even some practical advice. If it sounds interesting, take a look and sign up for notifications on the book’s Leanpub page.

  • Copy-Paste Management

    Developers sometimes engage in copy-paste development. If you’ve never written code, this is when a developer copies, pastes and possibly slightly modifies some existing code – instead of following the cleaner practice of reusing the code by (for example) turning it into a single function that can be called from multiple places.

    Copying and pasting is very seductive. Developers know that it’s not a good long term solution, but in the short term it’s just so quick. It worked there, so it should work here.

    Not just developers engage in copying and pasting. Managers and change artists do it too, and in a way, the behavior is a part of Scrum, as it is with any other packaged approach. What does copy-and-paste management look like? It looks like people trying to imitate what worked at another company, at another time, with different people – in the hope that it will work here too.

    You can suspect that you have a case of copy-paste management on your hands the moment you hear someone in your organization say: “We should use Scrum”. You will know you have a case of copy-paste-management if you discover that no one seems able to give a reasonable explanation as to why you should use Scrum.

    This text is short part of chapter 1 – “No Purpose Beyond Scrum” – in my upcoming book “Pitfalls of Scrum”. If you want to receive an email when it’s done, use this small form.

  • Prioritizing Effectively as a Team

    Prioritizing Effectively as a Team

    My new article “Prioritizing Effectively as a Team” is up on AgileConnection.com. The article starts out like this:

    “A common reaction to the product owner role is to see it as too big for a single person. If the idea were that one person should do everything from guiding the vision to writing user stories, I would agree. But that’s not how I see the role; I see it as one component in getting to effective teamwork.”

    You can read the full article on Agileconnection.com (no registration needed).

  • The Worst Daily Scrum Ever

    The Worst Daily Scrum Ever

    I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.

    Visiting a team in an organization I worked with, I got to see one particular scrum master run a daily scrum – into the ground. This is the story of how he did that – but it’s also the story of how the team miraculously survived this train crash of a meeting.

    Every morning, the team would gather around a large whiteboard, where the scope for the sprint and the relevant tasks were posted in the form of a bunch of sticky notes. The meeting would not begin until the scrum master, literally, pointed at a person, and asked:

    – “What have you been doing since yesterday?” Upon hearing this, the indicated person would give a very brief account about what tasks had been worked on.

    Then, the scrum master proceeded by asking:

    – “What will you be doing today?” Again, a short answer, which seemed mostly directed at satisfying the need to say something in response to this direct question.

    The third question asked by the scrum master was:

    – “Do you have any impediments?” I noticed that the answer to this was always no, for all members of the team. I knew this answer couldn’t be true, because this was a team that struggled mightily every single day.

    When I thought it couldn’t possibly become any worse, the scrum master fired off one last and revealing question:

    – “Do you have any hours to reduce”

    At first, I was surprised by this very direct way of trying to make the burndown point downwards, but it dawned on me that it was perfectly congruent with the scrum master’s unspoken goal: to preserve the illusion of control. The answer to this fourth question would go along these lines:

    – “Hours to reduce? No, not really. But, I guess I have been working on this task a bit, so let’s see. Yesterday, the estimate of remaining time was 16 hours. I guess it’s about 14 hours left now. No, 13 and a half.” Hearing this, the scrum master nodded and smiled, and noted the change in his notebook.

    Directed by the scrum master, the team continued in this fashion in a round-robin style. Whenever “some hours were reduced”, the scrum master would nod approvingly and take some notes.

    I could hear no requests, and no offerings of help. No really valuable information seemed to be surfaced. Energy seemed to be at a rock bottom low.

    Then something interesting happened.

    The scrum master declared that the meeting was over, and turned his back to the team to work on his notes from the meeting. Because his back was now turned to the team, he never really witnessed what happened next.

    With the official part of the meeting over, the team suddenly seemed to come alive. They suddenly huddled together and started a lively exchange about their plans for the day. One person would suggest a course of action, and someone else would fill in with some additional information. Someone asked a question, and others jumped in to answer it.

    With the directive scrum master out of the game, the team took the reins and did what needed to be done to lay the groundwork for working together during the day. They performed an effective daily scrum. Energy was high, information flowed, and when needs had been met the meeting was over.

    This real scrum went on for just a few minutes, with me watching in amazement. The scrum master never saw what happened. I know, because I asked him afterwards:

    – “Did you see what happened after you ended the meeting”?
    – “No.”
    – “The team came together and sorted out the day.”
    – “OK.”
    – “Do you think you need to change the way you run the meeting?”
    – “No. It works for me.”

    How’s your daily scrum? Is it working for you? How about for the rest of the team?

    If you liked this article, you may also like

  • What Is an Advanced Scrum Master?

    Being a scrum master is more than just reminding a team to perform certain ceremonies, it’s about growing the best possible workplace.

    To begin with, let’s clarify this whole thing about the “scrum master”. It’s the name of a role. It’s a relatively new and pretty ridiculous name by intent, because a change was needed in how we lead development work.

    Every now and then we shake things up by inventing new names. Just remember that behind the term “scrum master” is the timeless idea of the servant leader. Someone who is there not to exert power over others, but to give power to others. To empower them.

    I don’t know how long the term scrum master will hang around. I do know that I want what it represents to stick for the long run. For now, I’ll allow myself the use of the possibly even sillier expression “advanced scrum master”, but bear with me, at least for the length of this post.

    After having served as the scrum master for a team some years ago, a newly hired person was assigned to pick up the task after I moved on. We talked often during the transition period, but I really only remember one of those conversations.

    We were sitting comfortably and discussing the way we were working, when my new colleague asked me something that surprised me. He said:

    “Tobias – I don’t understand how this scrum master thing can possibly be a full time job. I can see how I need to invite people to the meetings, and work a bit with the product owner – but that will hardly take upp all my time. What am I supposed to be doing?”

    I was a bit stunned, because that thought had never struck me. From my perspective, the list of things you can choose to work on as a scrum master is endless. After all – how many teams have you met that were as productive, creative, and happy as they could possibly be? There’s always one more thing to address (including pacing the rate of change).

    What I’m saying is this: the scrum master role is as challenging and rewarding as you make it. You can definitely improve your ability to create positive results by gaining deeper skill and insight. Here are some things that I can think of that I would expect from a more advanced scrum master. I’m sure you could add many more to my list:

    • Mindfully asking powerful questions to assist learning
    • Helping the team find the time for learning
    • Supporting the team in increasing its skill
    • Working with the team to grow clear and simple processes and agreements that truly help
    • Looking far outside the scrum and agile canon to find new things to learn and try in fields such as agile engineering practices, psychology, organizations, testing, change, teams, learning, culture, consulting, systems, problem solving, and design (to name just a few)
    • Spending a whole lot of time working with the people in the organization surrounding the team, since that’s often the most powerful force shaping the team’s behavior and results
    • Gradually helping more parts of the organization to understand and make use of the scrum mindset of cross-functional and transparent work
    • Helping managers understand how to serve better
    • Constantly working on developing him- or herself, realizing that the most powerful tool you have at your disposal is yourself

    Last but not least, I would expect to see the advanced scrum master working on helping others learn how to do all of the above, so that the power to lead can spread. After all, we can’t let the organization’s future depend solely on somebody called a “scrum master”, can we now?

    How would you know that you had just seen an “advanced scrum master” in action? What would that person be doing, and how would it make things different?

    If you liked this article, you may also like

  • Check-in in a Circle

    When I kick off a class or workshop, I want participants to engage as soon as possible after entering the room. I do work through some practical bits first, but after that I quickly hand things over to participants.

    For a long time, I’ve been using an opening exercise I learned from Ken Schwaber. In it, I ask participants to sort themselves along a line in the room, according to different criteria.

    First, I ask the group to sort itself according to how effective and efficient their current project is (in Swedish, a single word has the connotation of both “effective” and “efficient”). Once sorted, people take turns sharing their situation. Doing this, participants come to see what a wide range of different experiences are present in the room.

    After this, participants get to sort themselves again, this time according to the level of energy they perceive in that same project. Really low energy in one end, and high in the other. We talk about it again.

    Finally, we do the same thing, this time based on how much experience and knowledge of Scrum the participants feel they have.

    Earlier this summer, I participated in a terrific one-week workshop with organizational development pioneers Charles and Edie Seashore. The name of the workshop was “Intentional Use of Self”.

    In one part of the workshop, we talked about how check-ins are an important part of helping a workshop group come together. We also did check-ins every morning. One format we used was based on a fishbowl. Charles and Edie would ask one small part of the group to step into the middle, and tell each other about some thing.

    Today, I decided to try this format out. I asked people in the class to step into the fishbowl based on how long they had been using Scrum.

    First, I asked those with no experience to step in and talk to each other about their current situation and their expectations for the course. After that, those with a few months of experience got to share. Then those with up to a couple of years experience.

    Finally, those of us with longer experience (I joined the fishbowl myself here) stepped into the inner circle a told each other about our experiences and expectations.

    Here’s what I like about Charles’ and Edie’s check-in:

    • Participants face each other, not just me
    • In a circle, it’s easier to speak up
    • When you do speak, you speak with a smaller group
    • Everyone else can still hear you
    • The fishbowl circle puts more emphasis on the likenesses we share, whereas the line creates an exposed situation for those on the ends of a line.
    • We still get to see the different experiences available in the group

    It’s a simple but powerful check-in format. I’m fascinated by the fact that I had to travel half-way around the world to pick it up. I’m glad I did.

    Do you facilitate workshops or teach classes? Do you use check-ins? What kinds of check-ins have you tried so far?

  • Pit of Specialization

    In an effort to prove I’m not a perfectionist, I’m publishing this work of art I just created, while sketching out some ideas for an upcoming talk. Being a specialist can be a double-edged sword.

    Have you experienced this pit? Did you like it there, or did you find a way to get out of it?

  • Tankar om rollerna i Scrum

    Jag skriver på en bok med arbetsnamnet “Nyckeln till Scrum”. Min erfarenhet säger mig att de som lyckas bäst med Scrum är de som inte bara kan metodens praktiska steg, utan som också förstår varför den är utformad som den är. Beväpnad med den förståelsen öppnar sig också vägen framåt, möjligheten att gå bortom Scrum. Det här är ett avsnitt som handlar om roller, som kanske kommer med i boken.

    Enligt ordboken på min Mac härstammar ordet ”roll” från det inte längre använda franska ordet ’roule’, som syftade på den rulle med papper som skådespelarens roll stod skriven på.

    Till skillnad från andra modeller beskriver Scrum bara några få roller. Tre stycken, närmare bestämt: produktägaren, scrum mastern och utvecklingsteamet. Vi har inga speciella roller för de som deltar i utvecklingsteamet, utan nöjer oss så.

    Varför behöver vi roller överhuvudtaget?

    Det handlar om förenkling. Över tiden kan vi lära oss att närmast intuitivt agera inom ramen för en viss roll, eller bete oss på ett visst sätt i vårt samarbete med en person som verkar i en viss roll. Vi behöver inte hänvisa till en lång lista som beskriver ansvar och befogenheter. Vi vet vad som gäller, helt enkelt.

    Roller som verktyg är ett dubbeleggat svärd. De förenklar, men kan också förenkla för mycket. När du hör att jag arbetat som projektledare associerar du vissa beteenden och mandat med det. Du kanske kan tänka dig ungefär vad jag jobbade med, vilka typer av utmaningar jag brottades med och vilken sorts beslut jag fick ta. Tyvärr har du förmodligen fel. Inga två projektledarjobb är lika varandra.

    En fara med namngivna roller är att vi tror att vi vet vad som gäller när vi egentligen inte vet. Eftersom vi tror att vi vet ställer vi inte frågor om rollerna. Vi beter oss som om vi vore överens och blir förvånade när problem uppstår, eftersom vi var så säkra på att vi förstått varandra.

    Samma utmaning finns när det gäller rollerna i Scrum. På pappret ser de tydligt definierade ut, men i praktiken är det inte är fullt så enkelt.

    När jag undervisar i Scrum brukar jag dela ut varsin specialgjord kortlek till grupperna på kursen. På varje kort står ett ansvarsområde eller en fråga. Jag ber grupperna dela upp korten i tre högar, en för varje roll i Scrum, så att rätt kort ligger på rätt roll. Jag förklarar att de är klara när de är helt överens om sorteringen. Det blir de aldrig.

    På ett av korten står ”Kan du förklara den övergripande arkitekturen?”. Gruppen vrider och vänder på argumenten för att lista ut vem som egentligen borde besvara denna fråga. Det brukar bli jämnt skägg mellan produktägaren och utvecklingsteamet. Några hävdar bestämt att det är utvecklingsteamet som borde ta denna fråga. Andra är lika säkra på att det är produktägaren. Det brukar sluta med att man får lägga kortet åt sidan.

    När vi efteråt går igenom övningen frågar jag deltagarna om de kan definiera ordet arkitektur. Utan undantag visar det sig att de som tycker att produktägaren borde fått frågan anser att arkitektur handlar om produkterbjudandets olika delar, som produktägaren självklart måste behärska för att kunna förklara produkten. De som röstar på utvecklingsteamet tycker istället att arkitektur handlar om den rent tekniska lösningen, som teamet ansvarar för. Olika definitioner leder till olika syn på ansvarsområdena.

    Flera frågekort är svåra att placera eftersom de beror på vilken kompetens som finns var. En fråga lyder: ”Exakt hur är det tänkt att den här dialogrutan är tänkt att fungera?” Somliga svarar snabbt utvecklingsteamet. Produktägaren ska ju inte vara inne och pilla i detaljer, och naturligtvis har vi antingen en separat gränssnittsexpert med i teamet, eller minst en utvecklare som behärskar området bra. Andra protesterar. Deras utvecklingsteam består av programmerare som inte behärskar gränssnittsutveckling, och ser det därför som självklart att produktägaren är den man går till för denna typ av frågor. Ytterligare andra menar att frågan handlar om situationen när teamet inte kan komma överens, och arbetet blir lidande för att ett beslut inte tas. De menar att det är produktägarens jobb att kliva in och ta beslutet. Vid ett tillfälle påpekade någon att det kanske handlar om utveckling av ett gränssnitt för en operatörspanel i ett kärnkraftsverk, och att produktägaren därför är med och bestämmer även om de minsta detaljerna, eftersom de är en sådan avgörande framgångsfaktor för produkten.

    Det är sällsynt att någon helt missförstått någon av Scrums roller – ändå blir tolkningarna helt annorlunda. Sammanhanget avgör tolkningen. Vi är inte ute efter den enda sanna tolkningen, vi är ute efter den tolkning som passar bäst, utan att göra våld på rollens grundläggande skrivelse.

    En fördel med att inte skriva rollbeskrivningar med extrem detaljskärpa är att de blir brett användbara. Nackdelen, om man får säga så, är att vi måste tänka efter mer själva. Vi måste sätta in rollen i sitt sammanhang, och se vad som händer då. Vi måste applicera metoden i vår kontext, lite på samma sätt som skådespelaren måste tolka sin roll utifrån den scen han står på och den pjäs han spelar. Det finns inte en sann Hamlet, lika lite som det finns en färdig definition av vad det innebär att vara produktägare, scrum master eller medlem i ett utvecklingsteam. Allt vi får är papperet med rollen på, sen är det upp till oss att på darriga ben stappla ut på scenen och agera.

    Vilka är dina erfarenheter av namngivna roller på jobbet?

  • An Exercise for Defining Done for Scrum Teams

    In this post, I’m going to share an exercise you could try for helping a team start their journey towards a clear and shared definition of what it means to done with a feature in a software product. I’m looking at this from the perspective of agile development with Scrum, but my guess is you can use this even if you’re not using Scrum. I’ve taken a core exercise I’ve used many times to help teams form a first definition of done, and combined it with some debriefing practices I’ve learned over the years. If you want to use this exercise, go ahead. If you run it a couple of times, you’ll be able to improve on it: then I’d love to learn about how you improved it.

    Scrum has taken some flak because many perceive the model as lacking a clear focus on solid development practices such as automated unit testing, refactoring and code or design quality in general.

    It’s true that Scrum does not supply us with a detailed definition of exactly how software should be developed. What we get instead are some general admonitions. From these, we need to create our own set of practices that are suitable in our specific context. Here are the general rules that Scrum gives us:

    • Every sprint should end with a done product increment
    • Done means having something potentially deployable, something of business value
    • Potentially deployable implies a well designed and well tested solution, documented with user manuals if those are needed for the product to be usable

    As a quick sidenote, let’s explore why we like to say “potentially deployable”, rather than “deployable”. Adding that extra word – potentially – gives us a useful, albeit sometimes risky, window of flexibility. What it means in practice is that, if by the end of the sprint we realize that we could gain from deploying, we should be able to do that deployment with just a little extra work. In an ideal world, we would be able to deploy directly – and some companies can do this. However, a company just starting out with Scrum probably cannot do this. They need to improve the way they develop software until they can be “more done” every Sprint, thus acquiring the ability to capture potential business opportunities by deploying early and frequently. The risky part: some will be satisfied with building “good enough” product increments, forgetting that in the long run, insufficient quality very easily turns into terrible quality.

    How does a team move from Scrum’s general definition of done to a detailed description of what done means for them? The team can get there over time, by inspecting and adapting every sprint. If for example, we notice that planning meetings take too long and are fraught with hostile discussions, we might want to explore if we really agree on what it means to be done with something.  If you and I are in the same team, and your definition of done is “if it compiles, ship it” and my definition happens to be “refactored, well designed and thoroughly tested”, we’re bound to have frustration and misunderstandings. If this is the case, a clear and shared definition of done will be very helpful.

    Let me describe an exercise I often use in my classes and workshops. It builds on several ideas to help a team get going with their work on defining what done means to them. The ideas I’ve built the exercise upon include these:

    • When asked if we agree on something, we sometimes say yes just to avoid exposing a conflict, so we need to find a way to safely expose disagreements that prevent us from working well together
    • Agreeing on a definition of something is often hard work, so we could use some help to get going and to avoid some common pitfalls
    • Simply stating that you agree is not as powerful as when you actively participate in the discussion, so we can use a setup that entices as many as possible to step in and actively participate

    Over the years, I’ve tried some different approaches to this. Let me give you a step by step description of the exercise the way I myself will do it the next time I use it. I think it will work well, because the core of it is about really activating participants and in getting the discussion going in an effective and safe way.

    Preparation

    1. On a set of regular size pages, type out a list of items that might be included in a team’s definition of done, such as: “Code is refactored”, “Automated unit tests written”, and so on. Take care to express things clearly. I have a set of four or five pages with things. Some of them are quite uncontroversial (“Code written”), some are things that typically need to be discussed and refined (“Full performance test run”).
    2. Format the pages so that each thing stands on its own line, a couple of centimeters (an inch) high, with large type. Add horizontal separators between each line, so that the sheets can easily be cut into slips.
    3. Add an extra page with blank lines that the team can fill in themselves
    4. Print these pages and bring them – and a couple of scissors – to the workshop.

    The Exercise

    1. Invite the team and set the room up so that everyone can work together comfortably around a large table.
    2. Explain that you are about to engage in an interactive exercise together, and that the purpose of it is to see if we can find a shared definition of what being done with a product increment means to this specific team in this specific project. If the team is new to Scrum, a mini-lecture about how defining done fits into Scrum’s iterative and incremental way of working will also help here.
    3. Hand out the sheets you prepared, and ask the team to cut them up into strips with the scissors you supplied. I prefer letting the team do this work, because doing something physical is an nice way for the them to slowly “warm up” for the hard parts of the
    4. Explain that the blank slips can be used to add missing items, if needed.
    5. While the team is doing the cutting, prepare a flip chart on the wall. On this flip chart, draw a vertical line down the middle, so that you get two columns of equal width. Over the left column, write the heading “Every sprint”. Over the right column, write “Before release”.
    6. Wait for the team to end their cutting, then ask for their attention. Explain the flip chart. Tell the team that you want them to take this flip chart and put it on their table. Say that you want them to sort their strips into the two columns. In the “Every sprint” column, they are to put every item that they agree should be performed by the team during each and every sprint. In the other column, “Before release”, they are to put items that they think are important, but that for some reason cannot be done in every sprint, but that definitely must be done before the product can be shipped out. There is typically no need to go into why something might end up in the “Before release” column, but if the question comes up, briefly explain that for technical or economical reasons, it can sometimes be hard to fit some things into the sprint, and that this may or may not be true for the current team.Defining done

    7. Explain that what comes next is very important. Once you have the full attention of the group, reveal that they will do the sorting under complete silence. This is usually quite surprising. Tell the group that they are to work in silence, until it is absolutely impossible to keep working silently. When this happens, but not before, they can start talking to each other.
    8. You also need to explain how the participants should handle differences of opinion during this part of the exercise. Explain that all participants have the right to place any slip in the place they think it should be. If anyone sees a slip that is in the wrong column, they can just move it to the right column. If you see someone moving a slip you just placed, just move it back again. You’ll notice if some slip keeps moving back and forth a number of times. If that happens, just place it on top of the line separating the columns, and keep working on some other slip. Don’t start talking when this happens, just keep going. When everything has settled down and you can no longer work in quiet, that’s when you can start talking about how to handle those hard to place pieces.
    9. Sit back and watch the team get to work. It’s quite fun. Take this time to practice your skills of observation – look at expressions, gestures, movements and think about what they might mean. If someone starts talking too early, gently remind them to work in silence for just a few minutes more, until most pieces have fallen into place.
    10. After some time, the team will notice it can get no further unless they start talking to each other. When this happens, most uncontroversial pieces have typically found their place, even though you can be sure there’s still no agreement. Depending on the team, you might need to facilitate this lightly. One way to do that is to ask some questions, like “I notice you’ve placed this slip here (point to a slip) – how did you decide on that?” Some teams naturally take to discussing, others need more help to get started.
    11. Let the team take its time working on the sorting. Remind them that we’re searching for a shared and usable definition of done, something that they could potentially use in their current project right away.

    The Debrief

    1. With the slips sorted into columns, hand out some tape and ask the team to fasten the slips to the flip chart they’ve been working on, then to post the whole thing on the wall.
    2. Ask the team: “You’ve created your first definition of what it means to be done with a product increment in a sprint. What are your thoughts now?”
    3. Write down the reflections that come up, exactly as they come up, on an empty flip chart.
    4. Next, write the heading “Suggestions” on a blank flip chart, then ask the team: “What are your suggestions on what you as a team should do next?”. Clearly explain that we’re currently only after ideas, that we’re not deciding anything yet.
    5. Help the team do a silent brainstorming to identify as many suggestions as possible . My experience is that a silent brainstorming results in more and more-varied ideas. To do this, just hand out sticky notes and ask participants to write one suggestion per sticky note. Set a time for this, perhaps five minutes, or maybe ten. I usually go with five, then ask if more time is needed when those five minutes are up. When the time is up, let those still writing finish their notes, then ask participants to take turns posting and reading their suggestions.
    6. With all suggestions up on the wall: do a quick dot voting to gauge the group’s thoughts about the suggestions. Ask each participant to place exactly five voting dots on the suggestions he or she thinks has the greatest potential in helping the team perform better. Explain that they can place the dots any way they want, all on one suggestion or distributed over several sticky notes. Explain that this still does not mean we’re deciding anything – we’re just trying to get a feel for the group’s overall interest in the suggestions.
    7. When the suggestions have all been posted, write the heading “Next steps” on a fresh flip chart and tell the group that the time has come to see if they can decide on some next steps to take. Ask the group: “Can you agree on some next step?”. Someone typically shouts out one of the previously posted suggestions, or something that is a synthesis or rewording of one of those suggestions. Help the group formulate the next step as a clearly stated action. Ask the group if they agree that doing this action is desirable. Use thumb voting if needed: thumb sup means agree, down means don’t agree, sideways means “I don’t care, so I’ll go with what the majority decides on”. If someone shows a thumbs down, work with them to modify the suggestion or create a new one, until agreement is reached. If no thumbs are pointing down, the group has decided.
    8. Ask for more next steps, until you have enough to see that the team will take some clear next steps to keep moving with the work they’ve just done on defining done. If everything goes well, the team will suggest activities that relate to incorporating the new definition of done into the daily work. If things go less well, they might not – but this is also information, and you should be glad that it comes up now and not later, when you’ve tried to build a product without first agreeing on how to work together. Don’t be surprised if the team comes up with really inventive and ambitious ideas, and choose to act on them – my experience is that this happens more or less every time I work this way with a team.

    The first definition of done agreed upon by a team in an exercise like this will not be the final one. Whatever you do, don’t print out and laminate this definition. As a team learns more, builds more capacity, and learns to work better together, they might realize that they can improve their definition of done. A team using Scrum then implements these improvements, and it does this in a way that ensures that the whole team is in on the changes.

    A word of caution. You might think this whole exercise seems like a waste of time. After all, how hard is it to create a solid definition of done and just hand it to the team? In fact, if you’ve been in the software business for a few years, that’s not hard at all. However, creating that list does not mean that the team will use it. Defining done is more about finding consensus than it is about listing an optimal set of practices. I’ll take a less impressive but widely shared definition of done over an ideal but ignored list any day. If we know where we stand, we can always improve from there.