RallyDev.com
The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ken Clyne
If a team member doesn't take accountability, things can get messy
With a four year old and a six year old, familiar sayings around our house are “pick up your toys,” “pick up your clothes,” “brush your teeth,” “get dressed.” Of course, as parents we could get our short-term objectives met much faster if we just did these tasks ourselves… but we don’t.
We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.
Giora Morein takes somewhat the opposite view in a recent Agile Tip of the Month article. He proposes that ScrumMasters (or, in my extreme analogy, the “parents”) should track hours remaining on a sprint on behalf of the team members (the “kids”). Giora says:
“Team members are focused on completing tasks and delivering value. The time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important. As such, the ScrumMaster should take on the responsibility of updating burndown data.“
While I don’t question Giora’s good intentions and there is no doubt this approach is expeditious, I believe it is worth striving to have the team update their own hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.
Here are some dangers I see in a team not taking responsibility for their hours:
- They become less accountable for the number they provide
- They don’t understand the mechanisms of the self-managing, self-organizing team
- They become dependent on the ScrumMaster
- The ScrumMaster becomes frustrated and disillusioned
- The ScrumMaster morphs from a leadership role to a management role
- The team starts to revert to form
How does your team update its remaining hours? Have you tried one method that worked better than another?
Ken,
I agree with you! I am discovering that team complacency can be a huge factor in agile adoption failure. (I guess I need to update my list of 12 failure modes to 13!) The less the team owns, the more complacent they can become. So, part of buying into and embracing the Scrum process is believing in the power of reporting your personal commitments and what is left to do on them. Daily. Without this, the ScrumMaster starts to look and feel like a traditional Project Manager “owning the schedule” IMHO.
Thanks,
Jean
Ken, I agree with you. In an enterprise environment especially, with a professionally managed project, updating effort remaining is a critical component of communicating status and roadblocks to the project manager(s).
In a small team with a small scope system with limited dependencies, it doesn’t matter because the deadline is the deadline and some piece of …. is going to ship regardless of the quality or issues.
In an enterprise environment with integrations, dependencies and across teams, allowing developers to hold their breath until they turn blue ;-) is a very bad idea.
On Ken, you hit the hot button. Great post, but I need to comment on the form of your statement.
At home we use Love and Logic as a parenting approach and it tends to find its way into my leadership approach at work too. But, don’t tell anyone;) It is all about teaching responsibility through empathy and consequences. I highly recommend it.
In Jim and Charles Fye’s work, they would say something like this to a six year old: “I can play Lego’s with a guy who cleans up his room.” This tells them what you will do.
Since you are trying to gain responsibility in your team, a Scrum Master, I might say to an agile team: “I can facilitate planning meetings for a team that updates their remaining numbers”
I also like to call those “I trade ya’s.” I will give you something, if you give me something. I find putting them in the “I will” form is much better than a direct order like:”Pick-up your room.” Thought from a constantly learning parent!
Great post, Ken. I completely agree. The flip side of the self-organizing coin is that the team isn’t just _able_ to direct its own planning, it is _responsible_ for that planning and its outcome. I’m not sure all teams pick up on that facet of ownership.
Thanks for the comments everyone.
Please don’t stretch the analogy too far, it would be a shame if you thought I was suggesting development teams are immature, I’ll leave that to Scott Adams.
So how do we get our teams to update their hours remaining? Well if it is valuable then there will be an impact. So as a ScrumMaster you might want to let the team fail a sprint so the team can inspect and adapt. Just make sure you have regular retrospectives.
Of course, don’t use the inspect and adapt technique for teaching your kids to cross the road or take care of their teeth.
great post! I completely agree. It’s even a must IMHO to have each team member to update its timetable. Doing so everybody has an immeadiate feedback on ‘do my working hours match the workload accounted for feature XY’. I’m consider myself as highly motivated techie/geek. I therefore spend easlily too much work on technical excellence / technically interesting points. I really need a feedback that tells me to meet the expected functionality. This is no motivation killer at all. It is as motivating to see that the whole teams achieves its iteration goal on schedule.
Nice post Ken,
I’m not a fan of the parent-child metaphor when describing the relationship between ScrumMaster and team. I understand the point you are trying to make but to me that relationship is somewhat patronizing.
Regarding the practice of capturing time remaining on tasks: my tip was based on spending extended periods of time with many teams. My suggestion is very much that team members do update their individual task time remaining but rather than expect them to enter them in an electronic system, just communicate it verbally to a “human” system. In my experience, the interaction goes something like this:
ScrumMaster: “Hey John, you got a minute? I’m trying to get the burndown updates and I see on the taskboard that your name is on these three in-progress tasks. How many hours do you think you have left and is there anything you need or any way I can help?”
(I never ask how much time has been spent on a task – I find that useless.
I’m not sure what you mean by making a team-member less *accountable* to the number or why accountability to a number is important, but I don’t see how the interaction above would do so.
Likewise, I’m not sure how this in any way impacts the mindset of the self-organizing team. Nor do I think the team becomes any more dependent on the ScrumMaster than they are on any other team member.
“The ScrumMaster becomes frustrated and disillusioned” – I have not observed this. I’m not saying ScrumMasters don’t get frustrated but I don’t think this is the cause.
Ken, I agree in an ideal world all team members would happily update their own time. Unfortunately in my experience, this degrades into a ScrumMaster whining daily for people to update their hours. “…don’t forget to update your hours”…”did you update your hours?”….”c’mon guys, update the hours” (somewhat parental in tone too).
Given a choice, I would far more prefer a team update its own hours – just like you suggest. I’ve seen it done very successfully directly on a task board. But in order for even this to work, *everyone* on the team has to willingly do it all the time. Everyone has to buy-in to the value of the hour-update. Trying to get 100% of people to buy-in is a big mountain to climb and I would opt to fight other battles elsewhere.
Giora
Giora many thanks for the reply.
I don’t want to come across as dogmatic on this issue (goodness knows there is enough of that around already) so I’m glad that you have inspected and adapted and your teams are successful.
I think it would be a shame if we got into the habit of the ScrumMaster always doing this.
We used to take our best technical leaders, make them project managers and bury their beautiful minds under the burden of a team’s administration. We certainly don’t want to repeat that mistake with our ScrumMasters.
With a team that does not see the value in updating the To Do hours it might be interesting to discuss the impacts at the retrospective. Perhaps this discussion may lead to an innovative change in the team’s process.
I forget the thread I followed to reach this post, but I’m happy I ended up where I did. ;-)
The team I’m working with now ran into a situation last week that started me thinking about this issue again. The team is new, in its second sprint. In our initial team-formation gathering, we created a working agreement, and someone proposed, without being cued, that each team member update the time remaining on their current task before standup every day.
As ScrumMaster, I’ve been drawing the burndown chart by hand each morning, five minutes before standup starts. Last Thursday, after we started standup, someone said: “Hey! The burndown is wrong; we finished these two tasks.” I said, “Congrats on that! Tomorrow’s burndown will be more accurate.”
I’ve noticed that in the days since then, tasks are updated dynamically during the day.
Why did this work? It might be because our burndown chart is very visible to everyone in the company, including senior management, and because everyone on the team is aware that this project is one that’s being watched by their coworkers. So maybe they care about the burndown being right more than a team that’s got two dozen sprints under its belt. I don’t know; I’ll let you know what happens when this team is into Sprint 10…
Cheers.
+ Michael