Accountability in a Scrum World
One day last week, I was reflecting on the day I had, which included a Sprint retrospective of a failed Sprint - the second consecutive failed Sprint. This got me thinking about accountability. Specifically in the terms of Scrum methodology. In a Scrum team of peers from different disciplines (and different managers), such as PM, Dev and Test, how is the team held accountable for their results?
If a team fails to comlete their Sprint goal, what is the concequence, or is their no concequence? When it comes time to review the performance of the individuals, how do you rate them against the success and failures of the team. Does a developer, who completed all her tasks in the Sprint, get penalized for the failure of the Sprint?
Imaging a Scrum tean that has failed two consecutive Sprints. Their Sprint goal for Sprint 3 is "to accomplish the Sprint 1 and 2 goals." There was (and is) no concequence for the previous failures. What happens if Sprint3 fails?
Ultimately, following the Agile guidelines, if the team fails, all of the individual contributors have failed. There is no such thing as individual success with a team failure.
So, how do we hold a Scrum team accountable? What concequence is there for failure? We frequently reward project teams with successes (even late successes) through ship parties, recognition emails, awards, extra days off, etc. There is nothing driving the team to prevent failure beyond their own pride. Is that enough?
Comments
Anonymous
May 22, 2006
Doug,
As I read this post all I can think was, "WOW!!! How does a team fail in SCRUM Process." SCRUM was created in order to avoid failure and adapt to changes.
I would start by looking at why task are not being completed. My hunch is that the team isn't properly trained in the technology they're using. Another hunch I have is that management is driving the time of the task instead of allowing the developers to drive the time themselves.
I wouldn't be looking to hold the SCRUM Team accountable - I'd be looking at management and how they support the SCRUM Team. Do they get in the way of development? Are they micro-managing?
Remember, the SCRUM Master has to make sure things are getting done - if they're not completing task it's up to the SCRUM Master to figure out why and make the necessary changes.
Good Luck! My vote is with the Team...Anonymous
May 22, 2006
The first Sprint failure was a management issue - resourcing. There was not enough developer resources allocated for the first sprint. There were other issues in the sprint, including poorly defined stories and exit criteria. The primary reson was the resourcing.
The second sprint cause is hard to pin point - there were a lot of reasons including, poorly defined stories, lack of a team understanding of the exit criteria, poor communication, etc. There was non management interferance. The developer claimed he was outpacing the testers, and thus there was a bottleneck. The testers were testing against exit criteria the developer didn't know about. The product owner was failing to provide much clarity.
The team is now halfway into Sprint 3. About 1/3 of the way into the sprint the team came to a consensus on what should be considered the exit criteria for a story.
I am a believer in Scrum, and am curious at what point is the team accountable for failing at the process. It sounds like Victor believes that the team is never to blame - either management failed to get the team the training they need, or management isn't supporting the team appropriately.
In this team's case, they all (except one) have attended at least a full day of Scrum training. They all have been encouraged to read Schwaber's latest book. One of the team members in a CSM. The ScrumMaster is very experienced. Members of the team have no other assignments. The team did their own task assesment and costing. The team is strongly encouraged to be self-managing. Management has been a very hands-off spectator to the team.
Given that, when is the team accountable, and how do you hold them accountable?Anonymous
May 22, 2006
Doug posts a question about how you handle accountability in a Scrum world. If the team doesn't meet...Anonymous
May 22, 2006
Doug Seven wonders accountability issue with Scrum.  And yag wants to discuss this further.  If you read...Anonymous
May 22, 2006
The comment has been removedAnonymous
May 23, 2006
Betsy - Thank you for the comments. It definitely gives me some things to consider.
Let me ask a follwo up. If the team is failing, even though they have been given the resources they need, the time they need, and the protection from external impediments they needs, when is the team accountable? If the team has the training they need, and the proficiency they need, when are the accountable?
If a team functions poorly as a result of an inability to work together, is that the team's fault, the Scrum Master's fault, or the managements fault (for putting them together).
If the failure is the result of poor estimating by the individuals on the team, and poor communication about where they are at in their task, id that the Scrum Master's fault for not forcing the correct information out into the open, or the team's fault for not being transparent?
It seems that when you talk about Scrum, everyone runs to the defense of the Team. The Team can never be at fault. If the sprint failed to meet its goal, the Team is not at fault, it must be something else that caused the failure.
I am a believer in Scrum. I have always done Scrum-like development (even when we didn't know that is what it was). I will not give up on it. I do feel that there does need to come a time when the Scrum Team has to be held accountable for their successes and failures.
I am not looking to punish anyone, but I am trying to understand when the team needs to stand up and take accountability for thier actions.
If the Sprint has a goal (a Happy Path) to enable feature X. There may be additional features or tasks taken on if the time/resources allow it, with feature X being the priority - nothing else gets done until feature X is done. Then, the Sprint comes to an end, and feature X is incomplete. No impediments, no management interferance. Simply a team that didn't complete its goal. Maybe it was more work than was anticipated. Maybe the definition of the feature was porr causing churn. Maybe the UAT was poorly defined. Maybe lots of reasons.
Who is accountable for this? I say the Team is. As a whole. It seems I may stand alone though.Anonymous
May 23, 2006
I wouldn’t get too bent out of shape yet on assigning accountability, maybe give the team a couple of sprints to figure it out, likely they will. If there are some obvious repeat offences you may want to step in to correct some bad patterns. I’m no expert but some reasons I have seen agile development sprint failures:
First code check in 4 hours at 4 am before the first sprint is due
The late code check in simply not working
Inadequate resources (numbers and team dynamics)
A team is ramping up and trying to find the sweet spot around code quality and depth of test coverage
Discrepancies around how much documentation is needed by the team
Scrum team not attending stand ups
Development deciding to simply assign bugs to themselves and check in fixes when trying to lock down a sprint deliverable
Build failures not being addressed week after week by a resource that is not allocated to the project
Team members suddenly pretending they have forgotten how to ship software for some reason
Developers and their managers having fundamental differences of opinion on basic implementation decisions and how to implement functionality
Development managers not undestanding they have a stake in it projectAnonymous
May 23, 2006
Why is 'not completing all of tasks' in a sprint considered a failure? Especially if these are short sprint cycles and brand new team. It may take a few sprints to even get a good grasp of 1) what the team output is, 2) what is needed from each discipline in terms of (stories, exit criteria etc.) so that completing every task IS possible.
The benefit of working in the agile world is if an item is not completed during the sprint, it's a leftover and you may determine it now has a lower priority and no longer needed saving dev/test from burning wasted cycles.Anonymous
May 23, 2006
Getting people to be accountable is a four step process. Step 1: realize you have a problem. Step 2: As a manager, post to your Blog that your employees will likely see, scaring them into being accountable. Step 3: Apologize to your employees, letting them know you posted the comment not to intimidate them but instead to foster community discussion on the topic. Step 4: Realize posting something like this is not a responsible move.Anonymous
May 23, 2006
"There is nothing driving the team to prevent failure beyond their own pride. Is that enough?"
http://www.joelonsoftware.com/printerFriendly/articles/fog0000000070.html
<blockquote>Alfie Kohn, in a now-classic Harvard Business Review article, wrote:
... at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all. [HBR Sept/Oct 93]</blockquote>Anonymous
May 23, 2006
The comment has been removedAnonymous
May 23, 2006
Fire the non-performers. There is probably a history of them being non-performers for the last 2.5 years +.
Why suffer along with another project with resources that are incompetent?Anonymous
May 23, 2006
The comment has been removedAnonymous
May 24, 2006
The comment has been removedAnonymous
May 25, 2006
The comment has been removedAnonymous
May 30, 2006
Last summer, I was having a conversation with a friend who worked in Microsoft Research.&nbsp; I knew...Anonymous
May 30, 2006
I've done some Scrum training at Microsoft and management was forcing more work into the Scrum than the developers (and the managers) thought they could deliver because of a fixed price contract. Repeated failures in that case were a management problem, compounded by the developers being yes-men or yes-women.
I've done five Scrum companies which were totally Scrum and any bonuses were always team bonuses. If the team failed noone got a bonus.
In excellent Scrum teams, the team members work together to get the job done and do not tolerant non-performers. If they need help to remove them from the team they insist management do their job or that their manager be replaced.
One analogy I like (although not perfect) is that managers are like the owner of the baseball team. They hire, they fire, they set the pay scale, they get the customers to show up, and they keep the field clean. Otherwise, they stay out of the way. If the team loses too many games, they address the problem by getting a new coach, trading for better players, or whatever it takes. They also lose a lot of money when the team loses.
If the team is winning and the revenue flow is not what it should be, the product owner takes the hit.
In my experience, well run Scrums hold individuals to a much higher level of accountability than the traditional cube farm.
Jeff SutherlandAnonymous
May 31, 2006
from PM bootcamp "the process is the product".
if the team is accountable for shipping then it will. but if the lead is asking who needs to be accountable then a mirror is in order.
the leads own shipping. period.Anonymous
July 05, 2006
The comment has been removedAnonymous
July 17, 2006
I know that there a quite a few agilists at Microsoft.&nbsp; In my reading over the weekend, I saw this...Anonymous
July 18, 2006
Scrum process conveneiently ignores the most basic human instinct which the traditional soft ware development processes took care of i.e tendency to shift blame in the face of a failure. Every human being is different and the ability to endure adverse results varies from person to person. (as also courage to stand up and say something is not proper)
Scrum assumes the all members if team have equal abilties for the role.
The fact that someone blamed a failure on the lack on clarity of the stories (as mentioned in the one blog note here ) itself shows up the tendency to shift balme. Idealy, in this situation as per scrum rules the aspect of non clarity of stories should have been addressed first, by the team rather than completing it and then blaming. Here the team is is switching back to the old ways, i.e finding justification/reasons for 'why they could not achieve something' rather than finding ways to do something the it needs to be.
Under standing and impelemnting Scrum is not as easy and simple as it is painted to be. ( If all are equal then at hte end of the appriasla cycle the team will vanish into thin air)Anonymous
October 24, 2006
Last summer, I was having a conversation with a friend who worked in Microsoft Research. I knew him fromAnonymous
December 21, 2006
We (Dev + Test Team + Customer) decided to adopt agile for our project (Java/J2EE) web based project. We started by adopting agile on one pilot project. But it was kind of partial agile adoption. We have done it successfully and we got success and the confidence about agile adoption. Now we are planning to adopt agile at global level (for all sub projects around 8 per release). We got training for Scrum and XP. Now my main question is, what will be the chances of getting fail (at Sprint Level/Release Level) and who will be accountable for the failure? Can any one suggest me the guidelines/tips (actual real experience) to avoid or minimize the chances of failure on agile project.Anonymous
April 10, 2007
The comment has been removed