Doug Seven

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...

Doug posts a question about how you handle accountability in a Scrum world. If the team doesn't meet...

Doug Seven wonders accountability issue with Scrum.  And yag wants to discuss this further.  If you read...

This is one of the weirdest posts I've seen yet about scrum and Agile.

My understanding of Agile is that if you are involved in a failed sprint - even some sort of retrospective style meeting - you in some way share the accountability. So the first question I'd ask Doug would be (and maybe not for public but just to consider) : what role did you play in the team's effectiveness?

Were you product owner? Did you help shape the developer workload for each iteration? Were you the experienced  scrum master? (not sure from your post) Did you mentor devs in the scrum process? Were you "the management" who took resources from the project (which in that Agile book with Scrum is some sort of classic nono but seems to be a fact of life for many teams)?

If for some reason you ended up a non-active bystander,  but somehow watching the scrum process unfold badly, I'd ask questions like: did everyone use the daily standup to unblock, or did they hedge? Were the business goals clarified by the product owner at every step, so that every iteration of the software had a business outcome?  Who owned the work task backlog?

The scrum master -> product owner partnership is very deep - one builds the engine and the other provides the reason to drive. Did those two communicate?  Was it one person trying to be both roles (rather hard)? If people on the team don't know why or what the business outcomes, it's hard to polarize around your work items.

And finally, any project management process is limited by the capabilities of the team members. If your project is about writing something in C++ and all your people have is skills in something else,  dev magic will not happen because you scrummed. Hopefully you'd have a clearer picture of what went wrong than via other methods, or who needed C++ training, or who wasn't communicating with whom, but no method substitutes for folks who understand their jobs and each other.

In all the high performing teams I've been on, excellence has been enough of a spur for the team to both ship and ship well.  Often that's a personality type rather than a snazzy work method we were under - since scrum hadn't been invented yet for some of these teams. A good pm can create the atmosphere of achievement - and peer pressure can make it uncool to slack - but only the people can decide whether or not they are the type to rise to the occasion.  

My two cents, I am hoping you do not give up on scrum but instead go deeper into it. Good luck!

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 project

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.

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.

"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>

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?

I think I have finally put my finger on what was so  odd about Doug's initial postings about the team. The word accountability requires that you be accountable largely TO someone or something - giving an accounting means there is someone to check whether your figures added up.

In Agile, the product owner is the representative of the customer, and they are accountable to the team and to the customer.  The team shipping what the product owner identifies as important, as the customer advocate, is the marker of success. I'm guessing (but I don't know the situation) that for Doug to press for accountability, he was the product owner or at least close enough to that role to feel like he can judge the success or failure of the team.

The product owner keeps the team from building the Wrong Product. You could ship something but if it annoyed or drove away customers, shipping every sprint did you no good. So I guess in that case, not shipping a stinker is actually a victory. I don't know if that's what happened here, but if the team learned each iteration more of what was needed to build the Right Product, then you have not wasted resources or time. Ideally you ship something, sometime, but shipping the wrong thing is always a waste.

Now, that's the team as a whole learning about building a product. That's herd learning or whatever.

But each member of the team - dev, test, pm - represents a discipline. Usually, their manager - lead dev or dev manager, lead tester or test manager, lead pm or group pm - is the one who at Microsoft has the biggest responsibility for making them better *in their discipline.* While sometimes mentoring can happen cross-discipline, it's safe to say that the leads probably shoulder the biggest karmic duty to grow their people as better devs, testers, pms, etc.

If a dev (or test or pm) isn't a good communicator, that's a work skill they need and their manager should work with them on it. Pms 100 percent need that skill - it's one I work on every day. I also bug my manager for tips on it. Cost estimating for a dev or test person - critical skill. Only someone wiser in years and experience can assist them in learning how to do that, someone in their discipline.  The scrum master and rest of the team have to take their word on it.

I think the beauty of Agile and scrum is, not that it fixes people but that it shines a light where a team is weak, which is the first step to fixing things. It also polarizes around the customer in the body of the Product Owner, who really is the only person who can determine (outside of actual customers) what failure for the product is.  If that Product owner does not represent the customers, or does not communicate what the customers want via the product backlog or standups or what have you, it will be readily apparent in Agile because you ship something that fails in the market.

In Agile, by signing on as a team member you agree to support the customer and the Product Owner's vision of the product.  The team fails together but each person owns their contribution toward the team's effectiveness (or lack thereof) because only they can represent the disciplines and themselves as workers. To butcher the founding fathers, you hang together AND separately if you mess up in Agile. You don't become accountable - you start out that way.

Does that make sense?

From my point of view:

Each person should be held accountable for his or her responsibilities. Each manager is responsible to the ability of his or her charges.

Take it from a military point of view (16 years in the military and its the only way I can look at things):
Say I have a staff of 22 people to put out a newspaper every week, run a show on AFN radio every morning, supply video news feeds to AFN Germany and run a public affairs office.
My assistant editor, a buck sergeant is responsible for the newspaper, my Sr. Broadcast Journalist is in charge of the radio show, a staff sergeant is in charge of the public affairs office and its personnel with respect to the military and a 1st Lt. is in charge of community information.
If the newspaper misses deadline, the six Spec. 4/PFC/Pvt. journalists on its staff is not responsible and I'd not post anything anywhere saying as such. I'd be all over the assistant editor like snot on a six-year-old's sleeve wonder why the newspaper is not on the streets. It is the assistant editor's mission and mandate to make sure the deadline is met and if it isn't, it's his head being served up on my table, not his staff.
If the paper doesn't come out, the S-5 at division headquarters does not come in and chew out the the privates and specialists on the newspaper staff or the assistant editor, he comes in and chews out the Public Affairs Officer (who is my boss), who would in turn chew me out for not knowing why the paper missed the deadline or not doing anything about it. (Of course if the deadline were missed, I'd know because it is my job to know, but just for example's sake)  I chew out the asst. editor and he chews out his staff. If he can't get his staff to meet deadlines, he is ineffective and is replaced by some one who can. If I can't make sure the paper gets out on time, or that the news feeds to AFN Germany are not being done, or that the soldiers are missing PT every day, I am back to guarding motorpool buildings at three a.m. because I am not doing my job.

I think there are several things going on here, and it's important to handle them separately. I don't want to get ahead of myself, though, so:

First, one question I get from the original post is, "Is it true that there is no such thing as individual success with a team failure? How do you review the performance of an individual against the successes and failures of the team?"
Let me rephrase this question in a different context: a small software company. Is it true that there is no such thing as individual success when a company fails to ship a software release on time? How do you review the performance of an individual against the successes and failures of the company?
*Of course* individual performance varies in a small company. The development team can do a great job, and if your sales team fails in its tasks, the entire company can go bankrupt. And vice versa. If your sales team is off playing golf instead of selling software, would you fire the slacking sales team and the excellent development team? You won't be in business long if you work like that. Why would a Scrum team be any different? If you have six great team members, and two dirtbags, either you fire the two dirtbags, or you start looking for six new team members to replace the six that will find new jobs after they get tired of carrying the dirtbags.

Secondly, it's important to identify exactly what you're hoping to get from the answer you're seeking. What does it mean TO YOU to "be accountable"? If the God of Scrum stoops down and answers you in this thread, saying "YES, YOU CAN HOLD YOUR TEAM ACCOUNTABLE NOW," what are you going to do? Are you looking for a way to justify rating someone positively on their review even though the team is missing sprint goals? Are you looking to rate someone negatively on their review? Do you want to fire someone? Do you want to take away the team's cookies? Do you feel that team members are displacing "blame" for missing sprint goals on external factors, when you really feel that it's because the team is not working hard enough? Or are you just looking for someone to say "Yes, sorry, it's all my fault"? What is the impediment to achieving the *real* goal behind these questions, and what do you have to do to remove that impediment? Is validation from a bunch of strangers really going to remove whatever the obstacle is that's holding you back from your goal?

Thirdly, I usually find that it's not very worthwhile to find out who is to blame for something. I think it's much more useful to find out what I need to do to move things in the direction I want them to go. If you want to start meeting sprint goals, instead of trying to assign blame for missing them, find out every single thing that is contributing to missing the goals. Obviously there is too much work. Is this because acceptance criteria are not being defined well enough? Are people estimating poorly? Is testing holding things up? Are developers not testing enough? Is everyone on the team working only six hours a day, when you've estimated based on eight hours a day? When you figure out what it is that's causing you to miss your goals, then you have the answer to what you need to do to make your goals.
As an example, if the root cause of missing your sprint goals is poor estimation, then get training for your developers. Start tracking metrics so you have some data on which to base estimates. Start making blog posts asking how to estimate more accurately. Run some estimation exercises or workshops for the team. Do team estimates, and compare those to individual estimates, and compare them to how long tasks really take, and figure out what is causing errors, and adjust in future estimates. If your root cause is poor estimates, and you're unhappy because the team is blaming their estimation failures on the product owner / the weather / management, then sit down with the team and SHOW them why you think estimates are the problem -- show them the initial estimates for the tasks, and how long they really took, and how much that threw off the schedule. Challenge them to show you similar data on whatever their favorite cause for failure is.

Really, to me, it sounds like you're unhappy that people on the team are refusing to take responsibility for having missed sprint goals. I may be entirely wrong (and probably am...hard to pick up subtleties online). Frankly, from what you wrote in the initial post and your first comment, I would say it's way too early to adjudge failures. Mistakes were made, you've identified at least some of them in retrospectives, and you're adjusting based on those mistakes. The team is recognizing issues (e.g. poor exit criteria) and changing things based on those issues. IMO you're too early to even have an accurate picture of your team's expected velocity.
If you're looking for a definitive answer as to when you can approach someone for their individual poor performance, I don't think you'll find one. It's *always* an individual situation. If Joe Dev hits the beach for 20 days of the first sprint, you can justifiably fire him during the first sprint. If Sue Tester gets in a car accident on your 19th sprint, and you miss your goals because of it, you can't reasonably downrate her for that. Again, I think it all comes down to "Why do you want to know, and what will you do once you do know?"

Last summer, I was having a conversation with a friend who worked in Microsoft Research.&amp;nbsp; I knew...

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 Sutherland

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.

In my project "Scrum Team Failed" due to following reason:

1. Team ("Team" and not few members of the team) did not define the Priority (1. Must Have, 2.Required,  3.If possible...)

2. If they did define the priority, they did not work on it as a team, they worked on different set of priorities.  IMHO, its the job of PM/Scrum Master to ensure team works on the Priority Items than random item.

3. As an outsider (QA Person), I was surprised to see that Scrum Master said nothing to team member (only 1 person in particular) for why he was not working on Pri-1 item(s) than working on something which had no ROI (if not done) whereas not working on the item which was most important

4. If an item does not progress (i'm referring to Daily Burn-Down) that should start to smell.  That's the time when Scrum Master should jump-in to make sure team does not need more help.

5. Last but not least, Scrum Master be pro-active.  People usually have habit of giving excuses.  One of my team member gave me an excuse saying "I wish I had 64-bit machine, I could have produced the output more faster", duh, what a lame excuse.  After providing the machine that output did not increase even a little.  These kinds of things should be watched for....

In short, team should focus on Sprint Goals rather than anything else.

I know that there a quite a few agilists at Microsoft.&amp;nbsp; In my reading over the weekend, I saw this...

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)

Last summer, I was having a conversation with a friend who worked in Microsoft Research. I knew him from

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.

If everyone is responsible then no one is responsible.  

Who wants the ball with 2 seconds left on the clock?  Anyone?  Anyone?

In short, no one is willing to accept responsibility these days because if they fail and are held accountable, their feelings will be hurt.

The Chinese and Indians are going to kick our butts.