Loading ...
Sorry, an error occurred while loading the content.

611RE: [scrumdevelopment] Re: Alternative to EGroups + scrum in a "management" org

Expand Messages
  • Mike Cohn
    Oct 6, 2002
    • 0 Attachment
      Dan--
      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
      product.

      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.

      --Mike


      -----Original Message-----
      From: Dan Brown [mailto:kid_danomite@...]
      Sent: Sunday, October 06, 2002 7:42 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
      "management" org

      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
      customers.

      Thanks so much in advance for any advice anyone can pass my way.

      Dan


      --- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
      > It looks good to me but the Yahoo ads don't bother me very much
      because
      > 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:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Show all 29 messages in this topic