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

Broken Software

I sometimes hear the agile manifesto being criticized for focusing on “just working software”. It’s said that working software is not enough, that we need to reach further. I agree that we need change, but not in the wording.

If your definition of working software is “if it compiles, ship it”, then the manifesto’s words won’t seem like they change much. For you, the manifesto sounds like business as usual.

Twelve years after first reading it, the agile manifesto still doesn’t sound like business as usual to my ears.

Here’s the thing. I really like software. Really. I always have, ever since I used my first computers as a small kid. I guess computers and software filled a spot for me.

I don’t like all software. I like software that does its job and is a pleasure to use. I’m on a continuous quest to find more software like that, but many of the apps I try suck.

It’s not working software if it doesn’t work for me. Then it’s broken software.

As a user, I’m not content with software that works in the sense that “all functions are there, but that’s about it”. If it does the job, but is a pain to use, I don’t think of it as working software. I may even come to hate it, because now I know that the software could have worked, but its creators didn’t care enough to make it lovely to use.

When developers lack a passion for the user, the result can never be working software. Instead, we get broken software. Broken software is not working software.

For me, the problem is not the expression “working software”. That makes perfect sense. The problem is that some software makers still have a broken definition of what working means.

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?

The Freedom to Solve Problems

Isn’t it really sad that employees in some companies aren’t allowed to solve the customers’ problems? In Sweden, the major telecom operators are notorious in this regard, in my personal experience.

What is it like in your company? Is everyone allowed to and capable of really helping your customers?

“In addition to encouraging creativity, bossless environments also increase efficiency, according to Stephen Courtright, a management professor at Texas A&M’s Mays Business School. He cites the example of Southwest Airlines, which allows baggage clerks the freedom to decide how to solve a customer’s complaint on the spot, without having to say, “‘Wait while I consult my boss.’”

Going Boss-free: Utopia or ‘Lord of the Flies’? – Knowledge@Wharton.

There’s Always One [Drop|Comment|Question] Left

My childhood friend’s mother was a “dagmamma”, literally, a “daytime mother”. In other words, she took care of a bunch of other people’s kids in her own home.

She was a very kind and intelligent person. One of the things she said has stuck with me to this very day.

“There’s always one drop left.”

She would say this when we had had finished our “fika” (for kids in Sweden, this would be strawberry juice and cinnamon buns) and we would start playing with our empty glasses. Or rather: we thought the glasses were empty, but she knew better. That’s why she reminded us.

I think of this every now and then when facilitating a meeting or a workshop. Whenever you ask for comments and questions, there comes a point where the contributions start to taper off. Silence commences. This is where you as the facilitator or convenener should stay quiet, too. Because, to paraphrase the wise dagmamma:

“There’s always one comment left”

Keep quiet. Count to twenty in German *) to focus your attention on something other than the heavy silence, and lo and behold. One more reflection always pours out.

 

*) Silently, that is. If you experiment with counting loudly in this situation, let me know what happens. I haven’t tried it yet.

Late Again, Thinking About the Cost of Delays

It’s Wednesday morning, and I’m on the train heading to Stockholm. The train is late, and it’s not the first time.

One reason delays annoy me so much is that they break my expectations. I’ve made my plans to fit with the train company’s timetable, and now they are not upholding their part of the commitment.

Then again, when it comes to riding the train from my hometown Uppsala to Sweden’s capital – Stockholm – delays are such an integral part of the experience that I’m no longer surprised when they happen. Curiously, they still annoy me. Maybe it’s because the company running the trains couldn’t seem to care less about the problems the delays are causing me. Somehow, they still manage to act like every single delay is a big surprise to them. I take comfort in the fact that I get some extra time to read and write, as long as I’ve found a place to sit on the train – but that’s another story.

Anyway, while a train delay may not seem a huge thing to fret about, consider its less obvious effects. When I don’t make it on time to my networking meeting, I miss out on information and networking that would be valuable to me.

Intuitively, we know that being late costs us, but we easily focus on only one narrow part of that cost: the increased cost of working on something for a longer time. We forget that we also push the rewards into the future, and that might be costing us even more.

In general, I find that a concrete cost today is easier to grasp than a probable loss in the future. Maybe it’s because we find it hard to think about loosing something we never really had in the first place. I guess this is one of the reasons we make short-sighted decisions.

If you want to learn more about understanding your cost of delay, Donald Reinertsen’s books are a good investment: Developing Products in Half the Time, Managing the Design Factory and The Principles of Product Development Flow.

Johanna Rothman to Stockholm, May 30, 2012

Author, consultant and teacher Johanna Rothman is coming to Stockholm on May 30, this year. She will be leading a one-day workshop about the agile project portfolio. The course will be in English, and I highly recommend you check it out if you need some inspiration on how to manage in a situation where you have multiple projects going on.

Here is the course page (in Swedish, but remember, the course itself is in English): http://www.citerus.se/curriculum/724094-agile-project-portfolio-management

If you haven’t heard Johanna talk before, there’s an interview with her on InfoQ. Watching it is time well spent.