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

Re: [scrumdevelopment] Break from sprinting - a strategy sprint

Expand Messages
  • Alan Dayley
    Some teams create a culture of sharing via events. - Tech Talks are held at least once a sprint to describe new architecture, invite stakeholders to present
    Message 1 of 19 , Feb 1, 2011
    • 0 Attachment
      Some teams create a culture of sharing via events.

      - "Tech Talks" are held at least once a sprint to describe new architecture, invite stakeholders to present or do deep design discussions.  Topics for the talks are either naturally needed based on the product communication needs, are suggested by team members and management or someone volunteers do fill a needed gap of knowledge.  Time box: One hour.

      - Learning Lunches are held once a month.  2-3 people offer to present on anything (gardening, photography, pinball machine collecting and repair, book review, whatever).  Everyone brings their lunch or chips in to have pizza delivered.

      - Design and code reviews are scheduled with standing appointments, four per sprint.  During Sprint Planning or in the daily meeting people step forward to have their work reviewed and a primary reviewer is set.  The whole team is welcome to attend if they are interested.  Time box: 1 hour.  Continue the review in another session if needed.  Reviews over an hour tend to loose value quickly.

      All of the above events are also open to people outside the particular team that is providing the content.  Cross-team attendance is very frequent.

      Innovation sprints and other ideas already presented are also good ideas.  I also agree that loosing sight of the architecture is a problem that should be solved by changing in-sprint behavior.  The architecture and other "bigger picture" views of the product should be part of every sprint, not just at special times.

      Alan 

      On Tue, Feb 1, 2011 at 12:42 PM, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
       

      The team becomes so engaged in developing on the same project or product that they sometimes lose site of the bigger picture architecturally.

      IMO this is dangerous and should not be allowed. And if a team really lost site of architecture, it might be really hard to get back line in just one sprint on a long running project.

      But I always loved the idea of an innovation week. Where members of team (either individually or in groups) make something which they just want to do, for one week. Might be a small tool, or might be a technology spike. Just something they can start from scratch with all the experience they got from previous sprints.

      Playing on the same code base (even it would be brilliant) is just boring sometimes.


    • wolfgangwiedenroth
      I like your analogy, because the answer to your question lies within it. There are two possibilities while driving by map. 1. You have a navigator telling you
      Message 2 of 19 , Feb 1, 2011
      • 0 Attachment
        I like your analogy, because the answer to your question lies within it. There are two possibilities while driving by map.

        1. You have a navigator telling you whether you are still on track or not and telling where to go next.
        2. You stop your car and take a look at the map.

        Scrum has both possibilities, though the first is not really fully covered. The second is the real answer.

        1. The Product Owner controls the map and corrects the path the product is heading. I know you are talking about the architecure, but that's why I said it not fully covered.

        2. Every sprint is timeboxed so there are planned breaks for the team, where they got the oppurtinity to take a look at the map. First time in the Sprint Review and later on in the Sprint Planning, where they are able to adjust their course.

        So there is no need for an extra break or "adjustment sprint" just as much there shouldn't be a need for "bugfix sprints" before a release.

        The team should be working in a sustainable pace to have enough time to plan their path.


        Regards,
        Wolfgang Wiedenroth
        blog: http://www.agilemanic.com
        twitter: @wwiedenroth


        --- In scrumdevelopment@yahoogroups.com, "bennyou.cpt1" <bennyou.cpt@...> wrote:
        >
        > I guess this could be for a number of reasons, but let's say for example a project has had quite a long life cycle and most of the people who have implemented have left.
        >
        > The technologies chosen in the past although right at the time might be become outdated and perhaps with the growth in the volumes of data as well as users now are starting to surface as problems. And let's say the team have stuck to good architectural practices and created a low coupled system where they can swop out infrastructure. The choice to replace such infrastructure could be a critical business decision, one perhaps not always best made by business, do we write our own, do we find a expensive but responsive vendor etc etc
        >
        > I understand the relentlessness of refactoring and gaining a deeper understanding in-sprint, but with a sprint to sprint to sprint approach sometimes it just seems all these decisions are made just in time and maybe they are not the best ones. They are just made to get a story done.
        >
        > The analogy I like using is that it's difficult to look at a map while you're driving. Sometimes one needs to stop regroup and make sure they are on the right road.
        >
        > --- In scrumdevelopment@yahoogroups.com, Dave Rooney <dave.rooney@> wrote:
        > >
        > > On 01/02/2011 1:16 PM, bennyou.cpt1 wrote:
        > > > 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?
        > > >
        > >
        > > My first thought is, "Why has the team lost sight of the bigger picture
        > > architecturally?" Why hasn't that been a consideration during all sprints?
        > > --
        > > Dave Rooney
        > > Westboro Systems
        > > Web: http://www.WestboroSystems.com
        > > Blog: http://practicalagility.blogspot.com
        > > Twitter: daverooneyca
        > >
        >
      • Paul Hudson
        What does your PO think of the idea? ... -- Sent from my mobile device
        Message 3 of 19 , Feb 1, 2011
        • 0 Attachment
          What does your PO think of the idea?

          On 01/02/2011, bennyou.cpt1 <bennyou.cpt@...> wrote:
          > I guess this could be for a number of reasons, but let's say for example a
          > project has had quite a long life cycle and most of the people who have
          > implemented have left.
          >
          > The technologies chosen in the past although right at the time might be
          > become outdated and perhaps with the growth in the volumes of data as well
          > as users now are starting to surface as problems. And let's say the team
          > have stuck to good architectural practices and created a low coupled system
          > where they can swop out infrastructure. The choice to replace such
          > infrastructure could be a critical business decision, one perhaps not always
          > best made by business, do we write our own, do we find a expensive but
          > responsive vendor etc etc
          >
          > I understand the relentlessness of refactoring and gaining a deeper
          > understanding in-sprint, but with a sprint to sprint to sprint approach
          > sometimes it just seems all these decisions are made just in time and maybe
          > they are not the best ones. They are just made to get a story done.
          >
          > The analogy I like using is that it's difficult to look at a map while
          > you're driving. Sometimes one needs to stop regroup and make sure they are
          > on the right road.
          >
          > --- In scrumdevelopment@yahoogroups.com, Dave Rooney <dave.rooney@...>
          > wrote:
          >>
          >> On 01/02/2011 1:16 PM, bennyou.cpt1 wrote:
          >> > 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?
          >> >
          >>
          >> My first thought is, "Why has the team lost sight of the bigger picture
          >> architecturally?" Why hasn't that been a consideration during all
          >> sprints?
          >> --
          >> Dave Rooney
          >> Westboro Systems
          >> Web: http://www.WestboroSystems.com
          >> Blog: http://practicalagility.blogspot.com
          >> Twitter: daverooneyca
          >>
          >
          >
          >

          --
          Sent from my mobile device
        • Roy Morien
          This is a strange question ... content fatigue ... delivering sprint in and sprint out ...lose sight of the bigger picture architecturally. First, I would
          Message 4 of 19 , Feb 1, 2011
          • 0 Attachment
            This is a strange question ... content fatigue ... delivering sprint in and sprint out ...lose sight of the bigger picture architecturally.
             
            First, I would wonder if the team ever had a Vision Phase, where the worth and value of the project was made clear. And if things have changed so much since then that a new vision needs to be created.
             
            I ask myself 'What is this 'architecture' that is being lost sight of?'.
             
            And what is this 'fatigue'? Is the team being pressured and stressed for various reasons? Are they being denied their good and proper leisure time by being required to work excessive overtime or weekends? Or is the team just somehow fed up with it all, for whatever reason?
             
            Somehow this posting also reminded me of an article I read recently, about the FBI's Sentinel project ... a train on its way to a wreck.
            http://www.informationweek.com/news/government/enterprise-apps/showArticle.jhtml?articleID=224400547
             
            Mueller chalked the problems up partially to the project's long development time. " When you have a project that was laid down in concrete four or five years ago, [with] technology changes, business practice changes, and complexity changes, one can expect some minor delays," he said.
             
            Bold highlighting are mine.
             
            Also, just for fun, have a look at some other articles about the same ball game.
            http://www.fiercegovernmentit.com/story/report-questions-fbis-ability-implement-agile-development-sentinel/2010-12-05
            http://adtmag.com/articles/2011/01/10/problems-with-fbi-approach-to-agile.aspxx
             
            Is this the sort of thing that has happened to you, bennyou?
             
            Or maybe you just need a few team activities like Saturday afternoon in the park, frisbee competition, barbeque, beer provided, bring the kids ... let's have some fun ... and please wear the new team project T-Shirt that we just gave you.
             
            Regards,
            Roy Morien
             

            To: scrumdevelopment@yahoogroups.com
            From: bennyou.cpt@...
            Date: Tue, 1 Feb 2011 18:16:42 +0000
            Subject: [scrumdevelopment] Break from sprinting - a strategy sprint

             
            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?


          • 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 5 of 19 , Feb 2, 2011
            • 0 Attachment
              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 6 of 19 , Feb 2, 2011
              • 0 Attachment
                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 7 of 19 , Feb 2, 2011
                • 0 Attachment
                  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 8 of 19 , Feb 2, 2011
                  • 0 Attachment
                    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 9 of 19 , Feb 2, 2011
                    • 0 Attachment
                      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 10 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 11 of 19 , Feb 2, 2011
                      • 0 Attachment
                        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 12 of 19 , Feb 3, 2011
                        • 0 Attachment
                          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 13 of 19 , Feb 3, 2011
                          • 0 Attachment
                            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 14 of 19 , Feb 3, 2011
                            • 0 Attachment
                              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.