Published Articles

October 29, 2010

My last post discussed Accountability and Self-Organizing (Scrum) Teams. In our years of Scrum development, we’ve managed to get some things right and some things wrong. Our biggest problem area seems to be drift – we start out fine but gradually drift back into old habits.

Daily stand-ups are a common area that I’ve noticed issues with accountability. Our organization stresses respect and courtesy, but at times we’re almost too nice. I’m a frequent attendee at many daily stand-ups (a.k.a., daily scrum), and I always (well, almost always) wait until invited to speak, respecting the boundary between management and the self-organizing team.

Consider the following scenarios involving the daily stand-up and answering the “three questions”:

Scenario #1: An individual responds to the What will you do today? question with, “… and I’m available for work” (or to help anyone). And the meeting concludes without this individual actually committing to any work or pairing with someone who could use a hand, despite the fact that there are task cards in the “not started” column of the team’s board and/or scenario #2 surfaces.

Scenario #2: An individual has been working on a task estimated to take two days, and its day three of the sprint. This individual reports, “I’ve been working on task XYZ for 2 days, but it is more complicated than we thought and it looks like I’ll need two more days to get it completed; and I have no impediments.” The remainder of the team nods, reports on their progress, and the team breaks and goes back to work.

What’s going on? What should you do as a manager?

In the first place, the ScrumMaster is someone who has authority to speak at the stand-up, and the ScrumMaster is responsible for guiding the team in its implementation of Scrum. In Scenario #1, the ScrumMaster could have asked the individual, “And what are you committing to today?” before allowing someone else to begin. In Scenario #2, the ScrumMaster could have asked, “It sounds like this is much more involved as we thought; would it be advantageous for someone to pair with you?”

Either scenario should be discussed during a retrospective, along with team modifying its working agreement as an improvement. For experienced Scrum teams, I expect more from everyone involved. I’ve been having conversations about accountability with my direct reports, talking in terms of these scenarios and how people should be holding each other accountable – in depersonalized ways. (Discussing accountability in terms of behavior and action, not as a threat.)

During one-on-ones, I’m encouraging people to speak up when they need help – especially when things appear to be more involved than initially thought. As a member of a Scrum team, it should be considered perfectly acceptable to ask for help and not be a personal reflection on your inability to get something done. Perhaps another set of eyes is all that you need to simplify a task, or to work on something extra because something truly is more involved than anyone thought.

The key to remember with Scrum is that stand-ups are not supposed to be simple status updates. Stand-ups are a mechanism for the team to manage its work. And while it’s honest to report that you need two more days for a particular task, is that being completely responsible in context with a team that is supposed to be getting high-priority tasks into the done column?

Transparency is another component of this. Give people insight into your work by being specific. This will allow the rest of the team to understand exactly where you are and what you are struggling with. This can trigger someone else to say, “I’ve worked on something similar to that in the past, I think I can help you,” whereas being vague and general about your work will cause people to simply nod and not be engaged about your task because they can’t relate to it.

I’m also reminding people that they should be asking others if they need help in situations where it is observed that a task is taking longer than planned. We’ve had situations where teams have let someone grind out a higher-priority task while others move on to the next task in the queue. This creates trouble because there too many tasks in flight at one time.

When many tasks are being worked concurrently the emphasis shifts back to individualized work with little to no collaboration and shared ownership of the work, negating the benefits of teamwork. The consequence of this will be instances where sprints end with very little completed, with carry-over of work into the next sprint. Limiting the work in process forces teams to consider how they can collaborate and get the highest-priority tasks into the done column quicker. Try it!

I’ve also tested people on something else, given the instances where I’ve seen little recognition of tasks going long during stand-ups. I’ve asked people if they know what they are going to say prior to the stand-up or if they are preparing their elevator pitch during the stand-up, which distracts them from paying attention to listening to others and managing the team’s work. I’ve gotten a couple of guilty grins when I’ve asked this question. I trust my people and they recognize the problem with this, so I’m sure that we’ll see improvement.

As you can see, the reasons for so-called “failures” aren’t deliberate acts of sabotage. People intend to do a good job, but highly collaborate teamwork is foreign to the years of very individualized focus that many organizations have. Consider the “failure” of accountability as outlined in Scenario #2; Could it simply be a consequence of a strong sense of personal responsibility and commitment, where someone wants to deliver on what they said they would? It can, and if that is the situation, I classify this as a good problem. A problem in a team context, but it’s better than someone who is simply not focused or uncaring about the team’s commitments.

As a manager seeking to overcome the individualized focus that is programmed into so many of today’s workforce, you need to continually point out that the objective of teamwork (and Scrum) is to maximize the output of the team, and that there are advantages to shared work and collaboration. And you need to support the teamwork first, individual second concept with performance expectations and reviews.

Post a Comment

Welcome!

I'm currently an independent agile coach, residing in Portland, Maine. My work experience includes being a developer, a development manager, product manager/chief product owner, and agile coach. This blog is about channeling my passion for business, software development and writing – with an emphasis on agile leadership. The opinions expressed in this blog are my own and do not represent the views of my current or former employers.