All About Agile | Agile Development Made Easy!
Trust, Commitment and Accountability
One Agile Coach suggested to me that he would 'hold the team at gun point' if in a particular sprint the team seems not delivering its commitment! How do you manage accountability of an Agile Team and the Scrum Master? Is Scrum Master or Agile Coach accountable for team? What does trust and commitment mean to an agile project?
Tags: Accountability, Agile, Coach, Commitment, Trust
Views: 193
Replies to This Discussion
-
Permalink Reply by Ilja Preuß on -
I think the Scrum Guide is pretty clear on this: a team commits to a Sprint Goal, which is kinda like a small version of a mission statement, like "allow customers to manage whishlists". The Sprint Backlog is there plan on how to deliver on that commitment. Let me reiterate: the team doesn't commit to the Sprint Backlog, it commits to the goal that the backlog is supposed to come up to.
When the team finds out that they cannot complete all the stuff in the backlog, they reconvene with the PO to reshape the backlog, so that they are again able to reach the goal they committed to. If that proves to be impossible, the sprint is terminated.
Now, if a team regularly doesn't reach the Sprint Goal, but doesn't escalate before the end of the sprint, some escalation by the SM/Coach might be asked for. Otherwise, certainly no guns involved, in my not so humble opinion.
-
Permalink Reply by Duncan Campbell on -
But what is the Sprint Goal? "Complete the next slice of requirements from the top of the product backlog to deliver the highest business value to the customer."?
It's not easy for every sprint to have a unifying theme.
The other part of commitment is that the team must do its level best to fulfill that commitment. The point of the team making the commitment is that they are more motivated to satisfy the commitment - they have a stake, rather than following someone else's estimation and milestones.
Though Scrum does tend to assume that all team members are highly motivated and sufficiently capable....
-
Permalink Reply by Ilja Preuß on
-
"It's not easy for every sprint to have a unifying theme."
Who did say software development was easy?
"The point of the team making the commitment is that they are more motivated to satisfy the commitment - they have a stake, rather than following someone else's estimation and milestones."
I don't agree that it's *the* point. Anyway, "holding them at gun point" is neither going to improve their motivation, nor likely to increase their commitment in future iterations.
The right solution to a not highly motivated team is to work on their motivation. The right solution to a not sufficiently capable team is working on the capability of the team. "Holding the team at gun point" is not a good alternative, as far as I can tell.
-
Permalink Reply by Duncan Campbell on
-
The solutions to motivated and capable teams also include giving the less motivated and capable members the opportunity to find teams and environments which do suit their levels of motivation and capability.
-
Permalink Reply by Ilja Preuß on
-
Motivation is much less a function of an individual, than of the system they are part of. Letting an employee find a different place that better motivates him might be much more costly than changing his current environment so that it is motivating to him.
And putting people in a position where they are not well equipped to live up to expectations is a management problem, in the first place.
-
Permalink Reply by Phlip on -
uh, I was reading the http://www.agile-community.com/forum/topics/bdd-tdd-acceptance-test... thread and clicked on this one! Sorry! C-:
-
Permalink Reply by Manish Manekar on -
The Scrum Guide states as follows:
"If the Team senses that it has overcommitted, it meets with the Product Owner to remove or reduce the scope of Product Backlog selected for the Sprint. If the Team senses that it may have extra time, it can work with the Product Owner to select additional Product Backlog."
"The ScrumMaster works with the customers and management to identify and instantiate a Product Owner. The ScrumMaster teaches the Product Owner how to do his or her job. Product Owners are expected to know how to manage to optimize value using Scrum. If they don’t, we hold the ScrumMaster accountable."
... this - to some extent - answers my question partially. The conflict, to me, seems to be between business expectations and Agile values. What do you think?
-
Permalink Reply by Ilja Preuß on
-
What are the "business expectations" that you see in conflict with Agile values?
-
Permalink Reply by Manish Manekar on
-
The "business expectations" I'm referring are where top management expects from engineering team to get the product out with a set of features and the date declared at the beginning of release. They care less about the engineering team following Agile, may be since they on their own and their business model is not Agile enough. Or in other words they don't see the benefits of iterative incremental development.
I am seeing this pattern quite often and the team managers aka Agile Coach are under pressure to use old tactics ('hold the team at gun point') of getting work done.
-
Permalink Reply by Ilja Preuß on
-
Where do those expectations come from? Did those old tactics ever work?
-
Permalink Reply by Manish Manekar on
-
Well, those are the expectations coming from top management. And either they believe the old tactics work for them or they don't accept it did not. In any case I see this as a conflict with Agile implementation.
The options I can think of are: 1. Transform the organization from top to adopt Agile or 2. Keep Agile away until there exist environment that is conducive.
-
Permalink Reply by Ilja Preuß on
-
How detailed is the definition of the "set of features" at the beginning of the project?
© 2012 Created by Kelly Waters.
