Missing Pigs

A Scrum Smell

29 May 2007

Mark Randolph
Echota Technologies

Importance

Vital

Symptoms

Developers failing to attend or actively participate in daily Scrum meetings is an obvious smell, but of what? 

Unclear expectations?
Competing assignments?
Lack of commitment?
Supervisory interference?
Weariness?
Fear?

Even when developers attend Scrums reliably, they can be absent in other ways:

Perfunctory reports
Withdrawal or non-participation
Disruptive behavior

These odors can suggest deep problems. Nonetheless, these problems can be solved once they are understood.

Discussion

Daily Scrum meetings are brief gatherings at which team members answer three questions:

What progress has been made?
What will be done that day?
What obstacles have been encountered?

The power of a “daily” is to focus on results. Whereas status meetings highlight activity and effort, a daily boosts collaboration and removes obstacles.  That distinction is everything.  Feel the difference between “What are you working on, when will you be finished, and how much time have you charged?” and “I have the feature coded, and if I can get access to the network I can get it done today.”  Scrums are about results, not activity. A healthy and effective Scrum team achieves more in a fifteen-minute meeting than classic projects achieve with all of their planning, process, and paper. 

Daily attendance—and active participation—by all team members is vital. Bacon has to be in the frying pan—and bacon comes from pigs. If your pigs aren’t active in your meetings, you’re left with raw pork.

Analysis, Remedies, and Case Histories

Why are the pigs missing?  Is it a:

Circumstantial problem?
Behavioral problem?

Analysis, remedies, and case histories for each category are addressed separately below.

Circumstantial Problems

As “advocate for productivity,” it is the ScrumMaster’s duty to remove obstacles to team progress.  So, what are the obstacles to full attendance? Here are examples:

Inconvenient meeting times or locations
Conflicts with mandatory activities, such as project, staff, or sales meetings
Competing project assignments
Supervisory interference
Unclear expectations
Teams distributed across multiple time zones
Shift work

Remedies to try:

(1) Establish rhythm
(2) Role model
(3) Change meeting time and location
(4) Explanation, persuasion, and negotiation
(5) Embrace technology
(6) Reorganize the team

Establish rhythm. Establish and maintain good habits—rhythm—by holding the Scrum at the same time and in the same place everyday. Insist everyone attend. Follow up with those who don’t. At the beginning of a project, or during a sprint retrospective after project start, be clear that daily attendance is expected and non-negotiable.

On teams with good rhythm I’ve had members say it feels “odd” or “uncomfortable” when the team can’t meet. For more on the benefits of rhythm and how it can be achieved and maintained, see the article “Loss of Rhythm” on this website.

Role model. Never miss a Scrum. Teams and individuals will never treat daily Scrums as important unless the ScrumMaster treats them as important. If absence is unavoidable, dial-in or appoint a deputy ScrumMaster. Don’t cancel a Scrum just because the ScrumMaster will be absent.

Change meeting time and/or location. For the sake of rhythm, it would be ideal to hold the daily scrum in the same place, early in the day, every day so the team can discuss obstacles and plan work for that day. However, if the current meeting time and place are not working out, use the retrospective portion of Sprint planning to negotiate a new meeting time and place. Keep trying new times and places until the best solution is found, but resist making changes except at Sprint boundaries or you risk breaking team rhythm.

Explanation, persuasion, and negotiation. Talk your way out of it. You’re the ScrumMaster. That’s what you do for a living. Find the source of the interference and see what can be negotiated. Speak with individual, their supervisors, or your external stake-holders.  Recruit your external stake-holders to influence others who might be deliberately or inadvertently interfering.

Embrace technology. Distributed teams have to use speaker phones, instant messaging, web conferencing, and cell phones, but creative application of technology can also solve meeting problems of collocated teams. I worked on a corporate campus where it could take longer to walk to a central meeting room than the Scrum would last. Today I could dial into a speaker phone two buildings and five floors away to Scrum with three other team members, with the odd man out dialing in on a cell phone. Welcome to the 21st century.

Reorganize the team. Reorganizing the team may work in instances when Scrum team members have interfering assignments or are not collocated. For example, we originally organized teams by project, with team members assigned to multiple teams. Consequently, a developer would attend two or even three Scrums a day. We could have avoided this by assigning multiple projects to single teams, in which case each member would have one Scrum with all projects remaining covered.

Behavioral Problems

Even when developers attend Scrums reliably, they can be absent in other ways:

Perfunctory reports
Withdrawal or non-participation
Disruptive behavior

Remedies to try with individuals:

(1) Act from knowledge
(2) Clarify expectations
(3) Individual accommodation
(4) Shuffle the team
(5) Manage the personality
(6) Be a heavy

Act from knowledge. Never assume anything regarding behavior.  Insensitivity or lack of discretion can make behavioral problems worse. For example, do not immediately suspect lack of commitment. That would be unfair—even harmful—since behavioral non-participation may be a symptom of:

Confusion over expectations
A sense of inadequacy, fear of failure, or fear of accountability
Shyness
Sense of futility or hopelessness
Weariness

Find out by asking the individual (privately) or someone who knows the individual (discreetly) what’s going on. Once the problem has been identified, choose an appropriate remedy. For example, shyness, fear of failure, and fear of accountability frequently respond well to kind words of encouragement and support.

Clarify expectations. Ensure everyone knows not just the mechanics of a daily, but the expectations for participation. Sprint retrospectives are appropriate venues for such discussions.

Individual accommodation.  As an example, if someone is weary, suggest to the team (after sponsors and other external stakeholders have left the room) that the team explicitly excuse the individual from the Sprint and let the individual (insist that the individual?) work on something other than the project for a week. Other individual accommodations can be made for other individual needs.

Shuffle the team. Teamwork is not for everyone. It is appropriate to approach this discreetly with affected individuals before taking action.  This allows them to influence or make the decision.

Manage the personality. People have all sorts of quirks:

Asocial personalities
Drama queens
Passive aggressives
Prima donnas

Indulging such individuals by enduring their antics in the hope that they produce is not recommended as it leaves the personality in control. Here is an example of a constructive alternative approach: Assign the personality a trusted assistant or “understudy” who can report on behalf of the primary and act as an intermediary for assignments. In this way, the team gains the benefit of the talent while being spared the disruption. Junior or entry level developers are candidates for understudy assistants, in which case, the understudy may even learn something!

In any case, start with Remedy 1 (Act from Knowledge) and do some homework on the Web. For example, google “passive aggression” and a number of good resources pop up.

Be a heavy. We are not discussing threats of physical violence, emotionally satisfying though that might be, but rather the naked use of authority. To be effective, clarity and consequence is required. Here is a formula for a conversation:

1. Introduce the topic, describing the unwanted behavior.
2. Explain why the behavior is harmful
3. Propose a specific remedy or a consequence

Listen to the response, and be prepared to re-engage

For example, following a flat statement from an individual that they refuse to attend Scrums:

1. “Let’s discuss your refusal further”
2. “Four of your teammates are waiting on database queries that you are writing. You need to be present to know what obstacles your team is encountering.”
3. “If you refuse to attend, I will notify your department head.”
4. “What do you want to do?”

Consult the abundant literature on handling difficult employees for other ideas.

Case history
We’ve had more than one person who had absolutely no use for daily Scrums. In one case, the individual (we’ll call him Shannon) showed up and gave a perfunctory report, but through body language made it clear they thought these meetings a waste of time.  My conversations with Shannon confirmed that he was not uncooperative (he did show up every day), but all Shannon wanted to do was crunch code. “Just tell me what you want written and I’ll do it.”  So, in truth, the problem was rather benign.

Acting from this knowledge, and since my desired outcome was no more complicated than specific, rather than perfunctory, reporting, I looked for simple remedies. In negotiating possible adjustments, Shannon suggested submitting daily e-mail reports. A fundamental Agile principle is to prefer face-to-face meetings over paper systems, so this was inadequate, but it did give me the opportunity to explain that daily Scrums were not status meetings, but coordination meetings, and an opportunity for Shannon to request completion of components of value to him. I went on to point out instances where he had actually benefited, not only on this project, but on a previous one. I also offered to make daily Scrums as convenient as possible by holding daily Scrums in his office.  Finally, I acknowledged and thanked the individual for his willingness to cooperate, which he seemed to appreciate when he saw I was sincere.

Summarizing:

I got to know the individual (Remedy 1: Act from knowledge)
Explained that Scrums were not status meetings, but coordination meetings (Remedy 2: Clarify expectations)
Started meeting in their office (Remedy 3: Individual accommodation)
Acknowledged my appreciation (Remedy 4: Manage the personality)

I would like to report the project a success, but the Scrum ultimately failed when I was unable overcome complexities introduced by another individual. Sometimes the magic works. Sometimes it doesn’t.
Resources

[1] Loss of Rhythm. Mark Randolph. http://www.scrumalliance.org/articles/34-scrum-smells-loss-of-rhythm

[2] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. March 10, 2004.
ISBN 073561993X. Chapter 1. Page 1. This is a good summary of the Scrum approach and includes discussion of the daily Scrum.

[3] Mike Cohn. Mountain Goat Software web site. 06/15/06.
 (http://www.mountaingoatsoftware.com/article/view/11)


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Mike Lowery, CSP,CSM,CSPO, 6/20/2007 3:18:42 AM
Mark,
I would appreciate your thoughts on how to get the team to feel the meeting is for them and not a status report for the Scrum Master. Knowing that the Daily scrum is not "my meeting" (being the scrum master) made me concerned that the team allways looked at me when going through the 3 questions.
I have tried standing behind them - but that made them feel uncomfortable.
I have tried sitting so they can not see me - but that made me feel rude.
I have tried putting desks between us so that they are in "the pig sty" and me in the "chicken coop" but they still look at me.
Talking about it to them and trying to point out it was their meeting not my "catch up".
Any thoughts would be greatly appreciated.
Mark Randolph, CSM, 6/25/2007 12:08:07 PM
I think you and the team are doing fine. As the ScrumMaster you are aware of and have already avoided several pitfalls; you donΓÇÖt direct the team, it is not run as a status meeting, and you want them to own their work. In short, you are a ScrumMaster who "gets it." Your team is in good hands.

What the team (and you) may be experiencing is simply an adjustment to a change of roles. Since this is a new situation for them as well as for you, I wonder if they arenΓÇÖt just looking to you for reassurance, "Am I doing this right?" So, provide it. Within the context of this article, (1) Act from knowledge; (2) Clarify expectations; (3) Role model. You are already clarifying expectations, so IΓÇÖll address knowledge and role modeling.

I tend to be bold with these things. In the middle of a Scrum I might ask the group, "This is new to me. Does everyone feel a little awkward like I do?" Or if that is too assertive, I'd ask one or more individuals the same question discretely after the meeting. Regarding role modeling, go first and give the kind of report you'd like them to give. You might even preface that with, ΓÇ£This is the kind of report Scrum expects...ΓÇ¥ You can also reinforce success. If someone gives a particularly succinct report, say, "That was a succinct report! I liked the focus on objectives. Can someone help Teri with that obstacle?" Then step back. Let the team work it.

Mike Cohn shared this with me. ΓÇ£I've had teams stand in circles for their standups and if the meeting feels like it's for me, I turn by back to the circle. It's a bit rude at first, we laugh it off. Then it becomes a bit of a joke--"Uh, Mike's starting to turn around..." Mike went on to say, ΓÇ£The weird behavior becomes the reminder and isn't needed except in that bit of a joke way over the long term.ΓÇ¥

Did this help?
Rahul Sawhney, CSP,CSM, 6/27/2007 5:22:36 AM
I thought of adding a couple of lines on this. In my experience, starting off with the daily scrums is the most difficult part. Once the teams have tasted blood, they get addicted. To keep teams motivated, consider this: 1. Lead from the background. Stress on impediments that block them. 2. Make tasks visible. In my case, the teams themselves came with an approach to do this. We came up with an approach to use post-its to paste tasks against each others' names whenever we face a bottleneck. Most of the things get sorted in the short meeting where there are issues, those post its end up with the scrum master. 3. Encourage people to call each other for scrum meetings. 4. Have only stand-ups: No sit downs. 5. Do not use meeting rooms. If one person sits, others follow. 5. Ask questions only to one or two persons. People will get used to the questions in couple of days and start answering them on their own. 6. Praise people if they did something interesting.. Sometimes we clap for the team members 7. Use retrospection meeting as a tool to engage with the team (we did away with weekly team meetings when we started with daily Scrum meetings), i am quite positive that you will get support from majority team members that its worth it.

Your opinion on this, Mark?
Mark Randolph, CSM, 10/17/2007 10:13:06 PM
I concur getting teams comfortable with the daily Scrum can be a difficult. Discouragement is to be avoided, though. Good Scrums are essential to success because (1) they avoid drift and keep teams focused on the current backlog, and (2) They highlight obstacles so they can be attacked. The teams that have failed for me, are the ones that I neglected. With even three weeks persistence, teams come around, and their rythm emerges. The ideas Rahul offers are creative and likely to be effective.

You must Login or Signup to comment.