Re: Sprint Burndown Chart
- --- In email@example.com, "Ilja Preuss" <preuss@...> wrote:
>Probably nothing once you have established mutual trust. But excess scrutiny during the
> > The product owner should judge according to what is
> > delivered at the Sprint Review Meeting rather than
> > what transpires during the Sprint.
> What is wrong with the product owner caring about what happens during the
> Curious, Ilja
sprint can inhibit the team's self-organization when the product owner and team are
trying to break a cycle of micromanagement and intimidation. We once had to ask a P.O.
(who happened to be everyone's boss) to give his teams more privacy during Sprint
execution. His mere presence was a distraction to government employees who were used
to being treated like kindergarteners.
I know this sounds like it goes against "visibility" but it's what that situation called for.
The developers had *less* visibility into each other's thoughts when they were concerned
about looking good for their boss.
As discussed earlier, we sometimes see ScrumWorks users whose Sprint Burndown Charts
go down in a perfect straight line. This suggests to me people are more concerned with
looking good for someone than reestimating honestly. If they know their performance will
be assessed by what their team actually delivers they'll be more comfortable giving honest
estimates to facilitate team self organization.
> I think it's important to recognize that the commitment inI'm not a Scrum expert, so I'm not sure what Scrum is saying about it.
> scrum is two-way. The team commits to achieving the goals by
> the end of the sprint, and the Product Owner commits to not
> interfering with how the team goes about achieving those
> goals or introducing change within the sprint. Each of those
> commitments is built on trust; the PO must trust that the
> team will do the best they can possibly do under the
> circumstances to achieve the goals, and the team must trust
> that the PO will not change the goals during the sprint.
> High-bandwith communication and visibility is extremely
> important, however I think that sometimes communication can
> morph into coercion if trust is not established, and when
> that happens trust only erodes further. The scrum master's
> duty is to facilitate the communication between the team and
> the stakeholders so that well-intentioned communication does
> not devolve into coercion and distrust.
From my point of view, though, I certainly agree that it's not good if the
product owner *interfers* with the work of the developers. On the other
hand, he has information that the developers would be well adviced to listen
to not only at the start and the end of the sprint. And he has expectations
that are better aligned with what the team can deliver more often than once
every three weeks.
So I'd want the whole team to work on communicating *continouosly* in a
non-"interfering", productive way.
Perhaps there are situations where this is best achieved by reducing the
amount of communication for a while. I just don't think it is a good idea to
use this as a permanent solution, or the default behaviour of a team.