RE: [scrumdevelopment] Re: Planning vs. Predicting (was Agile Development: Reforming Project Management)
- I totally agree. Your approach below is perfect, Jeff. Any more detailed
measurement of the process starts to alter the process.
Once CEOs and Boards start to see how Scrum and the believable reporting
that comes out of it they become its biggest fans.
From: Jeff Sutherland [mailto:jeff.sutherland@...]
Sent: Wednesday, October 16, 2002 9:08 AM
Subject: [scrumdevelopment] Re: Planning vs. Predicting (was Agile
Development: Reforming Project Management)
The purpose of the first SCRUM was not to measure managers or
developers. I asked the CEO of Easel if he had ever seen a plan that
he liked, had confidence in, or was met on time in the software
business. He said, "NO!" I said if he could see real software running
once a month that could be shown to users, would that give him more
confidence that we were going to have a product that we could sell in
a reasonable amount of time.
When he said, "Yes," I said he would have to give up all management
controls on the SCRUM and let it self manage. Product marketing would
build a product backlog, we would select high priority items for a
Sprint. There would be no management interference during the Sprint.
At the end of the Sprint, if management didn't like the software or
the progress, they could change everything at Sprint boundaries.
He agreed. The rest is history.
So I think the only thing that should be measured is the size of the
Sprint backlog, the rate of burndown of the burndown chart, and the
value of the demonstrable working software at the end of the Sprint.
Anything more generates more work for people who are not writing code
and builds beaurocracy that gets in the way of building better
That said, my Board needs a product roadmap and dates of delivery. We
prepare them as targets. Sometimes GANT charts are use to depict
these targets. They have no concrete reality until a burndown chart
is visible. We then report off the burndown charts showing clearly
where the customers and/or product marketing stuffed more
functionality into the release, where items were deferred to drive
toward a date, or where development stumbled on a technical problem.
The microdata that builds the burndown chart on each piece of
functionality with estimates and dates give more information than any
other scheme I have seen on team or individual output at the micro
level. We do not use these data as measures for managers as it would
distort estimates and corrupt the data.
--- In scrumdevelopment@y..., "Mary Poppendieck" <mary@p...> wrote:
> I hear the term 'plan-based approaches' used as a pejorative, and I
> think we are using the wrong term. There is nothing wrong with
> planning. Planning goes wrong when it focuses on predicting how
> will unfold and spelling out the responses to that prediction.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to