26156Re: Break down product backlog problem
- Jan 3, 2008Ah, yes, it seems he is "ferally tied to the tyranny of the
waterfall." It is an all-too-familiar scene with few painless
options or remedies. Well, other than taking him off the project
and putting a CSM on it, there are few choices. The real suffering
party here, I bet, is the team. Talk about confusing for them!!
In fairness to the PM, he should at least be encouraged and provided
the opportunity to attend CSM training asap, or otherwise be honest
with himself and you if he concludes he won't or doesn't want to
accept Scrum. I know of several companies where managers left after
Scrum was adopted because they simply had no desire to give up
positional authority in a command and control environment and try to
change to lead in a self-directed team environment. John Chambers,
CEO of Cisco, said that 15 to 20% of his leadership team "left"
after the company moved to that environment. It isn't for everyone.
One thing for sure, no one person should be allowed to impact a
project or team detrimentally to the point where their behavior
places the project at risk.
--- In firstname.lastname@example.org, <leo.ren@...> wrote:
> Hi Tom
> you are right. this PM is not a scrum master. even more, he
doesn't know agile.
> I know this is the problem of our organization, but that's fact. I
have to face. acctually,
> he uses waterfall thinking because he is familiar with that .I
will try to find another
> way to solve this problem. thanks.
> Best Regards
> Leo Ren
> From: email@example.com
[mailto:firstname.lastname@example.org] On Behalf Of ext Tom Mellor
> Sent: 2008Ç¯1·î3Æü 23:33
> To: email@example.com
> Subject: [scrumdevelopment] Re: Break down product backlog problem
> Leo - you have encountered an issue that isn't unheard of, for
sure. First, you refer to the other person as the "project
manager." Is this person actually the ScrumMaster (and has he or
she been trained as a Certified ScrumMaster?) This is important,
because if so, then he/she would understand the rationale for
keeping Sprints a constant duration and receptive to your suggestion
of breaking the feature down.
> Not all work is suited for completing it within a Sprint - it
would be great if it fit so nicely, but there can be technical work
that spans two Sprints. Ideally, the goal is to try to develop
features and other technical requirements to a state of agreed done
within an iteration. If some work cannot be accomplished in that
timeframe, then the team needs to figure out how to best break it
up (decompose it.) The "PM" may not think it has value, but in the
self-organized, self-directed team environment of Scrum, his opinion
is simply one of several and the decision is not solely his/hers.
> In firstname.lastname@example.org, <leo.ren@> wrote:
> I encounter a problem when I convince one project manager when we
break down product backlog. There is a feature, which can not be
finished in one sprint, I suggest to break it down and finish them
within two sprints. But the PM doesn't agree with me, he thinks
it's no value to do so. And he thinks we can re-schedule this
special sprint to twice of one normal sprint duration. I think it's
not good. We should keep the duration of one sprint to be same.
But I can not convince him. Can anybody help me? Or I'm wrong?
- << Previous post in topic Next post in topic >>