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

217Re: Splinter Department

Expand Messages
  • mpoppendieck
    Feb 9, 2002
    • 0 Attachment
      I like your idea of Friday afternoon slack time. On the other hand,
      as you noted, not everyone has something they want to pursue during
      such time. That's why at 3M it is 'allowable' to charge 'up to' 15%
      of your time on something outside your regular assignment. In
      actual practice, at any given time, only a few people actually do
      this. So if slack time is scheduled for everyone, you may loose
      more time than you can afford.

      I am reading between the lines a possible assumption that everyone
      must work the same hours as everyone else on the team. Is this
      considered necessary? Is there a problem with someone taking the
      odd afternoon off to do something else, or leaving for an unrelated
      meeting here and there? Is there a problem with someone coming in
      at 7 and leaving at 4, while someone else comes in at 10 and leaves
      at 7 (both on a regular basis)?


      --- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
      > I've dealt with this two ways in the past:
      > 1) allowing teams to take every Friday afternoon for use in
      > pursuing any company they want *except* work on the main project to
      > which they are assigned (whether Scrum-managed or not). This works
      well
      > because it gives each person about 10% of their time to spend on
      any
      > wild ideas they want. I've had individuals use this time for
      reading,
      > for learning new languages, for "study groups" to go over important
      > books in detail, to write magazine articles, etc. I don't allow
      people
      > to use the time to work on items in the current sprint backlog
      because
      > sometimes that leads to peer pressure that forces others to work
      on the
      > backlog.
      > 2) There is almost always some "friction" or slow time
      between
      > sprints at some point on a project. In a typically well-run project
      > there might be 3 - 4 sprints that can follow one right after
      another but
      > usually after that you hit a period where somebody isn't really
      ready
      > for a new round of sprints (or they're barely ready). A lot of
      times
      > this will be the product management group (or whatever group in an
      > organization defines the backlog/requirements). They may need to
      go do
      > research with customers (that should have been done sooner) or
      such and
      > there is a period where the team just doesn't need to go full
      speed on
      > the project. This is a great time to encourage people to get
      creative
      > with how they spend their time.
      >
      > Also, a fairly relevant question in all of this is whether most
      > developers (programmers and otherwise) will come up with "new
      products"
      > when left to their own devices for 15% of their time. It sounds
      like a
      > small percentage of time but it's not really and I'm not really
      sure it
      > pays off to the benefits of a business to have every employee
      spend that
      > much time "away" from mainline work.
      >
      > In terms of just plain including slack in a schedule, that is very
      much
      > a necessity but it's different from telling people to spend 15% of
      their
      > time on whatever they want. Every team is of course different so
      > percentages are somewhat meaningless but I typically encourage a
      team to
      > target around 60-70% occupied when they move items into a sprint
      > backlog. So: if the sprint is 20 days * 8 hours that is 160 hours.
      I'll
      > encourage teams to pull in about 100 hours each of identified
      backlog.
      > The rest is spent on whatever else takes up that team's day
      (meetings,
      > email, washing my car, etc.) but it also puts them into a mode
      right off
      > where there isn't undue pressure that leads to shortcuts. This is
      > different from commitment to the project, though. The team is
      expected
      > to be committed to the project 100% but slack is allowed in their
      > schedules because they are all trusted to know how best to spend
      that
      > time. DeMarco's latest book, "Slack" appropriately enough, is
      pretty
      > good on the subject but gets pretty repetitious by the end.
      >
      > --Mike
      >
    • Show all 29 messages in this topic