I just got back from a workshop on agile processes at OOPSLA2001, where our
conversations included your questions.
1. The backlog needs to be kept simple, so that the customer can assess the
business value of each item by a one or two line description. As a backlog
item becomes higher priority (more likely to be developed in a nearby
Sprint) it's description becomes more and more defined, also supporting more
and more refined estimates. Most project managers and product managers have
lists or Excel spreadsheets that describe "what the system will consist of."
The product backlog subsumes these lists.
2. We spend a lot of the book presenting case studies. Scrum and all of the
agile processes feel immensely different to people starting to employ them,
and they often have trouble believing that they won't spin out of control.
Scrum provides real predictability, as compared to the artificial comfort of
a pert chart, but it take people a while to get use to it. Scrum also
requires collaboration between the business and development team, with the
customer "hands on" driving the project every iteration, or Sprint. This,
too, takes a while to get used to. Customers and team members that dislike
personal accountability are profoundly comfortable with Scrum.
3. A question we asked at the workshop: "When shouldn't you use an Agile
process?". In theory, nowhere we can think of. In practicality, I've run
into the following:
a. The team had such an inadequate development environment and understanding
of basic software engineering principles that we delivered very little
business value the first three Sprints. The customer quite correctly
defunded the project because he felt that the team couldn't do the job. This
was a project failure, but a Scrum success. Scrum made the team's
inadequacies fully visibile to the customer and let him make relevant
b. The project manager was a control freak and couldn't resist telling team
members what to do during the Sprint, going so far as to maintain the Sprint
backlog as a pert chart. He completely undermined self-organization and
hindered the team from meeting its committments to the Sprint goal. We had
to replace the project manager.
Each of these cases failed, but Scrum provided early visibility into the
cause of the failure. The projects would have failed no matter what process
was used, but at least Scrum helped the organization minimize the damages
Since Scrum is a wrapper for any engineering processes, we've been able to
use it for any number of seemingly inappropriate projects, such a
coordinating executive decision making for a business, Y2K release
management and implementation control, and technology selection projects.
Sent: Monday, October 15, 2001 11:47 AM
Subject: [scrumdevelopment] Misc questions
Now I am done with the report about Scrum. It has been really
interesting to study Scrum. Scrum really have many interesting parts
and aspects, I must say. So I've ordered the book to see if there are
more juicy parts of Scrum :-)
Thanks Ken Schwaber for your terrific answers!
But I have hard dropping the issue so I will continue with my
* Doesn't the backlog become very complex? Is there any possibility
to see how such a "real" backlog is contructed?
* Where is the critique against Scrum? Everything can't be perfect...
* In the faq on www.controlchaos.com the third question is about
failured projects using Scrum. Is there any why of getting
information about these failures? It would be very interesting!
Thanks in advance,
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/