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

Re: Break from sprinting - a strategy sprint

Expand Messages
  • David A Barrett
    I think it s a reasonable question. Certainly, I wondered if the constant grind of churning out feature after feature after feature without a break was going
    Message 1 of 19 , Feb 2, 2011
      I think it's a reasonable question.  Certainly, I wondered if the constant grind of churning out feature after feature after feature without a break was going to become a burden in itself.  I can say though, that after 7 years of back to back Sprints without a break burn out has never become a problem.

      My guess is that the trade-offs for the Team members in moving to Scrum are almost all positive.  The Team is now constantly have success, deadlines are all self-imposed and unreasonable customer/user demand can almost always be dealt with by, "We'll have to put that in the Product Backlog".  So yeah, we expect them to deliver a bunch of stuff every month, and as soon as they've got that done we turn around and hand them a new batch of stuff with a new deadline but now it's all set up to succeed.



      Dave Barrett


      This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

      Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
    • bennyou.cpt1
      I like a lot of the answers that I m getting here. I guess some of the reasons why these things are happening is due to the nature of our business, we are an
      Message 2 of 19 , Feb 2, 2011
        I like a lot of the answers that I'm getting here.

        I guess some of the reasons why these things are happening is due to the nature of our business, we are an asset management company and have been around a while. And although having adopted good practices recently this hasn't always been the case.

        The system that we are maintaining and developing new features on top of has many massive moving parts, some of which are legacy and pre-dates 95 percent of the developers still remaining on the product. Product owners have long come and gone, and our one clear vision is the project allows our Client ease of managing their own portfolios.

        Up to now many of the functionality has been working and the integrated legacy parts have been performing adequetly, we've isolated new features of the system in specific contexts as prescribed by good practices employed by DDD and TDD.

        However the old stuff which has been isolated from is starting to get clunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the effort to regression test the size of this be business feasible and this is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees much less visible business value be delivered. Business does not understand the slow down of development of features.

        In and amongst this, we are not a software company so we are not developing the next killer app. We are building in a very limited domain space which after a while developers find boring, hence the content fatigue. Imagine eating the same sandwich every day for 10 years...

        There are many things we are doing right, but at the same time we are losing devs not because of bad company culture but more of the fact that they get bored of the same thing over and over, coincidentally many people left at the same time due to various reasons outside of the company's control. This turnover means that the newbies don't always have a clear picture as to what has been previously been built.

        So a lot of the stuff suggested here seems very intriguing.

        --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
        >
        > I think it's a reasonable question. Certainly, I wondered if the constant
        > grind of churning out feature after feature after feature without a break
        > was going to become a burden in itself. I can say though, that after 7
        > years of back to back Sprints without a break burn out has never become a
        > problem.
        >
        > My guess is that the trade-offs for the Team members in moving to Scrum
        > are almost all positive. The Team is now constantly have success,
        > deadlines are all self-imposed and unreasonable customer/user demand can
        > almost always be dealt with by, "We'll have to put that in the Product
        > Backlog". So yeah, we expect them to deliver a bunch of stuff every
        > month, and as soon as they've got that done we turn around and hand them a
        > new batch of stuff with a new deadline but now it's all set up to succeed.
        >
        >
        >
        > Dave Barrett
        >
        >
        > This e-mail may be privileged and/or confidential, and the sender does not
        > waive any related rights and obligations. Any distribution, use or copying
        > of this e-mail or the information it contains by other than an intended
        > recipient is unauthorized. If you received this e-mail in error, please
        > delete it and advise me (by return e-mail or otherwise) immediately.
        >
        > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
        > renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
        > utilisation ou copie de ce message ou des renseignements qu'il contient
        > par une personne autre que le (les) destinataire(s) désigné(s) est
        > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
        > le supprimer et m'en aviser immédiatement, par retour de courrier
        > électronique ou par un autre moyen.
        >
      • Roy Morien
        I have always had the impression that trying to update a legacy system, in the way that I think you are indicating, can turn into a quick sand swamp of
        Message 3 of 19 , Feb 2, 2011
          I have always had the impression that trying to 'update' a legacy system, in the way that I think you are indicating, can turn into a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
           
          I honestly think that it is usually better to use the legacy system as a 'prototype' for the new system, and, instead of trying to patch the old system, you develop a new system in parallel.
           
          At least, this is the theory of the thing, and is probably a difficult game to sell. But I have really had a lot of experience seeing people trying to 'fix it' when, if they scratched the old and developed the new, with the same intention that the old was developed for, it would save a lot of time.
           
          Regards,
          Roy Morien
           

          To: scrumdevelopment@yahoogroups.com
          From: bennyou.cpt@...
          Date: Wed, 2 Feb 2011 18:34:54 +0000
          Subject: [scrumdevelopment] Re: Break from sprinting - a strategy sprint

           
          I like a lot of the answers that I'm getting here.

          I guess some of the reasons why these things are happening is due to the nature of our business, we are an asset management company and have been around a while. And although having adopted good practices recently this hasn't always been the case.

          The system that we are maintaining and developing new features on top of has many massive moving parts, some of which are legacy and pre-dates 95 percent of the developers still remaining on the product. Product owners have long come and gone, and our one clear vision is the project allows our Client ease of managing their own portfolios.

          Up to now many of the functionality has been working and the integrated legacy parts have been performing adequetly, we've isolated new features of the system in specific contexts as prescribed by good practices employed by DDD and TDD.

          However the old stuff which has been isolated from is starting to get clunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the effort to regression test the size of this be business feasible and this is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees much less visible business value be delivered. Business does not understand the slow down of development of features.

          In and amongst this, we are not a software company so we are not developing the next killer app. We are building in a very limited domain space which after a while developers find boring, hence the content fatigue. Imagine eating the same sandwich every day for 10 years...

          There are many things we are doing right, but at the same time we are losing devs not because of bad company culture but more of the fact that they get bored of the same thing over and over, coincidentally many people left at the same time due to various reasons outside of the company's control. This turnover means that the newbies don't always have a clear picture as to what has been previously been built.

          So a lot of the stuff suggested here seems very intriguing.

          --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
          >
          > I think it's a reasonable question. Certainly, I wondered if the constant
          > grind of churning out feature after feature after feature without a break
          > was going to become a burden in itself. I can say though, that after 7
          > years of back to back Sprints without a break burn out has never become a
          > problem.
          >
          > My guess is that the trade-offs for the Team members in moving to Scrum
          > are almost all positive. The Team is now constantly have success,
          > deadlines are all self-imposed and unreasonable customer/user demand can
          > almost always be dealt with by, "We'll have to put that in the Product
          > Backlog". So yeah, we expect them to deliver a bunch of stuff every
          > month, and as soon as they've got that done we turn around and hand them a
          > new batch of stuff with a new deadline but now it's all set up to succeed.
          >
          >
          >
          > Dave Barrett
          >
          >
          > This e-mail may be privileged and/or confidential, and the sender does not
          > waive any related rights and obligations. Any distribution, use or copying
          > of this e-mail or the information it contains by other than an intended
          > recipient is unauthorized. If you received this e-mail in error, please
          > delete it and advise me (by return e-mail or otherwise) immediately.
          >
          > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
          > renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
          > utilisation ou copie de ce message ou des renseignements qu'il contient
          > par une personne autre que le (les) destinataire(s) désigné(s) est
          > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
          > le supprimer et m'en aviser immédiatement, par retour de courrier
          > électronique ou par un autre moyen.
          >


        • Ron Jeffries
          Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you ... Have you ever been engaged in a project to rewrite a legacy system? I d like to hear about
          Message 4 of 19 , Feb 2, 2011
            Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
            wrote:

            > I have always had the impression that trying to 'update' a legacy
            > system, in the way that I think you are indicating, can turn into
            > a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
            >
            > I honestly think that it is usually better to use the legacy
            > system as a 'prototype' for the new system, and, instead of trying
            > to patch the old system, you develop a new system in parallel.
            >
            > At least, this is the theory of the thing, and is probably a
            > difficult game to sell. But I have really had a lot of experience
            > seeing people trying to 'fix it' when, if they scratched the old
            > and developed the new, with the same intention that the old was
            > developed for, it would save a lot of time.

            Have you ever been engaged in a project to rewrite a legacy system?
            I'd like to hear about the results: your blase presentation of this
            idea tells me that if you've done it, you must know some secrets
            that I do not.

            I have been involved in several conversions, and I would prefer
            never to do it again, even with an Agile approach (but more about
            what I'd do if I had to below). What happens is:

            0. All the following criteria are absolute and highest priority.
            1. We need all the functionality of the old system.
            2. It has to be completely compatible with the old system.
            3. All the bugs have to be fixed.
            4. There are some bugs which, if fixed, would break compatibility.
            5. We have many new features that are absolutely critical.
            6. It has to be much easier to use and better looking, while
            remaining completely compatible.
            7. Conversion from the old system has to be trivially easy,
            absolutely seamless, and perfect.
            8. The situation is time critical. We are already late.
            9. We will be adding a few new important features to the
            old system. We're sure that you won't have any trouble adding
            them to yours. Be sure to watch version reports to find out
            what they are.

            After that, it starts to get really ugly. Every project of this kind
            that I've been involved in turned into a death march where most of
            us would have preferred actual death. Except for one: The Chrysler
            C3 project. It went really well except for being scrapped at the end
            despite that it was working fine.

            Now then. What would I do, faced with this opportunity?

            One possibility: Refactor the old system into a better system. This
            is not easy, as it requires great refactoring skill. However, if you
            do not have great refactoring skill, where do you get off telling us
            you are qualified to rewrite this giant steaming pile to make it
            better.

            Another possibility: Strangle the old app. Implement new
            functionality in a clean way, and eviscerate the old system one bit
            of functionality at a time, calling out to the new. This might
            continue forever; it might be that we'd call it good enough and
            stop; it might be that we would use the momentum of the new stuff
            working to continue forward.

            Yet another possibility: Build a new system as if we were one of our
            competitors. The new system is intended to be so good and so full of
            new capability that it wipes out the market for the old one, without
            ever needing to match it feces for feces.

            Absent any of those possibilities, I'd consider finding gainful
            employment in food services.

            Ron Jeffries
            www.XProgramming.com
            It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
          • Roy Morien
            Let me know which MacDonalds, Ron.
            Message 5 of 19 , Feb 2, 2011
              Let me know which MacDonalds, Ron.
               
              > To: scrumdevelopment@yahoogroups.com
              > From: ronjeffries@...
              > Date: Wed, 2 Feb 2011 19:09:12 -0500
              > Subject: Re: [scrumdevelopment] Re: Break from sprinting - a strategy sprint
              >
              > Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
              > wrote:
              >
              > > I have always had the impression that trying to 'update' a legacy
              > > system, in the way that I think you are indicating, can turn into
              > > a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
              > >
              > > I honestly think that it is usually better to use the legacy
              > > system as a 'prototype' for the new system, and, instead of trying
              > > to patch the old system, you develop a new system in parallel.
              > >
              > > At least, this is the theory of the thing, and is probably a
              > > difficult game to sell. But I have really had a lot of experience
              > > seeing people trying to 'fix it' when, if they scratched the old
              > > and developed the new, with the same intention that the old was
              > > developed for, it would save a lot of time.
              >
              > Have you ever been engaged in a project to rewrite a legacy system?
              > I'd like to hear about the results: your blase presentation of this
              > idea tells me that if you've done it, you must know some secrets
              > that I do not.
              >
              > I have been involved in several conversions, and I would prefer
              > never to do it again, even with an Agile approach (but more about
              > what I'd do if I had to below). What happens is:
              >
              > 0. All the following criteria are absolute and highest priority.
              > 1. We need all the functionality of the old system.
              > 2. It has to be completely compatible with the old system.
              > 3. All the bugs have to be fixed.
              > 4. There are some bugs which, if fixed, would break compatibility.
              > 5. We have many new features that are absolutely critical.
              > 6. It has to be much easier to use and better looking, while
              > remaining completely compatible.
              > 7. Conversion from the old system has to be trivially easy,
              > absolutely seamless, and perfect.
              > 8. The situation is time critical. We are already late.
              > 9. We will be adding a few new important features to the
              > old system. We're sure that you won't have any trouble adding
              > them to yours. Be sure to watch version reports to find out
              > what they are.
              >
              > After that, it starts to get really ugly. Every project of this kind
              > that I've been involved in turned into a death march where most of
              > us would have preferred actual death. Except for one: The Chrysler
              > C3 project. It went really well except for being scrapped at the end
              > despite that it was working fine.
              >
              > Now then. What would I do, faced with this opportunity?
              >
              > One possibility: Refactor the old system into a better system. This
              > is not easy, as it requires great refactoring skill. However, if you
              > do not have great refactoring skill, where do you get off telling us
              > you are qualified to rewrite this giant steaming pile to make it
              > better.
              >
              > Another possibility: Strangle the old app. Implement new
              > functionality in a clean way, and eviscerate the old system one bit
              > of functionality at a time, calling out to the new. This might
              > continue forever; it might be that we'd call it good enough and
              > stop; it might be that we would use the momentum of the new stuff
              > working to continue forward.
              >
              > Yet another possibility: Build a new system as if we were one of our
              > competitors. The new system is intended to be so good and so full of
              > new capability that it wipes out the market for the old one, without
              > ever needing to match it feces for feces.
              >
              > Absent any of those possibilities, I'd consider finding gainful
              > employment in food services.
              >
              > Ron Jeffries
              > www.XProgramming.com
              > It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
              >
              >
              >
              > ------------------------------------
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
              >
              > <*> To visit your group on the web, go to:
              > http://groups.yahoo.com/group/scrumdevelopment/
              >
              > <*> Your email settings:
              > Individual Email | Traditional
              >
              > <*> To change settings online go to:
              > http://groups.yahoo.com/group/scrumdevelopment/join
              > (Yahoo! ID required)
              >
              > <*> To change settings via email:
              > scrumdevelopment-digest@yahoogroups.com
              > scrumdevelopment-fullfeatured@yahoogroups.com
              >
              > <*> To unsubscribe from this group, send an email to:
              > scrumdevelopment-unsubscribe@yahoogroups.com
              >
              > <*> Your use of Yahoo! Groups is subject to:
              > http://docs.yahoo.com/info/terms/
              >
            • Roy Morien
              I have tried to make a contribution to this group, and I do hope that I have had some success. But I am now a little tired of the snipes and barbs that my
              Message 6 of 19 , Feb 2, 2011
              I have tried to make a contribution to this group, and I do hope that I have had some success.
               
              But I am now a little tired of the snipes and barbs that my offerings seem to elicit.
               
              So, I have decided to retire from the field and cease to participate in this group. This may be interpreted as me throwing a hissy fit, or taking my bat and ball and going home, or whatever other motive you may ascribe ... but it doesn't matter.
               
              Ron's latest barb about finding employment in the food industry was just a little too bitchy for me.
               
              So, as the saying is "he was a good cook, as good cooks go, and as good cooks go, he went".
               
              I have attached a couple of files to this final email, for the information of anyone who is interested ... one is a summary set of slides of my various publications and presentations, the other is the full paper I published about adopting agile methods in student projects. Read them if you will, ignore them if you have found my writing to be tedious and only worthy of someone who should be employed at MacDonalds (where, I must say, I have often found friendly, efficient service, so I really don't mean any insult to those good folk).
               
              Regards,
              Roy Morien
               
              > To: scrumdevelopment@yahoogroups.com
              > From: ronjeffries@...
              > Date: Wed, 2 Feb 2011 19:09:12 -0500
              > Subject: Re: [scrumdevelopment] Re: Break from sprinting - a strategy sprint
              >
              > Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
              > wrote:
              >
              > > I have always had the impression that trying to 'update' a legacy
              > > system, in the way that I think you are indicating, can turn into
              > > a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
              > >
              > > I honestly think that it is usually better to use the legacy
              > > system as a 'prototype' for the new system, and, instead of trying
              > > to patch the old system, you develop a new system in parallel.
              > >
              > > At least, this is the theory of the thing, and is probably a
              > > difficult game to sell. But I have really had a lot of experience
              > > seeing people trying to 'fix it' when, if they scratched the old
              > > and developed the new, with the same intention that the old was
              > > developed for, it would save a lot of time.
              >
              > Have you ever been engaged in a project to rewrite a legacy system?
              > I'd like to hear about the results: your blase presentation of this
              > idea tells me that if you've done it, you must know some secrets
              > that I do not.
              >
              > I have been involved in several conversions, and I would prefer
              > never to do it again, even with an Agile approach (but more about
              > what I'd do if I had to below). What happens is:
              >
              > 0. All the following criteria are absolute and highest priority.
              > 1. We need all the functionality of the old system.
              > 2. It has to be completely compatible with the old system.
              > 3. All the bugs have to be fixed.
              > 4. There are some bugs which, if fixed, would break compatibility.
              > 5. We have many new features that are absolutely critical.
              > 6. It has to be much easier to use and better looking, while
              > remaining completely compatible.
              > 7. Conversion from the old system has to be trivially easy,
              > absolutely seamless, and perfect.
              > 8. The situation is time critical. We are already late.
              > 9. We will be adding a few new important features to the
              > old system. We're sure that you won't have any trouble adding
              > them to yours. Be sure to watch version reports to find out
              > what they are.
              >
              > After that, it starts to get really ugly. Every project of this kind
              > that I've been involved in turned into a death march where most of
              > us would have preferred actual death. Except for one: The Chrysler
              > C3 project. It went really well except for being scrapped at the end
              > despite that it was working fine.
              >
              > Now then. What would I do, faced with this opportunity?
              >
              > One possibility: Refactor the old system into a better system. This
              > is not easy, as it requires great refactoring skill. However, if you
              > do not have great refactoring skill, where do you get off telling us
              > you are qualified to rewrite this giant steaming pile to make it
              > better.
              >
              > Another possibility: Strangle the old app. Implement new
              > functionality in a clean way, and eviscerate the old system one bit
              > of functionality at a time, calling out to the new. This might
              > continue forever; it might be that we'd call it good enough and
              > stop; it might be that we would use the momentum of the new stuff
              > working to continue forward.
              >
              > Yet another possibility: Build a new system as if we were one of our
              > competitors. The new system is intended to be so good and so full of
              > new capability that it wipes out the market for the old one, without
              > ever needing to match it feces for feces.
              >
              > Absent any of those possibilities, I'd consider finding gainful
              > employment in food services.
              >
              > Ron Jeffries
              > www.XProgramming.com
              > It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
              >
              >
              >
              > ------------------------------------
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
              >
              > <*> To visit your group on the web, go to:
              > http://groups.yahoo.com/group/scrumdevelopment/
              >
              > <*> Your email settings:
              > Individual Email | Traditional
              >
              > <*> To change settings online go to:
              > http://groups.yahoo.com/group/scrumdevelopment/join
              > (Yahoo! ID required)
              >
              > <*> To change settings via email:
              > scrumdevelopment-digest@yahoogroups.com
              > scrumdevelopment-fullfeatured@yahoogroups.com
              >
              > <*> To unsubscribe from this group, send an email to:
              > scrumdevelopment-unsubscribe@yahoogroups.com
              >
              > <*> Your use of Yahoo! Groups is subject to:
              > http://docs.yahoo.com/info/terms/
              >
            • Ron Jeffries
              Hello, Roy. On Wednesday, February 2, 2011, at 9:03:44 PM, you ... It is a bit hard to see why you would take that personally, since I said the following.
              Message 7 of 19 , Feb 2, 2011
                Hello, Roy. On Wednesday, February 2, 2011, at 9:03:44 PM, you
                wrote:

                > Ron's latest barb about finding employment in the food industry
                > was just a little too bitchy for me.

                It is a bit hard to see why you would take that personally, since I
                said the following. Note, in particular, my use of the word *I*,
                throughout.

                > Now then. What would I do, faced with this opportunity?
                >
                > One possibility: Refactor ...
                >
                > Another possibility: Strangle ...
                >
                > Yet another possibility: Build a new system ...
                >
                > Absent any of those possibilities, I'd consider finding gainful
                > employment in food services.

                I believe also that the yahoo group strips all attachments, so you
                might want to post links to the material you kindly offered.

                Ron Jeffries
                www.XProgramming.com
                Learn from yesterday, live for today, hope for tomorrow.
                The important thing is to not stop questioning. --Albert Einstein
              • Ron Jeffries
                Hello, bennyou.cpt1. On Tuesday, February 1, 2011, at 1:16:42 PM, ... I have heard of teams who did this sort of thing and found it quite useful. I would have
                Message 8 of 19 , Feb 3, 2011
                  Hello, bennyou.cpt1. On Tuesday, February 1, 2011, at 1:16:42 PM,
                  you wrote:

                  > I would like to get the communities opinion on the following:
                  > Assuming that after implementing Scrum the team becomes
                  > self-managing and becomes hyper productive and all that good stuff.

                  > Delivering sprint in and sprint out can almost cause content
                  > fatigue. The team becomes so engaged in developing on the same
                  > project or product that they sometimes lose site of the bigger
                  > picture architecturally.

                  > Has anyone else ever tried or considered breaking in between a
                  > long set of sprints and just regrouping with some sort of strat sprint?

                  > What is the communities thoughts on this?

                  I have heard of teams who did this sort of thing and found it quite
                  useful. I would have no problem with it.

                  Ron Jeffries
                  www.XProgramming.com
                  Do I contradict myself? Very well then I contradict myself.
                  (I am large, I contain multitudes.) --Walt Whitman
                • Charles Bradley - Scrum Coach CSM PSM I
                  bennyou, I tend to favor such practices, though I prefer they be done incrementally, and pretty much continuously. Similar concepts: 1. Google s 20% time
                  Message 9 of 19 , Feb 3, 2011
                    bennyou,

                    I tend to favor such practices, though I prefer they be done incrementally, and pretty much continuously.

                    Similar concepts:
                    1.  Google's 20% time
                    http://www.nytimes.com/2007/10/21/jobs/21pre.html

                    2.The P/PC balance from the "7 Habits" literature
                    http://www.refresher.com/!habits.html >

                    The balance of "production" and "production capability"

                    The Seven Habits are habits of effectiveness. Effectiveness lies in the balance of production of desired results, and the production capability to achieve those desired results; what the author describes as the principle of "P/PC Balance".  Correctly maintaining this balance is often a difficult judgment call; however, failure to do so will jeopardize either one or the other, or both of the elements in the ratio with varying degrees of personal and/or organizational dis-harmony.  An example that comes to mind would be the running down of an organization's human and/or physical assets (production capability) to inflate earnings per share (production) in the short term. 

                    </snip >


                    3.  Slack Time
                    http://www.tdan.com/view-book-reviews/5591

                    I think all of these concepts apply directly to software development, Scrum, and specifically the [Scrum] Development Team's right and responsibility to self organize.


                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/



                    From: Ron Jeffries <ronjeffries@...>
                    To: scrumdevelopment@yahoogroups.com
                    Sent: Thu, February 3, 2011 7:10:48 AM
                    Subject: Re: [scrumdevelopment] Break from sprinting - a strategy sprint

                     

                    Hello, bennyou.cpt1. On Tuesday, February 1, 2011, at 1:16:42 PM,
                    you wrote:

                    > I would like to get the communities opinion on the following:
                    > Assuming that after implementing Scrum the team becomes
                    > self-managing and becomes hyper productive and all that good stuff.

                    > Delivering sprint in and sprint out can almost cause content
                    > fatigue. The team becomes so engaged in developing on the same
                    > project or product that they sometimes lose site of the bigger
                    > picture architecturally.

                    > Has anyone else ever tried or considered breaking in between a
                    > long set of sprints and just regrouping with some sort of strat sprint?

                    > What is the communities thoughts on this?

                    I have heard of teams who did this sort of thing and found it quite
                    useful. I would have no problem with it.

                    Ron Jeffries
                    www.XProgramming.com
                    Do I contradict myself? Very well then I contradict myself.
                    (I am large, I contain multitudes.) --Walt Whitman

                  • Jussi Mäkelä
                    Hi, I know a company that runs three-week sprints, the last day of the sprint is always dedicated for learning, tinkering etc. It seems to work very nicely,
                    Message 10 of 19 , Feb 3, 2011
                      Hi,


                      I know a company that runs three-week sprints, the last day of the sprint is always dedicated for learning, tinkering etc. It seems to work very nicely, it's a nice break from the "normal" stuff and you get to focus on things that you find interesting. I think it's a wonderful idea, however I'm not sure if it's something what you are after. Give it a try at least!

                      /Jussi

                      2011/2/1 bennyou.cpt1 <bennyou.cpt@...>
                       

                      Hi,

                      I would like to get the communities opinion on the following:
                      Assuming that after implementing Scrum the team becomes self-managing and becomes hyper productive and all that good stuff.

                      Delivering sprint in and sprint out can almost cause content fatigue. The team becomes so engaged in developing on the same project or product that they sometimes lose site of the bigger picture architecturally.

                      Has anyone else ever tried or considered breaking in between a long set of sprints and just regrouping with some sort of strat sprint?

                      What is the communities thoughts on this?


                    Your message has been successfully submitted and would be delivered to recipients shortly.