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

Break from sprinting - a strategy sprint

Expand Messages
  • bennyou.cpt1
    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
    Message 1 of 19 , Feb 1, 2011
    • 0 Attachment
      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?
    • Dave Rooney
      ... 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
      Message 2 of 19 , Feb 1, 2011
      • 0 Attachment
        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
      • Jon Archer
        We are releasing every quarter and just decided to have an innovation sprint in between each release. Partly to decompress, partly to let people do whatever
        Message 3 of 19 , Feb 1, 2011
        • 0 Attachment
          We are releasing every quarter and just decided to have an "innovation" sprint in between each release. Partly to decompress, partly to let people do whatever they fancy for a bit...only caveat is they have to come back and do a little "show and tell" on what they got up to. We haven't had our first one yet, but I really like the idea and think it will be worthwhile.

          Jon

          On Tue, Feb 1, 2011 at 11:22 AM, 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


        • bennyou.cpt1
          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
          Message 4 of 19 , Feb 1, 2011
          • 0 Attachment
            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
            >
          • Seyit Caglar Abbasoglu
            ... 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
            Message 5 of 19 , Feb 1, 2011
            • 0 Attachment
              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.
            • 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.