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

RE: [scrumdevelopment] Re: Splinter Department

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.