611RE: [scrumdevelopment] Re: Alternative to EGroups + scrum in a "management" org
- Oct 6, 2002Dan--
One of the nice things with Scrum is that it is very applicable at
organizational levels above where the software happens. When I've sold
Scrum to directors, VPs, CEOs, etc., the approach I take is
1)describe the problem(s) they are currently facing and get their
agreement that I really know the problems. You can probably do this with
some variation of "Our products are generally well received and have
acceptable defect levels but customers are constantly pushing for faster
deliveries" or "We meet our dates but we always end up cutting some
(many?) of the features we've previously told people we'll have in the
2) I don't really go into Scrum and what it's all about. I use the name
"Scrum" but I don't say, "we're going to make this group agile etc...".
Rather, I just describe an approach--stress that you're doing the
project in one month increments and that during that one month the
developers commit to completing everything they sign up for and that you
want the business to commit to not changing things (that doesn't sound
like a problem in your case). Describe how you'll meet at the start of
the month to create the "sprint backlog" and how the marketing person (a
"product manager" or in Scrum terms the "Product Owner") completely owns
the prioritization but that the team will draw a line under the tasks
they can commit to. Tell the person you're selling about the "daily
scrum" meetings and tell him how he can attend any of these he wants but
that he's a chicken and will be there just to observe.
3) Explain how the Product Owner can call "Release!" whenever he or she
wants following a sprint. Tell him how any estimates you give decrease
in accuracy quickly beyond one or two sprints into the future. Negotiate
that estimates from you will be in the number of sprints (months) it
will take to do the project. I'll typically say something like, "Based
on my understanding of the features needed before we can sell the new
version, I estimate this project will take 3-5 sprints (months) before
it will releasable. We'll be at the 3 end if we opt to release near the
low end of what the Product Owner says is needed and if things go well;
we'll be at the 5 if we're at the high end of that or if we have some
problems or turnover, etc. Most importantly, we'll be able to make that
decision on a month-to-month basis."
4) Go over some of the economics (not really the dollars, though) of
what you're proposing. For example, a point that Ken taught me is how
really low the opportunity cost for Scrum is. What is the absolute worst
case of trying Scrum for 30 days? Scrum can be implemented in a day and
without any tool costs or dramatic changes in engineering practices
(some changes are usually appropriate, especially incorporating some of
the good ideas from XP but they aren't necessary right off). In an
absolutely disastrous situation the team would have gone off and coded
for 30 days and produced something that the organization doesn't want.
Even if you find Scrum doesn't work for some reason then you switch back
after 30 days.
5) Scrum really takes off when you get the whole company thinking Scrum.
I'm working with an organization right now and we're moving Scrum up
from the engineers to a process we use for allocating resources across
the company. This is a really small company (20 people) but they have
dozens of commercial products and so we're starting to introduce a
higher level set of Scrum activities to decide where programmers should
spend their time. I haven't tried this yet (but I will within two weeks)
but I am really intrigued with using Real Option Valuation (an
alternative to simple ROI calculations) in these management Scrums.
In terms of expanding Scrum beyond development so that it includes all
of the other product deliverables: There's really no secret there--just
put those items on the product backlog and then move them into
appropriate sprint backlogs. On most products this feels a bit weird but
it's still worth doing. What I mean by that is you put tasks on the
backlog of "write user's guide" and like Scrum says you don't really
assign that to a particular person. Well, if you've only got one tech
writer it's pretty obvious who will do the work. It's the same case with
"design packaging" and "write marketing collateral" and "place ads" etc.
All those activities are not ones a programmer is likely to pull off a
sprint backlog list. Anyway, I do track them on the sprint backlog
because it helps me get a good overall view of the project AND many of
these activities do spinoff engineering tasks--e.g., proofreading
sections of the manual, etc. Those tasks can be handled just like coding
tasks so they should be tracked that way. Also, this helps make sure
that these tasks aren't forgotten when the programmers plan how much
they can get done. One thing I do when I'm tracking these types of
activities--I'll typically leave them out of my sprint burndown charts
(so the burndown chart is just the "true" engineering tasks (including
test)), or I may show the burndown with and without them, depending on
the project. The burndown charts are most useful when there's a lot of
uncertainty in tasks. For example, most tech writers end up having their
work very timeboxed such that they know they have 3 days on chapter 1
and 5 on chapter 2. Those types of tasks burn down at predictable rates
so they mask real trends in the burndown chart.
Yes, use your marketing team or ideally a single "Product Manager" in
that group as your customer. I've done plenty of commercial software
w/Scrum and always use that type of person. I've had people suggest I
use a "customer advisory team" but I've always been in too big of a
hurry for that and trust the Product Manager to invoke such a team on
the occasional item where it's necessary.
Good luck and post some progress reports to this group. I'm sure I'm not
the only one who would like to hear how it goes.
From: Dan Brown [mailto:kid_danomite@...]
Sent: Sunday, October 06, 2002 7:42 PM
Subject: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
I assume everyone in the list followed this comment, but it is worth
repeating. Yahoo Groups has a nice digest feature; no advertisements
(except for the people who SP~M the group), and the one daily e-mail
makes for a quick read to scan for what is interesting.
As the saying goes, "and now for something completely different."
I would love to get feedback from those with some experience in a
management-centric environment on how to get some traction with
Agile. Here's the current situation: I've introduced a slight
variation of scrum that is only within our development group (we are
basically handed a product backlog that does not change at the
beginning of development). While scrum is not quite ubiquitous on
teams, it is fairly well received within development, but there are a
couple challenges to becoming truly agile.
First, as I mentioned, we tend to be a management-centric group, so
it's been a challenge for the leadership to let go of the reigns a
bit and also for a lot of the development team to grab on and drive.
Second, we deliver to external customers, so our marketing team, I
think, would be our closest proxy for "the customer" but I haven't
yet successfully engaged them in the process. Finally, if we can
successfully engage the rest of the business, I need a better
understanding of how we expand the scope from software deliveries at
the end of each sprint, to a complete product delivery that is ready
for manufacture, sale, and service when we launch to external
Thanks so much in advance for any advice anyone can pass my way.
--- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
> It looks good to me but the Yahoo ads don't bother me very much
> I use email rather than the web for this group.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to
- << Previous post in topic Next post in topic >>