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

Splinter Department

Expand Messages
  • Jonas Bengtsson
    Hi, I ve just read Exploiting Chaos: Cashing in on the Realities of Software Development by Dave Olson. In his book he proposes a splinter department . This
    Message 1 of 29 , Feb 4, 2002
    • 0 Attachment
      Hi,
      I've just read "Exploiting Chaos: Cashing in on the Realities of Software
      Development" by Dave Olson. In his book he proposes a "splinter department".
      This department is a place where very uncertain ideas can be tested, a
      nursery for new ideas. For instance, if a person gets a bright idea he can,
      with the management's approval, go to the splinter department for a couple
      of months and experimenting with the idea. If the experiments turn out good
      he might start a pilot project and so forth.

      The main reason for this department is that some ideas are too risky to
      explore inside a project and that some ideas are distractions from the main
      goal of a project.

      Is there a need for such a department in a Scrum "environment"?

      Regards,
      Jonas
    • Mike Beedle
      ... Jonas: I am familiar with the book. I read it in the mid-90s. Scrum uses a more reengineered approach, a Case Team, in Hammer s terminology. A Case Team,
      Message 2 of 29 , Feb 4, 2002
      • 0 Attachment
        Jonas Bengtsson wrote:
        > Hi,
        > I've just read "Exploiting Chaos: Cashing in
        > on the Realities of Software Development" by
        > Dave Olson. In his book he proposes a
        > "splinter department". This department is a place
        > where very uncertain ideas can be tested, a
        > nursery for new ideas. For instance, if a person
        > gets a bright idea he can, with the management's
        > approval, go to the splinter department for a couple
        > of months and experimenting with the idea. If the
        > experiments turn out good he might start a pilot
        > project and so forth.
        >
        > The main reason for this department is that
        > some ideas are too risky to explore inside a
        > project and that some ideas are distractions
        > from the main goal of a project.
        >
        > Is there a need for such a department in a Scrum
        > "environment"?

        Jonas:

        I am familiar with the book. I read it in the mid-90s.

        Scrum uses a more reengineered approach, a Case Team,
        in Hammer's terminology. A Case Team, by definition,
        avoids hand-offs among teams, that require iteration
        and rework among different teams, because those are
        exactly the reasons why things get slowed down:

        1) you need managers to talk and agree to do work
        2) you need workers to take instructions from
        managers/team leaders
        3) you need workers to report to management what
        is going on, and
        4) managers to report to each other on progress,
        etc.
        (All the bureaucratic stuff that is undesirable and
        slows things down, albeit, some of it is always
        unavoidable.)

        Instead in Scrum, new ideas are tried from within
        the team, that is iteration and rework, if any,
        stays within a single team. Experiments or prototypes
        are labeled as such in the Product Backlog.
        And they are implemented when they are allocated
        to the Sprint Backlog within a Sprint. Progress
        is reported through the Daily Scrums and the
        decision to continue or to stop with the "experiment"
        is evaluated daily.

        In other words, Scrum mechanisms treat experiments
        like any other task. In that sense, Scrum techniques
        are universal i.e. they work for _any_ kind of
        work that the team needs to accomplish,

        - Mike
      • Jonas Bengtsson
        Thanks for your answer! It seems more reasonable to handle it (experiments/prototypes) within the team. And if people run away all the time, from the team, to
        Message 3 of 29 , Feb 4, 2002
        • 0 Attachment
          Thanks for your answer!

          It seems more reasonable to handle it (experiments/prototypes) within the
          team. And if people run away all the time, from the team, to do experiments
          I suspect the team will have a harder time to jell.

          Regards,
          Jonas

          > -----Original Message-----
          > From: Mike Beedle [mailto:beedlem@...]
          > Sent: Monday, February 04, 2002 4:51 PM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: RE: [scrumdevelopment] Splinter Department
          >
          >
          > Jonas Bengtsson wrote:
          > > Hi,
          > > I've just read "Exploiting Chaos: Cashing in
          > > on the Realities of Software Development" by
          > > Dave Olson. In his book he proposes a
          > > "splinter department". This department is a place
          > > where very uncertain ideas can be tested, a
          > > nursery for new ideas. For instance, if a person
          > > gets a bright idea he can, with the management's
          > > approval, go to the splinter department for a couple
          > > of months and experimenting with the idea. If the
          > > experiments turn out good he might start a pilot
          > > project and so forth.
          > >
          > > The main reason for this department is that
          > > some ideas are too risky to explore inside a
          > > project and that some ideas are distractions
          > > from the main goal of a project.
          > >
          > > Is there a need for such a department in a Scrum
          > > "environment"?
          >
          > Jonas:
          >
          > I am familiar with the book. I read it in the mid-90s.
          >
          > Scrum uses a more reengineered approach, a Case Team,
          > in Hammer's terminology. A Case Team, by definition,
          > avoids hand-offs among teams, that require iteration
          > and rework among different teams, because those are
          > exactly the reasons why things get slowed down:
          >
          > 1) you need managers to talk and agree to do work
          > 2) you need workers to take instructions from
          > managers/team leaders
          > 3) you need workers to report to management what
          > is going on, and
          > 4) managers to report to each other on progress,
          > etc.
          > (All the bureaucratic stuff that is undesirable and
          > slows things down, albeit, some of it is always
          > unavoidable.)
          >
          > Instead in Scrum, new ideas are tried from within
          > the team, that is iteration and rework, if any,
          > stays within a single team. Experiments or prototypes
          > are labeled as such in the Product Backlog.
          > And they are implemented when they are allocated
          > to the Sprint Backlog within a Sprint. Progress
          > is reported through the Daily Scrums and the
          > decision to continue or to stop with the "experiment"
          > is evaluated daily.
          >
          > In other words, Scrum mechanisms treat experiments
          > like any other task. In that sense, Scrum techniques
          > are universal i.e. they work for _any_ kind of
          > work that the team needs to accomplish,
          >
          > - Mike
          >
          > 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 the Yahoo! Terms of Service.
        • vze2k2j6@verizon.net
          I d say so if the technology is so whacked, bleeding edge, or untested that someone needs to first evaluate it. Wireless used to fit into that category, and in
          Message 4 of 29 , Feb 4, 2002
          • 0 Attachment
            I'd say so if the technology is so whacked, bleeding edge, or untested that someone needs to first evaluate it. Wireless used to fit into that category, and in some cases still does.
            Ken
            >
            > From: "Jonas Bengtsson" <jonas.b@...>
            > Date: 2002/02/04 Mon AM 09:35:23 CST
            > To: <scrumdevelopment@yahoogroups.com>
            > Subject: [scrumdevelopment] Splinter Department
            >
            > Hi,
            > I've just read "Exploiting Chaos: Cashing in on the Realities of Software
            > Development" by Dave Olson. In his book he proposes a "splinter department".
            > This department is a place where very uncertain ideas can be tested, a
            > nursery for new ideas. For instance, if a person gets a bright idea he can,
            > with the management's approval, go to the splinter department for a couple
            > of months and experimenting with the idea. If the experiments turn out good
            > he might start a pilot project and so forth.
            >
            > The main reason for this department is that some ideas are too risky to
            > explore inside a project and that some ideas are distractions from the main
            > goal of a project.
            >
            > Is there a need for such a department in a Scrum "environment"?
            >
            > Regards,
            > Jonas
            >
            >
            >
            > 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/
            >
            >
            >
          • Peter McGowan
            I d say there is no more and no less need for such a group than in a non-scrum environment. I can see how scrum might effect how such a splinter group might
            Message 5 of 29 , Feb 4, 2002
            • 0 Attachment
              I'd say there is no more and no less need for such a group than in a
              non-scrum environment.

              I can see how scrum might effect how such a "splinter group" might operate
              and I suspect the chances of success would be increased if scrum was
              implemented by such a group. But should the question of the existence of
              such a group be a scrum one? I don't believe so.

              Peter

              ----- Original Message -----
              From: <vze2k2j6@...>
              To: <scrumdevelopment@yahoogroups.com>
              Sent: Monday, February 04, 2002 8:50 PM
              Subject: Re: [scrumdevelopment] Splinter Department


              > I'd say so if the technology is so whacked, bleeding edge, or untested
              that someone needs to first evaluate it. Wireless used to fit into that
              category, and in some cases still does.
              > Ken
              > >
              > > From: "Jonas Bengtsson" <jonas.b@...>
              > > Date: 2002/02/04 Mon AM 09:35:23 CST
              > > To: <scrumdevelopment@yahoogroups.com>
              > > Subject: [scrumdevelopment] Splinter Department
              > >
              > > Hi,
              > > I've just read "Exploiting Chaos: Cashing in on the Realities of
              Software
              > > Development" by Dave Olson. In his book he proposes a "splinter
              department".
              > > This department is a place where very uncertain ideas can be tested, a
              > > nursery for new ideas. For instance, if a person gets a bright idea he
              can,
              > > with the management's approval, go to the splinter department for a
              couple
              > > of months and experimenting with the idea. If the experiments turn out
              good
              > > he might start a pilot project and so forth.
              > >
              > > The main reason for this department is that some ideas are too risky to
              > > explore inside a project and that some ideas are distractions from the
              main
              > > goal of a project.
              > >
              > > Is there a need for such a department in a Scrum "environment"?
              > >
              > > Regards,
              > > Jonas
              > >
              > >
              > >
              > > 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/
              > >
              > >
              > >
              >
              >
              >
              > 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/
              >
              >
            • Paul Clanton
              I ve found that there are occasions when you may want to break away from the team. For example, more risk averse organizations may not ever put experimental
              Message 6 of 29 , Feb 5, 2002
              • 0 Attachment

                I’ve found that there are occasions when you may want to break away from the team.  For example, more risk averse organizations may not ever put experimental stuff at the top of the backlog.  A team member may just need a break to do something different, stretch their mental legs, learn something new, whatever. 

                 

                One approach that I have had success with is to allow team members to take a short (e.g., two weeks) “sabatical” once or twice a year to explore other things.  This might be some unique training or noodling around with a crazy idea or two.  The deliverable is not a working piece of software—although it’s not discouraged—but rather knowledge gained and/or a fresh perspective that’s presented at a meeting on the last day of their sabatical.  There is no _handoff_ but rather a _sharing_ that occurs.  It’s sufficiently short so that the rework, if any, is minimal.  At the same time, it’s long enough for them to have taken the idea beyond the “thinking about it” stage. It helps everybody to recharge their batteries at regular intervals.  Moreover, you get new ideas and/or a fresh perspective without having to break in a new team member! 

                 

                In contrast to the splinter department, this gives everybody an equal shot so that nobody can be accused of “running away”.  It happens at a regular, scheduled time, so nobody is surprised.  Finally, it makes good on the promise that many organizations seem to forget about regular training.

                 

                -----Original Message-----
                From: Jonas Bengtsson [mailto:jonas.b@...]
                Sent: Monday, February 04, 2002 9:50 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] Splinter Department

                 

                Thanks for your answer!

                It seems more reasonable to handle it (experiments/prototypes) within the
                team. And if people run away all the time, from the team, to do experiments
                I suspect the team will have a harder time to jell.

                Regards,
                Jonas

                > -----Original Message-----
                > From: Mike Beedle [mailto:beedlem@...]
                > Sent: Monday, February 04, 2002 4:51 PM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: RE: [scrumdevelopment] Splinter Department
                >
                >
                > Jonas Bengtsson wrote:
                > > Hi,
                > > I've just read "Exploiting Chaos: Cashing in
                > > on the Realities of Software Development" by
                > > Dave Olson. In his book he proposes a
                > > "splinter department".  This department is a place
                > > where very uncertain ideas can be tested, a
                > > nursery for new ideas. For instance, if a person
                > > gets a bright idea he can, with the management's
                > > approval, go to the splinter department for a couple
                > > of months and experimenting with the idea. If the
                > > experiments turn out good he might start a pilot
                > > project and so forth.
                > >
                > > The main reason for this department is that
                > > some ideas are too risky to explore inside a
                > > project and that some ideas are distractions
                > > from the main goal of a project.
                > >
                > > Is there a need for such a department in a Scrum
                > > "environment"?
                >
                > Jonas:
                >
                > I am familiar with the book.  I read it in the mid-90s.
                >
                > Scrum uses a more reengineered approach, a Case Team,
                > in Hammer's terminology.  A Case Team, by definition,
                > avoids hand-offs among teams, that require iteration
                > and rework among different teams, because those are
                > exactly the reasons why things get slowed down:
                >
                > 1) you need managers to talk and agree to do work
                > 2) you need workers to take instructions from
                > managers/team leaders
                > 3) you need workers to report to management what
                > is going on, and
                > 4) managers to report to each other on progress,
                > etc.
                > (All the bureaucratic stuff that is undesirable and
                > slows things down, albeit, some of it is always
                > unavoidable.)
                >
                > Instead in Scrum, new ideas are tried from within
                > the team, that is iteration and rework, if any,
                > stays within a single team.  Experiments or prototypes
                > are labeled as such in the Product Backlog.
                > And they are implemented when they are allocated
                > to the Sprint Backlog within a Sprint.  Progress
                > is reported through the Daily Scrums and the
                > decision to continue or to stop with the "experiment"
                > is evaluated daily.
                >
                > In other words, Scrum mechanisms treat experiments
                > like any other task.  In that sense, Scrum techniques
                > are universal i.e. they work for _any_ kind of
                > work that the team needs to accomplish,
                >
                > - Mike
                >
                > 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 the Yahoo! Terms of Service.




                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 the Yahoo! Terms of Service.

              • Mike Beedle
                Interesting. Now we really have the full spectrum: 1) integrated (within the Scrum team) 2) loosely coupled but same team (sabbatical) 3) splinter team For
                Message 7 of 29 , Feb 5, 2002
                • 0 Attachment
                  Interesting. Now we really have the full spectrum:

                  1) integrated (within the Scrum team)
                  2) loosely coupled but same team (sabbatical)
                  3) splinter team

                  For most clients I run several Scrum or XP applications
                  teams at once with one shared services or architecture
                  team that develops infrastructure related
                  stuff and releases reusable components developed by
                  all of the teams. But this functionality is _always_
                  related to the application needs.
                  (Ch 7 in the Scrum book, btw.)

                  So the Splinter team in our case is the shared services
                  or architecture team - this team develops new
                  infrastructure and releases any reusable components,
                  for example:

                  javascript libraries,
                  tag libraries,
                  web services,
                  business services (EJB, servlet-based),
                  transactions,
                  business objects, and
                  architectural services
                  etc.

                  More info about this at http://www.xbreed.net

                  (I take this opportunity to apologize for the
                  brevity of contents there. It will be shortly expanded.)

                  - Mike

                  -----Original Message-----
                  From: Paul Clanton [mailto:pclanton@...]
                  Sent: Tuesday, February 05, 2002 9:05 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] Splinter Department


                  I’ve found that there are occasions when you may want to break away from the
                  team. For example, more risk averse organizations may not ever put
                  experimental stuff at the top of the backlog. A team member may just need a
                  break to do something different, stretch their mental legs, learn something
                  new, whatever.

                  One approach that I have had success with is to allow team members to take a
                  short (e.g., two weeks) “sabatical” once or twice a year to explore other
                  things. This might be some unique training or noodling around with a crazy
                  idea or two. The deliverable is not a working piece of software—although it
                  ’s not discouraged—but rather knowledge gained and/or a fresh perspective
                  that’s presented at a meeting on the last day of their sabatical. There is
                  no _handoff_ but rather a _sharing_ that occurs. It’s sufficiently short so
                  that the rework, if any, is minimal. At the same time, it’s long enough for
                  them to have taken the idea beyond the “thinking about it” stage. It helps
                  everybody to recharge their batteries at regular intervals. Moreover, you
                  get new ideas and/or a fresh perspective without having to break in a new
                  team member!

                  In contrast to the splinter department, this gives everybody an equal shot
                  so that nobody can be accused of “running away”. It happens at a regular,
                  scheduled time, so nobody is surprised. Finally, it makes good on the
                  promise that many organizations seem to forget about regular training.

                  -----Original Message-----
                  From: Jonas Bengtsson [mailto:jonas.b@...]
                  Sent: Monday, February 04, 2002 9:50 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] Splinter Department

                  Thanks for your answer!

                  It seems more reasonable to handle it (experiments/prototypes) within the
                  team. And if people run away all the time, from the team, to do experiments
                  I suspect the team will have a harder time to jell.

                  Regards,
                  Jonas

                  > -----Original Message-----
                  > From: Mike Beedle [mailto:beedlem@...]
                  > Sent: Monday, February 04, 2002 4:51 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: RE: [scrumdevelopment] Splinter Department
                  >
                  >
                  > Jonas Bengtsson wrote:
                  > > Hi,
                  > > I've just read "Exploiting Chaos: Cashing in
                  > > on the Realities of Software Development" by
                  > > Dave Olson. In his book he proposes a
                  > > "splinter department". This department is a place
                  > > where very uncertain ideas can be tested, a
                  > > nursery for new ideas. For instance, if a person
                  > > gets a bright idea he can, with the management's
                  > > approval, go to the splinter department for a couple
                  > > of months and experimenting with the idea. If the
                  > > experiments turn out good he might start a pilot
                  > > project and so forth.
                  > >
                  > > The main reason for this department is that
                  > > some ideas are too risky to explore inside a
                  > > project and that some ideas are distractions
                  > > from the main goal of a project.
                  > >
                  > > Is there a need for such a department in a Scrum
                  > > "environment"?
                  >
                  > Jonas:
                  >
                  > I am familiar with the book. I read it in the mid-90s.
                  >
                  > Scrum uses a more reengineered approach, a Case Team,
                  > in Hammer's terminology. A Case Team, by definition,
                  > avoids hand-offs among teams, that require iteration
                  > and rework among different teams, because those are
                  > exactly the reasons why things get slowed down:
                  >
                  > 1) you need managers to talk and agree to do work
                  > 2) you need workers to take instructions from
                  > managers/team leaders
                  > 3) you need workers to report to management what
                  > is going on, and
                  > 4) managers to report to each other on progress,
                  > etc.
                  > (All the bureaucratic stuff that is undesirable and
                  > slows things down, albeit, some of it is always
                  > unavoidable.)
                  >
                  > Instead in Scrum, new ideas are tried from within
                  > the team, that is iteration and rework, if any,
                  > stays within a single team. Experiments or prototypes
                  > are labeled as such in the Product Backlog.
                  > And they are implemented when they are allocated
                  > to the Sprint Backlog within a Sprint. Progress
                  > is reported through the Daily Scrums and the
                  > decision to continue or to stop with the "experiment"
                  > is evaluated daily.
                  >
                  > In other words, Scrum mechanisms treat experiments
                  > like any other task. In that sense, Scrum techniques
                  > are universal i.e. they work for _any_ kind of
                  > work that the team needs to accomplish,
                  >
                  > - Mike
                  >
                  > 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 the Yahoo! Terms of Service.





                  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 the Yahoo! Terms of Service.



                  Yahoo! Groups Sponsor



                  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 the Yahoo! Terms of Service.
                • mpoppendieck
                  ... I can offer one more option. 3M has it s famous 15% rule. This rule says that anyone can charge up to 15% of their time to a shush fund and use it to
                  Message 8 of 29 , Feb 6, 2002
                  • 0 Attachment
                    --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                    >
                    > Interesting. Now we really have the full spectrum:
                    >
                    > 1) integrated (within the Scrum team)
                    > 2) loosely coupled but same team (sabbatical)
                    > 3) splinter team
                    >

                    I can offer one more option.

                    3M has it's famous 15% rule. This rule says that anyone can charge
                    up to 15% of their time to a 'shush fund' and use it to explore new
                    ideas. In practice, it is frequently used, because it allows anyone
                    with a great idea to get others to help them out, with no approval
                    necessary.

                    Say you are working on a cool new idea, both in your 15% time and
                    even in your spare time. But you need help. You can go up to
                    anyone else and ask them to help you out. If they think your idea
                    is cool, they will spend their 15% time on it. Both of you are
                    still doing your regular jobs, but are exploring this side idea
                    also.

                    Because using the 15% time is strongly encouraged, it is easy to put
                    together quite a team to work on splinter ideas, even as they are
                    all working on normal projects. There is virtually no oversight and
                    no accountability for the cool new idea. Any lab equipment
                    (computers for instance) and a minor amount of material is avaiable
                    at no cost. This continues until the assembled team decides to ask
                    for more resources than they can scrape together in the 15% time.
                    By that time, enough risk has been removed from the idea that it can
                    get legitimate funding.
                  • Mike Beedle
                    Very interesting. Relating this back to Scrum a bit, this would mean that the task was assigned on the Product Backlog -- because all the planned work needs
                    Message 9 of 29 , Feb 6, 2002
                    • 0 Attachment
                      Very interesting. Relating this back to Scrum a bit, this
                      would mean that the task was assigned on the Product Backlog --
                      because all the planned work needs to be there, and that to
                      accomplish this work it would have to be allocated to the
                      Sprint Backlog with special rules:
                      1) do this optionally, 2) use up to 15% of your time on it,
                      3) engage others as needed, 4) report progress in the Daily
                      Scrums.

                      This is a very interesting approach, Product Backlog and
                      Sprint Backlog with rules.

                      On occasion, we have had some of that, but I don't think it
                      has been formalized by anyone. I think this is a valid and
                      productive way of doing things. The Scrum Master would
                      help the team members enforce the rules, of course.

                      The only qualm I would have, is that it can get fairly
                      complicated as the number of rules increases, but I guess
                      different teams would have different rule tolerances ;-)

                      If you don't mind Mary, I'd like to borrow this one for
                      my next Scrum project,

                      - Mike


                      -----Original Message-----
                      From: mpoppendieck [mailto:mary@...]
                      Sent: Wednesday, February 06, 2002 1:40 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Re: Splinter Department


                      --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                      >
                      > Interesting. Now we really have the full spectrum:
                      >
                      > 1) integrated (within the Scrum team)
                      > 2) loosely coupled but same team (sabbatical)
                      > 3) splinter team
                      >

                      I can offer one more option.

                      3M has it's famous 15% rule. This rule says that anyone can charge
                      up to 15% of their time to a 'shush fund' and use it to explore new
                      ideas. In practice, it is frequently used, because it allows anyone
                      with a great idea to get others to help them out, with no approval
                      necessary.

                      Say you are working on a cool new idea, both in your 15% time and
                      even in your spare time. But you need help. You can go up to
                      anyone else and ask them to help you out. If they think your idea
                      is cool, they will spend their 15% time on it. Both of you are
                      still doing your regular jobs, but are exploring this side idea
                      also.

                      Because using the 15% time is strongly encouraged, it is easy to put
                      together quite a team to work on splinter ideas, even as they are
                      all working on normal projects. There is virtually no oversight and
                      no accountability for the cool new idea. Any lab equipment
                      (computers for instance) and a minor amount of material is avaiable
                      at no cost. This continues until the assembled team decides to ask
                      for more resources than they can scrape together in the 15% time.
                      By that time, enough risk has been removed from the idea that it can
                      get legitimate funding.


                      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 the Yahoo! Terms of Service.
                    • Paul
                      I love 3M s 15% idea. It s a win-win for everyone! -- Paul ... __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards
                      Message 10 of 29 , Feb 6, 2002
                      • 0 Attachment
                        I love 3M's 15% idea. It's a win-win for everyone!

                        -- Paul

                        --- mpoppendieck <mary@...> wrote:
                        > --- In scrumdevelopment@y..., "Mike Beedle"
                        > <beedlem@e...> wrote:
                        > >
                        > > Interesting. Now we really have the full
                        > spectrum:
                        > >
                        > > 1) integrated (within the Scrum team)
                        > > 2) loosely coupled but same team (sabbatical)
                        > > 3) splinter team
                        > >
                        >
                        > I can offer one more option.
                        >
                        > 3M has it's famous 15% rule. This rule says that
                        > anyone can charge
                        > up to 15% of their time to a 'shush fund' and use it
                        > to explore new
                        > ideas. In practice, it is frequently used, because
                        > it allows anyone
                        > with a great idea to get others to help them out,
                        > with no approval
                        > necessary.
                        >
                        > Say you are working on a cool new idea, both in your
                        > 15% time and
                        > even in your spare time. But you need help. You
                        > can go up to
                        > anyone else and ask them to help you out. If they
                        > think your idea
                        > is cool, they will spend their 15% time on it. Both
                        > of you are
                        > still doing your regular jobs, but are exploring
                        > this side idea
                        > also.
                        >
                        > Because using the 15% time is strongly encouraged,
                        > it is easy to put
                        > together quite a team to work on splinter ideas,
                        > even as they are
                        > all working on normal projects. There is virtually
                        > no oversight and
                        > no accountability for the cool new idea. Any lab
                        > equipment
                        > (computers for instance) and a minor amount of
                        > material is avaiable
                        > at no cost. This continues until the assembled team
                        > decides to ask
                        > for more resources than they can scrape together in
                        > the 15% time.
                        > By that time, enough risk has been removed from the
                        > idea that it can
                        > get legitimate funding.
                        >
                        >


                        __________________________________________________
                        Do You Yahoo!?
                        Send FREE Valentine eCards with Yahoo! Greetings!
                        http://greetings.yahoo.com
                      • mpoppendieck
                        Mike, I don t think I explained the 15% rule well enough. People are specifically NOT working on Backlog in their 15% time. They are working on their own
                        Message 11 of 29 , Feb 7, 2002
                        • 0 Attachment
                          Mike, I don't think I explained the 15% rule well enough. People
                          are specifically NOT working on Backlog in their 15% time. They are
                          working on their own cool idea. Generally it is not related to any
                          projects they are assigned to in the other 85% of their time. The
                          whole point is that people are free to tackle anything they are
                          interested in during this time. If they had to get their idea from
                          a Backlog, that would defeat the purpose.

                          By the way, this is how 3M starts up hundreds of new product
                          projects every year, and is able to continually diversify into new
                          businesses.

                          Mary

                          --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                          >
                          > Very interesting. Relating this back to Scrum a bit, this
                          > would mean that the task was assigned on the Product Backlog --
                          > because all the planned work needs to be there, and that to
                          > accomplish this work it would have to be allocated to the
                          > Sprint Backlog with special rules:
                          > 1) do this optionally, 2) use up to 15% of your time on it,
                          > 3) engage others as needed, 4) report progress in the Daily
                          > Scrums.
                          >
                          > This is a very interesting approach, Product Backlog and
                          > Sprint Backlog with rules.
                          >
                          > On occasion, we have had some of that, but I don't think it
                          > has been formalized by anyone. I think this is a valid and
                          > productive way of doing things. The Scrum Master would
                          > help the team members enforce the rules, of course.
                          >
                          > The only qualm I would have, is that it can get fairly
                          > complicated as the number of rules increases, but I guess
                          > different teams would have different rule tolerances ;-)
                          >
                          > If you don't mind Mary, I'd like to borrow this one for
                          > my next Scrum project,
                          >
                          > - Mike
                          >
                        • Jonas Bengtsson
                          How do you manage this when times get rough? For instance in the end of a sprint when you realise that the group won t be able to fulfil its commitment - do
                          Message 12 of 29 , Feb 7, 2002
                          • 0 Attachment
                            How do you manage this when times get rough? For instance in the end of a
                            sprint when you realise that the group won't be able to fulfil its
                            commitment - do you allow the 15% than?
                            Won't adding such things to the backlog and reporting in the daily scrums
                            lead to unnecessary noise?
                            What kind of activities will you approve?

                            /Jonas

                            > -----Original Message-----
                            > From: Mike Beedle [mailto:beedlem@...]
                            > Sent: Wednesday, February 06, 2002 9:56 PM
                            > To: scrumdevelopment@yahoogroups.com
                            > Subject: RE: [scrumdevelopment] Re: Splinter Department
                            >
                            >
                            >
                            > Very interesting. Relating this back to Scrum a bit, this
                            > would mean that the task was assigned on the Product Backlog --
                            > because all the planned work needs to be there, and that to
                            > accomplish this work it would have to be allocated to the
                            > Sprint Backlog with special rules:
                            > 1) do this optionally, 2) use up to 15% of your time on it,
                            > 3) engage others as needed, 4) report progress in the Daily
                            > Scrums.
                            >
                            > This is a very interesting approach, Product Backlog and
                            > Sprint Backlog with rules.
                            >
                            > On occasion, we have had some of that, but I don't think it
                            > has been formalized by anyone. I think this is a valid and
                            > productive way of doing things. The Scrum Master would
                            > help the team members enforce the rules, of course.
                            >
                            > The only qualm I would have, is that it can get fairly
                            > complicated as the number of rules increases, but I guess
                            > different teams would have different rule tolerances ;-)
                            >
                            > If you don't mind Mary, I'd like to borrow this one for
                            > my next Scrum project,
                            >
                            > - Mike
                            >
                            >
                            > -----Original Message-----
                            > From: mpoppendieck [mailto:mary@...]
                            > Sent: Wednesday, February 06, 2002 1:40 PM
                            > To: scrumdevelopment@yahoogroups.com
                            > Subject: [scrumdevelopment] Re: Splinter Department
                            >
                            >
                            > --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                            > >
                            > > Interesting. Now we really have the full spectrum:
                            > >
                            > > 1) integrated (within the Scrum team)
                            > > 2) loosely coupled but same team (sabbatical)
                            > > 3) splinter team
                            > >
                            >
                            > I can offer one more option.
                            >
                            > 3M has it's famous 15% rule. This rule says that anyone can charge
                            > up to 15% of their time to a 'shush fund' and use it to explore new
                            > ideas. In practice, it is frequently used, because it allows anyone
                            > with a great idea to get others to help them out, with no approval
                            > necessary.
                            >
                            > Say you are working on a cool new idea, both in your 15% time and
                            > even in your spare time. But you need help. You can go up to
                            > anyone else and ask them to help you out. If they think your idea
                            > is cool, they will spend their 15% time on it. Both of you are
                            > still doing your regular jobs, but are exploring this side idea
                            > also.
                            >
                            > Because using the 15% time is strongly encouraged, it is easy to put
                            > together quite a team to work on splinter ideas, even as they are
                            > all working on normal projects. There is virtually no oversight and
                            > no accountability for the cool new idea. Any lab equipment
                            > (computers for instance) and a minor amount of material is avaiable
                            > at no cost. This continues until the assembled team decides to ask
                            > for more resources than they can scrape together in the 15% time.
                            > By that time, enough risk has been removed from the idea that it can
                            > get legitimate funding.
                            >
                            >
                            > 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 the Yahoo! Terms of Service.
                            >
                            >
                            > Yahoo! Groups Sponsor
                            > ADVERTISEMENT
                            >
                            >
                            >
                            >
                            > 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 the Yahoo! Terms of Service.
                          • mpoppendieck
                            The trick is that the the use of the 15% rule must be encouraged across the organization. This is sort of built-in organizational Slack (see Tom DeMarco s
                            Message 13 of 29 , Feb 7, 2002
                            • 0 Attachment
                              The trick is that the the use of the 15% rule must be encouraged
                              across the organization. This is sort of built-in organizational
                              Slack (see Tom DeMarco's book by the same title).

                              Mary

                              --- In scrumdevelopment@y..., Paul <horked_noodle@y...> wrote:
                              > I love 3M's 15% idea. It's a win-win for everyone!
                              >
                              > -- Paul
                              >
                            • Paul Clanton
                              For the sake of continuity, I ve cobbled together some of the threads of this e-mail because I think that Mary and I have been saying similar things about the
                              Message 14 of 29 , Feb 7, 2002
                              • 0 Attachment

                                For the sake of continuity, I’ve cobbled together some of the threads of this e-mail because I think that Mary and I have been saying similar things about the splinter projects and Jonas has raised some very good questions about the realities of life.

                                 

                                Here’s my take on things. 

                                (1)   These projects take place outside of the Scrum and need no approval.  Oversight is minimal.  In terms of the Scrum process, these projects are a way to explore potential projects to add to the backlog.

                                (2)   These projects are not optional (although your participation in somebody else’s project is).  Innovation is a life and death question for most organizations.  This is a relatively inexpensive way to ensure that innovation occurs.

                                (3)   These projects are more important than any other projects (see #2 above) so even when times get rough, these projects are not sacrificed.  The one exception would be the project that MUST finish by a certain date or the company will suffer a major setback.  This same situation would trigger a canceling of all vacations and training, mandate overtime, etc. (Hopefully these are few and far between.)

                                 

                                In comparing Mary’s 3M approach and the sabbatical idea I raised, I think the differences are superficial.  I suggested a two-week (i.e., 4%) sabbatical _at least_ once a year.  This does not preclude spending 15% (i.e., 7.5 weeks).  I am not sure how 3M expects this time to be allocated (e.g., continuous on a daily basis or in chunks) but I personally favor chunking it up.  After all, continuous, short, uninterrupted work is the essence of Scrum.  Moreover, this gives people time to recharge their work batteries just as a vacation gives them time to recharge their personal batteries.

                                 

                                As always, comments, suggestions, slurs, and character assassinations are welcome.

                                Paul

                                 

                                -----Original Message-----
                                From: mpoppendieck [mailto:mary@...]
                                Sent: Thursday, February 07, 2002 8:43 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Splinter Department

                                 

                                The trick is that the the use of the 15% rule must be encouraged
                                across the organization.  This is sort of built-in organizational
                                Slack (see Tom DeMarco's book by the same title).

                                Mary

                                 

                                -----Original Message-----
                                From: Jonas Bengtsson [mailto:jonas.b@...]
                                Sent: Thursday, February 07, 2002 8:38 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Splinter Department

                                 

                                How do you manage this when times get rough? For instance in the end of a
                                sprint when you realise that the group won't be able to fulfil its
                                commitment - do you allow the 15% than?
                                Won't adding such things to the backlog and reporting in the daily scrums
                                lead to unnecessary noise?
                                What kind of activities will you approve?

                                /Jonas

                                 


                                -----Original Message-----
                                From: mpoppendieck [mailto:mary@...]
                                Sent: Thursday, February 07, 2002 8:34 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Splinter Department

                                 

                                Mike, I don't think I explained the 15% rule well enough.  People
                                are specifically NOT working on Backlog in their 15% time.  They are
                                working on their own cool idea.  Generally it is not related to any
                                projects they are assigned to in the other 85% of their time.  The
                                whole point is that people are free to tackle anything they are
                                interested in during this time.  If they had to get their idea from
                                a Backlog, that would defeat the purpose. 

                                By the way, this is how 3M starts up hundreds of new product
                                projects every year, and is able to continually diversify into new
                                businesses.

                                Mary


                                > -----Original Message-----
                                From: Mike Beedle [mailto:beedlem@...]
                                Sent: Wednesday, February 06, 2002 9:56 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Splinter Department

                                Very interesting.  Relating this back to Scrum a bit, this
                                would mean that the task was assigned on the Product Backlog --
                                because all the planned work needs to be there, and that to
                                accomplish this work it would have to be allocated to the
                                Sprint Backlog with special rules:
                                1) do this optionally, 2) use up to 15% of your time on it,
                                3) engage others as needed, 4) report progress in the Daily
                                Scrums.

                                This is a very interesting approach, Product Backlog and
                                Sprint Backlog with rules.

                                On occasion, we have had some of that, but I don't think it
                                has been formalized by anyone.  I think this is a valid and
                                productive way of doing things.  The Scrum Master would
                                help the team members enforce the rules, of course.

                                The only qualm I would have, is that it can get fairly
                                complicated as the number of rules increases, but I guess
                                different teams would have different rule tolerances ;-)

                                If you don't mind Mary, I'd like to borrow this one for
                                my next Scrum project,

                                - Mike

                                -----Original Message-----
                                From: mpoppendieck [mailto:mary@...]
                                Sent: Wednesday, February 06, 2002 1:40 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Splinter Department


                                --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                                >
                                > Interesting.  Now we really have the full spectrum:
                                >
                                > 1) integrated (within the Scrum team)
                                > 2) loosely coupled but same team (sabbatical)
                                > 3) splinter team
                                >

                                I can offer one more option.

                                3M has it's famous 15% rule.  This rule says that anyone can charge
                                up to 15% of their time to a 'shush fund' and use it to explore new
                                ideas.  In practice, it is frequently used, because it allows anyone
                                with a great idea to get others to help them out, with no approval
                                necessary.

                                Say you are working on a cool new idea, both in your 15% time and
                                even in your spare time.  But you need help.  You can go up to
                                anyone else and ask them to help you out.  If they think your idea
                                is cool, they will spend their 15% time on it.  Both of you are
                                still doing your regular jobs, but are exploring this side idea
                                also.

                                Because using the 15% time is strongly encouraged, it is easy to put
                                together quite a team to work on splinter ideas, even as they are
                                all working on normal projects. There is virtually no oversight and
                                no accountability for the cool new idea.  Any lab equipment
                                (computers for instance) and a minor amount of material is avaiable
                                at no cost.  This continues until the assembled team decides to ask
                                for more resources than they can scrape together in the 15% time.
                                By that time, enough risk has been removed from the idea that it can
                                get legitimate funding.

                                -----Original Message-----
                                From: Mike Beedle [mailto:beedlem@...]
                                Sent: Tuesday, February 05, 2002 11:59 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Splinter Department

                                 


                                Interesting.  Now we really have the full spectrum:

                                1) integrated (within the Scrum team)
                                2) loosely coupled but same team (sabbatical)
                                3) splinter team

                                For most clients I run several Scrum or XP applications
                                teams at once with one shared services or architecture
                                team that develops infrastructure related
                                stuff and releases reusable components developed by
                                all of the teams.  But this functionality is _always_
                                related to the application needs.
                                (Ch 7 in the Scrum book, btw.)

                                So the Splinter team in our case is the shared services
                                or architecture team - this team develops new
                                infrastructure and releases any reusable components,
                                for example:

                                javascript libraries,
                                tag libraries,
                                web services,
                                business services (EJB, servlet-based),
                                transactions,
                                business objects, and
                                architectural services
                                etc.

                                More info about this at http://www.xbreed.net

                                (I take this opportunity to apologize for the
                                brevity of contents there.  It will be shortly expanded.)

                                - Mike

                                -----Original Message-----
                                From: Paul Clanton [mailto:pclanton@...]
                                Sent: Tuesday, February 05, 2002 9:05 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Splinter Department


                                I’ve found that there are occasions when you may want to break away from the
                                team.  For example, more risk averse organizations may not ever put
                                experimental stuff at the top of the backlog.  A team member may just need a
                                break to do something different, stretch their mental legs, learn something
                                new, whatever.

                                One approach that I have had success with is to allow team members to take a
                                short (e.g., two weeks) “sabatical” once or twice a year to explore other
                                things.  This might be some unique training or noodling around with a crazy
                                idea or two.  The deliverable is not a working piece of software—although it
                                ’s not discouraged—but rather knowledge gained and/or a fresh perspective
                                that’s presented at a meeting on the last day of their sabatical.  There is
                                no _handoff_ but rather a _sharing_ that occurs.  It’s sufficiently short so
                                that the rework, if any, is minimal.  At the same time, it’s long enough for
                                them to have taken the idea beyond the “thinking about it” stage. It helps
                                everybody to recharge their batteries at regular intervals.  Moreover, you
                                get new ideas and/or a fresh perspective without having to break in a new
                                team member!

                                In contrast to the splinter department, this gives everybody an equal shot
                                so that nobody can be accused of “running away”.  It happens at a regular,
                                scheduled time, so nobody is surprised.  Finally, it makes good on the
                                promise that many organizations seem to forget about regular training.
                                 

                              • mpoppendieck
                                The important thing about new product development at 3M is that the champion of a new product develops a passion about that product, and inspires passion in
                                Message 15 of 29 , Feb 8, 2002
                                • 0 Attachment
                                  The important thing about new product development at 3M is that
                                  the 'champion' of a new product develops a passion about that
                                  product, and inspires passion in others. It's very much like a
                                  new
                                  business venture. People who have a passion about something find
                                  the time to work on it, lunch time, come in early, stay late,
                                  weekends, whenever. People whose regular jobs get demanding simply
                                  spend less time on the `unofficial' project. The 15% is just
                                  a
                                  term, it is not a hard and fast number. People do what they can,
                                  when they can, and are particularly careful not to let their regular
                                  jobs suffer.

                                  As an example, I led a team which met every week for 3 years at 7:30
                                  on Wednesday mornings. This was so regularly scheduled meetings,
                                  which tended to start at 8:30, would not interfere. At the end of
                                  the 3 years, attendance was averaging 25+ every single week, while
                                  there were less than 10 people officially assigned to the program.
                                  It was sort of like a Scrum meeting only it lasted about an hour.
                                  Almost everyone came to the weekly meeting; often that was the only
                                  thing that people did. But when they had an interest, could spare
                                  the time, and were needed, they would do more.

                                  People are very good about being dedicated to their regular jobs,
                                  and if they are totally captivated by their regular job, they are
                                  less likely to use any 15% time. Some people are bored by their
                                  jobs and some people just want to do new things. Having a way to
                                  get engaged with an endeavor of their own choosing gives these
                                  people a chance to follow a dream. At the same time – my
                                  observation – their regular work does not suffer at all. They
                                  are
                                  careful to be sure that their assignments get a fair share of their
                                  attention, perhaps *because* they had found a new interest in life,
                                  or perhaps in appreciation of being allowed to work on the new idea.

                                  There was really very little effort to track how scientists spend
                                  their time at 3M when I worked there. Sometimes government
                                  contracts required careful tracking, but in general, no one counted
                                  hours. I think that leaving the problem of handling a crisis to the
                                  people involved is the sensible approach. People who are motivated
                                  will do right by their employers and will come through when needed.
                                  Trying too hard to set up a structure is more or less an insult to
                                  the people who are capable of figuring this out for themselves.

                                  Mary

                                  --- In scrumdevelopment@y..., "Jonas Bengtsson" <jonas.b@h...> wrote:
                                  > How do you manage this when times get rough? For instance in the
                                  end of a
                                  > sprint when you realise that the group won't be able to fulfil its
                                  > commitment - do you allow the 15% than?
                                  > Won't adding such things to the backlog and reporting in the daily
                                  scrums
                                  > lead to unnecessary noise?
                                  > What kind of activities will you approve?
                                  >
                                  > /Jonas
                                  >
                                • Mike Beedle
                                  ... Mary: Thanks for the clarification. One of the promises that we make in Scrum is focus and commitment of every resources in delivering software according
                                  Message 16 of 29 , Feb 9, 2002
                                  • 0 Attachment
                                    Mary wrote:
                                    > Mike, I don't think I explained the 15% rule well enough.
                                    > People are specifically NOT working on Backlog in their
                                    > 15% time. They are working on their own cool idea. Generally
                                    > it is not related to any projects they are assigned
                                    > to in the other 85% of their time. The whole point is
                                    > that people are free to tackle anything they are
                                    > interested in during this time. If they had to get
                                    > their idea from a Backlog, that would defeat the purpose.

                                    Mary:

                                    Thanks for the clarification.

                                    One of the promises that we make in Scrum is focus and
                                    commitment of every resources in delivering software
                                    according to the customer priorities. And the customer
                                    priorities are kept in the prioritized product backlog.

                                    So this would be difficult, but maybe not impossible in
                                    a traditional Scrum team.

                                    Paul's sabbatical would be more feasible, as long as the
                                    team member on sabbatical is _not_ in the Scrum team, he/she
                                    may spend time doing something else without dragging
                                    anyone with him/her,

                                    - Mike
                                  • Mike Beedle
                                    ... Paul, Sorry I didn t get the same idea after Mary s clarification: Isn t the sabbatical outside the team and the 15%-exploratory inside the team as Mary
                                    Message 17 of 29 , Feb 9, 2002
                                    • 0 Attachment
                                      Paul Clanton wrote:
                                      > In comparing Mary’s 3M approach and the sabbatical
                                      >idea I raised, I think the differences are
                                      >superficial. I suggested a two-week (i.e., 4%)
                                      >sabbatical _at least_ once a year. This does
                                      >not preclude spending 15% (i.e., 7.5 weeks).
                                      >I am not sure how 3M expects this time to be
                                      >allocated (e.g., continuous on a daily basis
                                      >or in chunks) but I personally favor chunking
                                      >it up. After all, continuous, short, uninterrupted
                                      >work is the essence of Scrum. Moreover, this
                                      >gives people time to recharge their work batteries
                                      >just as a vacation gives them time to recharge
                                      >their personal batteries.

                                      Paul,

                                      Sorry I didn't get the same idea after Mary's
                                      clarification:

                                      Isn't the sabbatical outside the team and
                                      the 15%-exploratory inside the team as Mary
                                      described it?

                                      (meta-comment "Here is my Scrum-centric mind
                                      taking over my hands.")

                                      This difference is significant. In Scrum, we
                                      promise that the team will be focused and committed
                                      and that it won't be working on anything else except
                                      the Sprint Backlog, (which of course came from the
                                      Product Backlog, and therefore came from
                                      Customer's priorities).

                                      I am starting to think the sabbatical is more
                                      compatible with Scrum, if the activities are
                                      not related to the customer's needs.

                                      OTOH, if they are, they should be in the Product
                                      Backlog, and prioritized and assigned to Sprint
                                      Backlog like any other task,

                                      - Mike
                                    • mpoppendieck
                                      When people go home from work, they coach their kids sports or volunteer at church or train for triathlons or engage in other passions. We certainly don t
                                      Message 18 of 29 , Feb 9, 2002
                                      • 0 Attachment
                                        When people go home from work, they coach their kids sports or
                                        volunteer at church or train for triathlons or engage in other
                                        passions. We certainly don't expect them to give this up for
                                        work,
                                        except maybe temporarily in a crisis. Some people come home from
                                        working on a Scrum team and work on some Open Source code or put
                                        together a database for a boy scout troop, and so on. The point of
                                        the 15% rule is that people who get passionate about something other
                                        than their regular jobs (but related to their company interests) are
                                        encouraged to pursue the idea while on the job. By leveraging this
                                        kind of passion, 3M gets hundreds of new products every year.

                                        I wonder how we can expect every member of a Scrum team to be
                                        totally committed to do nothing but work on the backlog over the
                                        several months a project might run. It seems rather pretentious to
                                        assume this. I suspect that a well-led Scrum team will motivate all
                                        the team members to work only on the customer backlog. But if Scrum
                                        becomes a way of life in an organization, it seems to me that the
                                        organization should admit that some people on some Scrum teams might
                                        get distracted and want to do something else some of the time. If
                                        they can't do it at work, they will do it at home. 3M provides a
                                        simple mechanism to allow everyone some slack, so they can follow
                                        their passions at work, and in exchange, the company cashes in on
                                        the results.

                                        So I would argue that allowing (not scheduling, allowing) slack in
                                        everyone's normal schedule, instead of expecting everyone to be
                                        100%
                                        committed to what their management wants them to do, is a good
                                        thing.


                                        --- In scrumdevelopment@y..., "Mike Beedle" <beedlem@e...> wrote:
                                        >
                                        > One of the promises that we make in Scrum is focus and
                                        > commitment of every resources in delivering software
                                        > according to the customer priorities. And the customer
                                        > priorities are kept in the prioritized product backlog.
                                        >
                                        > So this would be difficult, but maybe not impossible in
                                        > a traditional Scrum team.
                                        >
                                        > Paul's sabbatical would be more feasible, as long as the
                                        > team member on sabbatical is _not_ in the Scrum team, he/she
                                        > may spend time doing something else without dragging
                                        > anyone with him/her,
                                        >
                                        > - Mike
                                      • Mike Cohn
                                        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
                                        Message 19 of 29 , Feb 9, 2002
                                        • 0 Attachment

                                          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

                                           

                                          -----Original Message-----
                                          From: mpoppendieck [mailto:mary@...]
                                          Sent:
                                          Saturday, February 09, 2002 9:14 AM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: [scrumdevelopment] Re: Splinter Department

                                           

                                          When people go home from work, they coach their kids sports or
                                          volunteer at church or train for triathlons or engage in other
                                          passions.  We certainly don't expect them to give this up for
                                          work,
                                          except maybe temporarily in a crisis.  Some people come home from
                                          working on a Scrum team and work on some Open Source code or put
                                          together a database for a boy scout troop, and so on.  The point of
                                          the 15% rule is that people who get passionate about something other
                                          than their regular jobs (but related to their company interests) are
                                          encouraged to pursue the idea while on the job.  By leveraging this
                                          kind of passion, 3M gets hundreds of new products every year.

                                          I wonder how we can expect every member of a Scrum team to be
                                          totally committed to do nothing but work on the backlog over the
                                          several months a project might run.  It seems rather pretentious to
                                          assume this.  I suspect that a well-led Scrum team will motivate all
                                          the team members to work only on the customer backlog.  But if Scrum
                                          becomes a way of life in an organization, it seems to me that the
                                          organization should admit that some people on some Scrum teams might
                                          get distracted and want to do something else some of the time. If
                                          they can't do it at work, they will do it at home.  3M provides a
                                          simple mechanism to allow everyone some slack, so they can follow
                                          their passions at work, and in exchange, the company cashes in on
                                          the results.

                                          So I would argue that allowing (not scheduling, allowing) slack in
                                          everyone's
                                          normal schedule, instead of expecting everyone to be

                                          100%
                                          committed
                                          to what their management wants them to do, is a good

                                          thing. 

                                           

                                        • mpoppendieck
                                          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
                                          Message 20 of 29 , 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
                                            >
                                          • Paul
                                            You just took a good idea and made it a bad one. I really don t like this arm-twisting idea that every Friday you will work on something outside of your
                                            Message 21 of 29 , Feb 9, 2002
                                            • 0 Attachment
                                              You just took a good idea and made it a bad one. I
                                              really don't like this arm-twisting idea that every
                                              Friday you will work on something outside of your
                                              project. What happens when spring goals are not being
                                              met? The better idea was 3M which leaves the decision
                                              up to the individual who has other commitments (
                                              Sprint Goals ).

                                              -- Paul


                                              --- Mike Cohn <mike@...> 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
                                              >
                                              > -----Original Message-----
                                              > From: mpoppendieck [mailto:mary@...]
                                              > Sent: Saturday, February 09, 2002 9:14 AM
                                              > To: scrumdevelopment@yahoogroups.com
                                              > Subject: [scrumdevelopment] Re: Splinter Department
                                              >
                                              > When people go home from work, they coach their kids
                                              > sports or
                                              > volunteer at church or train for triathlons or
                                              > engage in other
                                              > passions. We certainly don't expect them to give
                                              > this up for
                                              > work,
                                              > except maybe temporarily in a crisis. Some people
                                              > come home from
                                              > working on a Scrum team and work on some Open Source
                                              > code or put
                                              > together a database for a boy scout troop, and so
                                              > on. The point of
                                              > the 15% rule is that people who get passionate about
                                              > something other
                                              > than their regular jobs (but related to their
                                              > company interests) are
                                              > encouraged to pursue the idea while on the job. By
                                              > leveraging this
                                              > kind of passion, 3M gets hundreds of new products
                                              > every year.
                                              >
                                              > I wonder how we can expect every member of a Scrum
                                              > team to be
                                              > totally committed to do nothing but work on the
                                              > backlog over the
                                              > several months a project might run. It seems rather
                                              > pretentious to
                                              > assume this. I suspect that a well-led Scrum team
                                              > will motivate all
                                              > the team members to work only on the customer
                                              > backlog. But if Scrum
                                              > becomes a way of life in an organization, it seems
                                              > to me that the
                                              > organization should admit that some people on some
                                              > Scrum teams might
                                              > get distracted and want to do something else some of
                                              > the time. If
                                              > they can't do it at work, they will do it at home.
                                              > 3M provides a
                                              > simple mechanism to allow everyone some slack, so
                                              > they can follow
                                              > their passions at work, and in exchange, the company
                                              > cashes in on
                                              > the results.
                                              >
                                              > So I would argue that allowing (not scheduling,
                                              > allowing) slack in
                                              > everyone's normal schedule, instead of expecting
                                              > everyone to be
                                              > 100%
                                              > committed to what their management wants them to do,
                                              > is a good
                                              > thing.
                                              >
                                              >
                                              >


                                              __________________________________________________
                                              Do You Yahoo!?
                                              Send FREE Valentine eCards with Yahoo! Greetings!
                                              http://greetings.yahoo.com
                                            • Mike Cohn
                                              Personally, I ve always let people work the hours they want unless some big wig tells me I can t allow that. Many of the companies I ve worked with-especially
                                              Message 22 of 29 , Feb 9, 2002
                                              • 0 Attachment

                                                Personally, I’ve always let people work the hours they want unless some big wig tells me I can’t allow that. Many of the companies I’ve worked with—especially over the past 7 years—have been distributed across more than one time zone. At that point it’s irrelevant when people work or are in the office. In practice I never really care when people take their time off the mainline project. “Friday afternoon” was more symbolic than anything else. Certainly if someone wanted to attend a product user’s group meeting or such out of the office I’ve encouraged that whenever it was scheduled. The idea was to have the person spend some company time doing things that indirectly, rather than directly, benefit the project. Reading magazines, articles, web sites, etc. all count in that direction. Similarly, I’ve pushed programmers to attend conferences that are outside their normal realm in the past because I think these help encourage creative problem-solving. For example, I’ve sent C++ programmers to Eiffel conferences even though that company had no possibility of doing Eiffel programming. It just helps people learn to approach problems differently. That’s a good benefit to encouraging time away from the mainline project.

                                                 

                                                -----Original Message-----
                                                From: mpoppendieck [mailto:mary@...]
                                                Sent: Saturday, February 09, 2002 1:16 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: [scrumdevelopment] Re: Splinter Department

                                                 

                                                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





                                                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 the Yahoo! Terms of Service.
                                              • Mike Cohn
                                                You re right-there can be problems with telling individuals on a team that the Friday afternoon should or must be spent off the project. I ve never had a
                                                Message 23 of 29 , Feb 9, 2002
                                                • 0 Attachment

                                                  You’re right—there can be problems with telling individuals on a team that the Friday afternoon “should” or “must” be spent off the project. I’ve never had a programmer consider it “arm-twisting” though. Usually what happens is that the programmer knows that Friday afternoon is his for anything remotely related to work as long as he has made respectable progress on his assignments and almost every programmer I’ve worked with will do whatever they can to be able to have that time for pursuing their own special interests.

                                                   

                                                  Of course I’ve never truly forced a programmer not to work on the main project and work on outside things. If a project is behind, desperately needs a few hours, or was going to be in a position where people were going to come in over the weekend (rather voluntarily or not) it would be criminal to tell people not to code on Friday but to be in on Saturday. My comment about telling people that I don’t want them to work on the mainline task is more to fully get the point across that they are not going to impress me with their dedication or commitment by working on the project on Friday afternoon in most cases. With most developers it is very hard to convince them of your sincerity when you tell them you would really rather have them with their feet pitched up reading a good book or contributing to an open source project or such for that few hours a week.

                                                   

                                                  Also, I want to be clear that I started my comment with “I’ve dealt with this two ways in the past…”.  While I think giving people dedicated time to pursue beneficial tasks outside the mainline project it is not how I’ve been doing it with teams over the past few years. I actually find it much better to just underallocate tasks to the sprint and establish a culture where people know it is OK to spend a little time each week (as appropriate, depending on where the project is and how the sprint is going) on unplanned tasks. However, it is not easy to establish this as part of the culture in most organizations, usually there’s a CEO or CFO or someone who walks around asking “why isn’t Johnny coding?”

                                                   

                                                  -----Original Message-----
                                                  From: Paul [mailto:horked_noodle@...]
                                                  Sent
                                                  : Saturday, February 09, 2002 1:43 PM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: RE: [scrumdevelopment] Re: Splinter Department

                                                   

                                                  You just took a good idea and made it a bad one.  I
                                                  really don't like this arm-twisting idea that every
                                                  Friday you will work on something outside of your
                                                  project.  What happens when spring goals are not being
                                                  met?  The better idea was 3M which leaves the decision
                                                  up to the individual who has other commitments (
                                                  Sprint Goals ).

                                                      -- Paul


                                                  --- Mike Cohn <mike@...> 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

                                                  > -----Original Message-----
                                                  > From: mpoppendieck [mailto:mary@...]
                                                  > Sent:
                                                  Saturday, February 09, 2002 9:14 AM
                                                  > To: scrumdevelopment@yahoogroups.com
                                                  > Subject: [scrumdevelopment] Re: Splinter Department

                                                  > When people go home from work, they coach their kids
                                                  > sports or
                                                  > volunteer at church or train for triathlons or
                                                  > engage in other
                                                  > passions.  We certainly don't expect them to give
                                                  > this up for
                                                  > work,
                                                  > except maybe temporarily in a crisis.  Some people
                                                  > come home from
                                                  > working on a Scrum team and work on some Open Source
                                                  > code or put
                                                  > together a database for a boy scout troop, and so
                                                  > on.  The point of
                                                  > the 15% rule is that people who get passionate about
                                                  > something other
                                                  > than their regular jobs (but related to their
                                                  > company interests) are
                                                  > encouraged to pursue the idea while on the job.  By
                                                  > leveraging this
                                                  > kind of passion, 3M gets hundreds of new products
                                                  > every year.
                                                  >
                                                  > I wonder how we can expect every member of a Scrum
                                                  > team to be
                                                  > totally committed to do nothing but work on the
                                                  > backlog over the
                                                  > several months a project might run.  It seems rather
                                                  > pretentious to
                                                  > assume this.  I suspect that a well-led Scrum team
                                                  > will motivate all
                                                  > the team members to work only on the customer
                                                  > backlog.  But if Scrum
                                                  > becomes a way of life in an organization, it seems
                                                  > to me that the
                                                  > organization should admit that some people on some
                                                  > Scrum teams might
                                                  > get distracted and want to do something else some of
                                                  > the time. If
                                                  > they can't do it at work, they will do it at home.
                                                  > 3M provides a
                                                  > simple mechanism to allow everyone some slack, so
                                                  > they can follow
                                                  > their passions at work, and in exchange, the company
                                                  > cashes in on
                                                  > the results.
                                                  >
                                                  > So I would argue that allowing (not scheduling,
                                                  > allowing) slack in
                                                  > everyone's normal schedule, instead of expecting
                                                  > everyone to be
                                                  > 100%
                                                  > committed to what their management wants them to do,
                                                  > is a good
                                                  > thing. 
                                                  >

                                                  >


                                                  __________________________________________________
                                                  Do You Yahoo!?
                                                  Send FREE Valentine eCards with Yahoo! Greetings!
                                                  http://greetings.yahoo.com


                                                  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 the Yahoo! Terms of Service.
                                                • mpoppendieck
                                                  ... team ... project. ... Usually ... his ... respectable ... worked with ... main ... desperately ... were ... would ... to work ... they are ... working ...
                                                  Message 24 of 29 , Feb 10, 2002
                                                  • 0 Attachment
                                                    --- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
                                                    > You're right-there can be problems with telling individuals on a
                                                    team
                                                    > that the Friday afternoon "should" or "must" be spent off the
                                                    project.
                                                    > I've never had a programmer consider it "arm-twisting" though.
                                                    Usually
                                                    > what happens is that the programmer knows that Friday afternoon is
                                                    his
                                                    > for anything remotely related to work as long as he has made
                                                    respectable
                                                    > progress on his assignments and almost every programmer I've
                                                    worked with
                                                    > will do whatever they can to be able to have that time for pursuing
                                                    > their own special interests.
                                                    >
                                                    > Of course I've never truly forced a programmer not to work on the
                                                    main
                                                    > project and work on outside things. If a project is behind,
                                                    desperately
                                                    > needs a few hours, or was going to be in a position where people
                                                    were
                                                    > going to come in over the weekend (rather voluntarily or not) it
                                                    would
                                                    > be criminal to tell people not to code on Friday but to be in on
                                                    > Saturday. My comment about telling people that I don't want them
                                                    to work
                                                    > on the mainline task is more to fully get the point across that
                                                    they are
                                                    > not going to impress me with their dedication or commitment by
                                                    working
                                                    > on the project on Friday afternoon in most cases. With most
                                                    developers
                                                    > it is very hard to convince them of your sincerity when you tell
                                                    them
                                                    > you would really rather have them with their feet pitched up
                                                    reading a
                                                    > good book or contributing to an open source project or such for
                                                    that few
                                                    > hours a week.
                                                    >
                                                    > Also, I want to be clear that I started my comment with "I've
                                                    dealt with
                                                    > this two ways in the past.". While I think giving people
                                                    dedicated time
                                                    > to pursue beneficial tasks outside the mainline project it is not
                                                    how
                                                    > I've been doing it with teams over the past few years. I actually
                                                    find
                                                    > it much better to just underallocate tasks to the sprint and
                                                    establish a
                                                    > culture where people know it is OK to spend a little time each
                                                    week (as
                                                    > appropriate, depending on where the project is and how the sprint
                                                    is
                                                    > going) on unplanned tasks. However, it is not easy to establish
                                                    this as
                                                    > part of the culture in most organizations, usually there's a CEO
                                                    or CFO
                                                    > or someone who walks around asking "why isn't Johnny coding?"
                                                    >
                                                    > -----Original Message-----
                                                    > From: Paul [mailto:horked_noodle@y...]
                                                    > Sent: Saturday, February 09, 2002 1:43 PM
                                                    > To: scrumdevelopment@y...
                                                    > Subject: RE: [scrumdevelopment] Re: Splinter Department
                                                    >
                                                    > You just took a good idea and made it a bad one. I
                                                    > really don't like this arm-twisting idea that every
                                                    > Friday you will work on something outside of your
                                                    > project. What happens when spring goals are not being
                                                    > met? The better idea was 3M which leaves the decision
                                                    > up to the individual who has other commitments (
                                                    > Sprint Goals ).
                                                    >
                                                    > -- Paul
                                                    >
                                                    >
                                                    > --- 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
                                                    > >
                                                    > > -----Original Message-----
                                                    > > From: mpoppendieck [mailto:mary@p...]
                                                    > > Sent: Saturday, February 09, 2002 9:14 AM
                                                    > > To: scrumdevelopment@y...
                                                    > > Subject: [scrumdevelopment] Re: Splinter Department
                                                    > >
                                                    > > When people go home from work, they coach their kids
                                                    > > sports or
                                                    > > volunteer at church or train for triathlons or
                                                    > > engage in other
                                                    > > passions. We certainly don't expect them to give
                                                    > > this up for
                                                    > > work,
                                                    > > except maybe temporarily in a crisis. Some people
                                                    > > come home from
                                                    > > working on a Scrum team and work on some Open Source
                                                    > > code or put
                                                    > > together a database for a boy scout troop, and so
                                                    > > on. The point of
                                                    > > the 15% rule is that people who get passionate about
                                                    > > something other
                                                    > > than their regular jobs (but related to their
                                                    > > company interests) are
                                                    > > encouraged to pursue the idea while on the job. By
                                                    > > leveraging this
                                                    > > kind of passion, 3M gets hundreds of new products
                                                    > > every year.
                                                    > >
                                                    > > I wonder how we can expect every member of a Scrum
                                                    > > team to be
                                                    > > totally committed to do nothing but work on the
                                                    > > backlog over the
                                                    > > several months a project might run. It seems rather
                                                    > > pretentious to
                                                    > > assume this. I suspect that a well-led Scrum team
                                                    > > will motivate all
                                                    > > the team members to work only on the customer
                                                    > > backlog. But if Scrum
                                                    > > becomes a way of life in an organization, it seems
                                                    > > to me that the
                                                    > > organization should admit that some people on some
                                                    > > Scrum teams might
                                                    > > get distracted and want to do something else some of
                                                    > > the time. If
                                                    > > they can't do it at work, they will do it at home.
                                                    > > 3M provides a
                                                    > > simple mechanism to allow everyone some slack, so
                                                    > > they can follow
                                                    > > their passions at work, and in exchange, the company
                                                    > > cashes in on
                                                    > > the results.
                                                    > >
                                                    > > So I would argue that allowing (not scheduling,
                                                    > > allowing) slack in
                                                    > > everyone's normal schedule, instead of expecting
                                                    > > everyone to be
                                                    > > 100%
                                                    > > committed to what their management wants them to do,
                                                    > > is a good
                                                    > > thing.
                                                    > >
                                                    > >
                                                    > >
                                                    >
                                                    >
                                                    > __________________________________________________
                                                    > Do You Yahoo!?
                                                    > Send FREE Valentine eCards with Yahoo! Greetings!
                                                    > http://greetings.yahoo.com
                                                    >
                                                    >
                                                    >
                                                    >
                                                    > Yahoo! Groups Sponsor
                                                    >
                                                    >
                                                    > ADVERTISEMENT
                                                    >
                                                    >
                                                    <http://rd.yahoo.com/M=221000.1882886.3382503.1261774/D=egroupweb/S=1
                                                    707
                                                    > 209021:HM/A=965714/R=0/O=1/I=brandr-promo-flowersale-alerts-
                                                    lrecm/*http:
                                                    > /shopping.yahoo.com/promotions/flowers/index.html>
                                                    >
                                                    >
                                                    > <http://us.adserver.yahoo.com/l?
                                                    M=221000.1882886.3382503.1261774/D=egrou
                                                    > pmail/S=1707209021:HM/A=965714/rand=548790149>
                                                    >
                                                    > To Post a message, send it to: scrumdevelopment@e...
                                                    > To Unsubscribe, send a blank message to:
                                                    > scrumdevelopment-unsubscribe@e...
                                                    >
                                                    > Your use of Yahoo! Groups is subject to the Yahoo!
                                                    > <http://docs.yahoo.com/info/terms/> Terms of Service.
                                                  • Paul Clanton
                                                    With Mary’s subsequent clarification, I agree that the difference is significant. The way I’ve treated the sabbatical in the past is pretty much as
                                                    Message 25 of 29 , Feb 11, 2002
                                                    • 0 Attachment

                                                      With Mary’s subsequent clarification, I agree that the difference is significant.  The way I’ve treated the sabbatical in the past is pretty much as you’ve described it, namely outside the team and outside the backlogs for a concentrated stretch.

                                                       

                                                      -----Original Message-----
                                                      From: Mike Beedle [mailto:beedlem@...]
                                                      Sent: Saturday, February 09, 2002 2:01 AM
                                                      To: scrumdevelopment@yahoogroups.com
                                                      Subject: RE: [scrumdevelopment] Re: Splinter Department

                                                       

                                                      Paul Clanton wrote:

                                                      > In comparing Mary’s 3M approach and the sabbatical
                                                      >idea I raised, I think the differences are
                                                      >superficial.  I suggested a two-week (i.e., 4%)
                                                      >sabbatical _at least_ once a year.  This does
                                                      >not preclude spending 15% (i.e., 7.5 weeks).
                                                      >I am not sure how 3M expects this time to be
                                                      >allocated (e.g., continuous on a daily basis
                                                      >or in chunks) but I personally favor chunking
                                                      >it up.  After all, continuous, short, uninterrupted
                                                      >work is the essence of Scrum.  Moreover, this
                                                      >gives people time to recharge their work batteries
                                                      >just as a vacation gives them time to recharge
                                                      >their personal batteries.

                                                      Paul,

                                                      Sorry I didn't get the same idea after Mary's
                                                      clarification:

                                                      Isn't the sabbatical outside the team and
                                                      the 15%-exploratory inside the team as Mary
                                                      described it?

                                                      (meta-comment "Here is my Scrum-centric mind
                                                      taking over my hands.")

                                                      This difference is significant.  In Scrum, we
                                                      promise that the team will be focused and committed
                                                      and that it won't be working on anything else except
                                                      the Sprint Backlog, (which of course came from the
                                                      Product Backlog, and therefore came from
                                                      Customer's priorities).

                                                      I am starting to think the sabbatical is more
                                                      compatible with Scrum, if the activities are
                                                      not related to the customer's needs.

                                                      OTOH, if they are, they should be in the Product
                                                      Backlog, and prioritized and assigned to Sprint
                                                      Backlog like any other task,

                                                      - Mike



                                                      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 the Yahoo! Terms of Service.
                                                    • Paul Clanton
                                                      I think Mike s just touched on one of the major issues. All the good ideas we have been tossing around (and they _are_ all good) depend heavily on the culture
                                                      Message 26 of 29 , Feb 11, 2002
                                                      • 0 Attachment

                                                        I think Mike’s just touched on one of the major issues.  All the good ideas we have been tossing around (and they _are_ all good) depend heavily on the culture of the organization.  What works in one organization may not work in another.  3M’s 15% works because it’s a part of their culture.  The sabbatical worked for me because it fit the culture of the organization I’d worked for at the time.  Mike’s Friday afternoon idea worked with the culture at one place but not another. 

                                                         

                                                        We’re really talking about encouraging innovation.  If the culture doesn’t support innovation then none of what we’re talking about may be possible.  In this case, I would suggest either working very hard to change that culture or starting to look for another job before the company folds!  On the other hand, if the company does support innovation, one of these approaches may be a good solution.

                                                         

                                                        I personally favor the sabbatical approach for the same reasons that I find Scrum works well for me, namely that it promotes a concentrated, uninterrupted time for people to become immersed in something.  However, the central theme is encouraging innovation by allowing people time to do something outside of their regular project tasks and that’s more important than the mechanics.  Find something that works and consistently push at it.

                                                         

                                                        -----Original Message-----
                                                        From: Mike Cohn [mailto:mike@...]
                                                        Sent: Saturday, February 09, 2002 4:15 PM
                                                        To: scrumdevelopment@yahoogroups.com
                                                        Subject: RE: [scrumdevelopment] Re: Splinter Department

                                                         

                                                        You’re right—there can be problems with telling individuals on a team that the Friday afternoon “should” or “must” be spent off the project. I’ve never had a programmer consider it “arm-twisting” though. Usually what happens is that the programmer knows that Friday afternoon is his for anything remotely related to work as long as he has made respectable progress on his assignments and almost every programmer I’ve worked with will do whatever they can to be able to have that time for pursuing their own special interests.

                                                         

                                                        Of course I’ve never truly forced a programmer not to work on the main project and work on outside things. If a project is behind, desperately needs a few hours, or was going to be in a position where people were going to come in over the weekend (rather voluntarily or not) it would be criminal to tell people not to code on Friday but to be in on Saturday. My comment about telling people that I don’t want them to work on the mainline task is more to fully get the point across that they are not going to impress me with their dedication or commitment by working on the project on Friday afternoon in most cases. With most developers it is very hard to convince them of your sincerity when you tell them you would really rather have them with their feet pitched up reading a good book or contributing to an open source project or such for that few hours a week.

                                                         

                                                        Also, I want to be clear that I started my comment with “I’ve dealt with this two ways in the past…”.  While I think giving people dedicated time to pursue beneficial tasks outside the mainline project it is not how I’ve been doing it with teams over the past few years. I actually find it much better to just underallocate tasks to the sprint and establish a culture where people know it is OK to spend a little time each week (as appropriate, depending on where the project is and how the sprint is going) on unplanned tasks. However, it is not easy to establish this as part of the culture in most organizations, usually there’s a CEO or CFO or someone who walks around asking “why isn’t Johnny coding?”

                                                         

                                                        -----Original Message-----
                                                        From: Paul [mailto:horked_noodle@...]
                                                        Sent: Saturday, February 09, 2002 1:43 PM
                                                        To: scrumdevelopment@yahoogroups.com
                                                        Subject: RE: [scrumdevelopment] Re: Splinter Department

                                                         

                                                        You just took a good idea and made it a bad one.  I
                                                        really don't like this arm-twisting idea that every
                                                        Friday you will work on something outside of your
                                                        project.  What happens when spring goals are not being
                                                        met?  The better idea was 3M which leaves the decision
                                                        up to the individual who has other commitments (
                                                        Sprint Goals ).

                                                            -- Paul


                                                        --- Mike Cohn <mike@...> 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

                                                        > -----Original Message-----
                                                        > From: mpoppendieck [mailto:mary@...]
                                                        > Sent: Saturday, February 09,
                                                        2002 9:14 AM
                                                        > To: scrumdevelopment@yahoogroups.com
                                                        > Subject: [scrumdevelopment] Re: Splinter Department

                                                        > When people go home from work, they coach their kids
                                                        > sports or
                                                        > volunteer at church or train for triathlons or
                                                        > engage in other
                                                        > passions.  We certainly don't expect them to give
                                                        > this up for
                                                        > work,
                                                        > except maybe temporarily in a crisis.  Some people
                                                        > come home from
                                                        > working on a Scrum team and work on some Open Source
                                                        > code or put
                                                        > together a database for a boy scout troop, and so
                                                        > on.  The point of
                                                        > the 15% rule is that people who get passionate about
                                                        > something other
                                                        > than their regular jobs (but related to their
                                                        > company interests) are
                                                        > encouraged to pursue the idea while on the job.  By
                                                        > leveraging this
                                                        > kind of passion, 3M gets hundreds of new products
                                                        > every year.
                                                        >
                                                        > I wonder how we can expect every member of a Scrum
                                                        > team to be
                                                        > totally committed to do nothing but work on the
                                                        > backlog over the
                                                        > several months a project might run.  It seems rather
                                                        > pretentious to
                                                        > assume this.  I suspect that a well-led Scrum team
                                                        > will motivate all
                                                        > the team members to work only on the customer
                                                        > backlog.  But if Scrum
                                                        > becomes a way of life in an organization, it seems
                                                        > to me that the
                                                        > organization should admit that some people on some
                                                        > Scrum teams might
                                                        > get distracted and want to do something else some of
                                                        > the time. If
                                                        > they can't do it at work, they will do it at home.
                                                        > 3M provides a
                                                        > simple mechanism to allow everyone some slack, so
                                                        > they can follow
                                                        > their passions at work, and in exchange, the company
                                                        > cashes in on
                                                        > the results.
                                                        >
                                                        > So I would argue that allowing (not scheduling,
                                                        > allowing) slack in
                                                        > everyone's normal schedule, instead of expecting
                                                        > everyone to be
                                                        > 100%
                                                        > committed to what their management wants them to do,
                                                        > is a good
                                                        > thing. 
                                                        >

                                                        >


                                                        __________________________________________________
                                                        Do You Yahoo!?
                                                        Send FREE Valentine eCards with Yahoo! Greetings!
                                                        http://greetings.yahoo.com


                                                        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 the Yahoo! Terms of Service.



                                                        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 the Yahoo! Terms of Service.
                                                      • Jonas Bengtsson
                                                        Hi all, I m going to write a paper about product-lines (for a course called product-line architecture). So I thought of writing about how product-lins are
                                                        Message 27 of 29 , Feb 20, 2002
                                                        • 0 Attachment
                                                          Hi all,

                                                          I'm going to write a paper about product-lines (for a course called
                                                          product-line architecture). So I thought of writing about how product-lins
                                                          are managed in agile development. Most literature I've read state that a
                                                          planned BDUF is the only way to go.
                                                          * Are there any articles etc that describes how to deal with product-lines
                                                          in agile development?
                                                          * Does anyone have any experiences with product-lines in agile development?

                                                          Thanks in advance,
                                                          Jonas
                                                        • mpoppendieck
                                                          Jonas, You might want to check out the following page, titled Lean Design , on my web site: http://www.poppendieck.com/design.htm A good article to check out
                                                          Message 28 of 29 , Feb 21, 2002
                                                          • 0 Attachment
                                                            Jonas,

                                                            You might want to check out the following page, titled 'Lean
                                                            Design', on my web site:

                                                            http://www.poppendieck.com/design.htm

                                                            A good article to check out is "How Microsoft Makes Large Teams Work
                                                            Like Small Teams", Michael Cusumano, Sloan Management Review, Fall
                                                            1997 which is an excerpt of the book "Microsoft Secrets" by the same
                                                            author.

                                                            Another good source of information is material on how Toyota does
                                                            new product development. Since Toyota is by far the most agile
                                                            automobile developer, I think you can learn a lot from how they
                                                            develop products. Some of the more relevant articles are:

                                                            The Second Toyota Paradox: How Delaying Decisions Can Make Better
                                                            Cars Faster, Sloan Management Review, Spring `95, Allen Ward,
                                                            Jeffrey Liker, John Cristiano, Durward Sobek

                                                            Another Look at how Toyota Integrates Product Development, Durward
                                                            Sobek, Jeffrey Liker, Allen Ward, Harvard Business Review, July-
                                                            August, 1998.

                                                            Toyota's Principles of Set-Based Concurrent Engineering, Sloan
                                                            Management Review, Winter `99, Sobek, Allen, Liker

                                                            You basically need access to a business library to get at these
                                                            articles, but they are very good.

                                                            --- In scrumdevelopment@y..., "Jonas Bengtsson" <jonas.b@h...> wrote:
                                                            > Hi all,
                                                            >
                                                            > I'm going to write a paper about product-lines (for a course called
                                                            > product-line architecture). So I thought of writing about how
                                                            product-lins
                                                            > are managed in agile development. Most literature I've read state
                                                            that a
                                                            > planned BDUF is the only way to go.
                                                            > * Are there any articles etc that describes how to deal with
                                                            product-lines
                                                            > in agile development?
                                                            > * Does anyone have any experiences with product-lines in agile
                                                            development?
                                                            >
                                                            > Thanks in advance,
                                                            > Jonas
                                                          • Jonas Bengtsson
                                                            Thank you Mary! I found all the articles except Another Look at how Toyota Integrates Product Development . I will look into all the articles later! /Jonas
                                                            Message 29 of 29 , Feb 25, 2002
                                                            • 0 Attachment
                                                              Thank you Mary!
                                                              I found all the articles except "Another Look at how Toyota Integrates
                                                              Product Development". I will look into all the articles later!

                                                              /Jonas

                                                              > -----Original Message-----
                                                              > From: mpoppendieck [mailto:mary@...]
                                                              > Sent: Thursday, February 21, 2002 10:34 PM
                                                              > To: scrumdevelopment@yahoogroups.com
                                                              > Subject: [scrumdevelopment] Re: Product-lines
                                                              >
                                                              >
                                                              > Jonas,
                                                              >
                                                              > You might want to check out the following page, titled 'Lean
                                                              > Design', on my web site:
                                                              >
                                                              > http://www.poppendieck.com/design.htm
                                                              >
                                                              > A good article to check out is "How Microsoft Makes Large Teams Work
                                                              > Like Small Teams", Michael Cusumano, Sloan Management Review, Fall
                                                              > 1997 which is an excerpt of the book "Microsoft Secrets" by the same
                                                              > author.
                                                              >
                                                              > Another good source of information is material on how Toyota does
                                                              > new product development. Since Toyota is by far the most agile
                                                              > automobile developer, I think you can learn a lot from how they
                                                              > develop products. Some of the more relevant articles are:
                                                              >
                                                              > The Second Toyota Paradox: How Delaying Decisions Can Make Better
                                                              > Cars Faster, Sloan Management Review, Spring `95, Allen Ward,
                                                              > Jeffrey Liker, John Cristiano, Durward Sobek
                                                              >
                                                              > Another Look at how Toyota Integrates Product Development, Durward
                                                              > Sobek, Jeffrey Liker, Allen Ward, Harvard Business Review, July-
                                                              > August, 1998.
                                                              >
                                                              > Toyota's Principles of Set-Based Concurrent Engineering, Sloan
                                                              > Management Review, Winter `99, Sobek, Allen, Liker
                                                              >
                                                              > You basically need access to a business library to get at these
                                                              > articles, but they are very good.
                                                              >
                                                              > --- In scrumdevelopment@y..., "Jonas Bengtsson" <jonas.b@h...> wrote:
                                                              > > Hi all,
                                                              > >
                                                              > > I'm going to write a paper about product-lines (for a course called
                                                              > > product-line architecture). So I thought of writing about how
                                                              > product-lins
                                                              > > are managed in agile development. Most literature I've read state
                                                              > that a
                                                              > > planned BDUF is the only way to go.
                                                              > > * Are there any articles etc that describes how to deal with
                                                              > product-lines
                                                              > > in agile development?
                                                              > > * Does anyone have any experiences with product-lines in agile
                                                              > development?
                                                              > >
                                                              > > Thanks in advance,
                                                              > > Jonas
                                                              >
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.