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

Re: [scrumdevelopment] Well done waterfall+agile

Expand Messages
  • Eric Tiongson
    Agree with what Michael said, you ll just find yourself in a heap of trouble if you do that. However you can still use agile practices (not processes) within a
    Message 1 of 27 , Nov 8, 2012
    • 0 Attachment
      Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

      However you can still use agile practices (not processes) within a waterfall processes.

      Sent from my iPhone

      On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

       

      No.

      Don't do this.

      If you want to do waterfall. Just do that.

      Good luck.

      Don't fake it.

      Mike Vizdos

      On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
       

      Hi all,

      I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

      I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

      Could you point to those articles or papers, or experiences?

      Thank you very much in advance.

    • Ashish Mahajan
      Agreed. If you are good at swimming in water(fall),fine. If you are good at cycling(scrum cycles), fine. But trying cycling in water may be fatal. Regards
      Message 2 of 27 , Nov 8, 2012
      • 0 Attachment
        Agreed.
        If you are good at swimming in water(fall),fine.
        If you are good at cycling(scrum cycles), fine.
        But trying cycling in water may be fatal.

        Regards
        Ashish
        Sent from my BlackBerry® smartphone

        From: Eric Tiongson <tiongks@...>
        Sender: scrumdevelopment@yahoogroups.com
        Date: Fri, 9 Nov 2012 13:12:37 +0800
        To: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
        ReplyTo: scrumdevelopment@yahoogroups.com
        Cc: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
        Subject: Re: [scrumdevelopment] Well done waterfall+agile

         

        Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

        However you can still use agile practices (not processes) within a waterfall processes.

        Sent from my iPhone

        On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

         

        No.

        Don't do this.

        If you want to do waterfall. Just do that.

        Good luck.

        Don't fake it.

        Mike Vizdos

        On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
         

        Hi all,

        I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

        I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

        Could you point to those articles or papers, or experiences?

        Thank you very much in advance.

      • Dan Greening
        Hi Eric, Everyone is saying Don t do it. I agree, but I ll try to explain why. There are MANY well-meaning people who think they can be the First People Ever
        Message 3 of 27 , Nov 8, 2012
        • 0 Attachment
          Hi Eric,

          Everyone is saying "Don't do it." I agree, but I'll try to explain why.

          There are MANY well-meaning people who think they can be the First People Ever to combine waterfall and Scrum, name their new process with some catchy name, start teaching this Frankenstein system, then cause internal organizational chaos or sloth.

          It comes from a serious misunderstanding of what agile/Scrum methods are.  They are a form of production science, where you measure end-user value production in short, fixed iterations, then use your measurements to diagnose problems, adjust your production methods and forecast.  Waterfall's long production cycles make it impossible to do this feasibly 

          You may think that Frankenprocess (waterfall + Scrum) can first measure design, then measure development, then measure testing, then measure deployment. The problem is that these measurements don't help highlight the high-risk items fast enough to avoid disaster.  You certainly can't forecast delivery time with them because, with Frankenprocess (as with waterfall), you haven't tried/measured any of the later stages when you formulate your early forecasts. You've just guessed. That's what waterfall is: a bunch of unproven guesses with no early verification/correction where you bet the project outcome on your guesses.

          You may think you can do mini-waterfall, like a series of 4 two-week Scrum sprints where the last sprint is, say, testing and deployment. If you do that, you basically have created an 8-week Sprint. The velocities of the first 3 sprints are meaningless. You have no certainty that the 4th Sprint will actually be shippable, so you can't rely on any of the velocities in the first three Sprints to forecast or diagnose. Finally, you dictate different processes in different Sprints and therefore lose the flow and rhythm of highly-effective teamwork where the whole team tries to get something shippable together.

          I tried to write this explanation as succinctly as possible. I hope this helps. 

          Dan Greening
          Managing Director, Evolve Beyond LLC
          Email: dgreening@..., Phone: +1 (415) 754-8311, Skypeid: drgreening, Site: http://evolvebeyond.com


          On Fri, Nov 9, 2012 at 6:21 AM, Ashish Mahajan <agileashish@...> wrote:
           

          Agreed.
          If you are good at swimming in water(fall),fine.
          If you are good at cycling(scrum cycles), fine.
          But trying cycling in water may be fatal.

          Regards
          Ashish

          Sent from my BlackBerry® smartphone

          From: Eric Tiongson <tiongks@...>
          Date: Fri, 9 Nov 2012 13:12:37 +0800
          Subject: Re: [scrumdevelopment] Well done waterfall+agile

           

          Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

          However you can still use agile practices (not processes) within a waterfall processes.

          Sent from my iPhone

          On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

           

          No.

          Don't do this.

          If you want to do waterfall. Just do that.

          Good luck.

          Don't fake it.

          Mike Vizdos

          On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
           

          Hi all,

          I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

          I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

          Could you point to those articles or papers, or experiences?

          Thank you very much in advance.


        • Dinesh Sharma
          So you want to follow RUP right?   Thanks & Regards, Dinesh Sharma ________________________________ From: Ashish Mahajan To:
          Message 4 of 27 , Nov 9, 2012
          • 0 Attachment
            So you want to follow RUP right?
             
            Thanks & Regards,
            Dinesh Sharma

            From: Ashish Mahajan <agileashish@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Friday, 9 November 2012, 5:21
            Subject: Re: [scrumdevelopment] Well done waterfall+agile

             
            Agreed.
            If you are good at swimming in water(fall),fine.
            If you are good at cycling(scrum cycles), fine.
            But trying cycling in water may be fatal.

            Regards
            Ashish
            Sent from my BlackBerry® smartphone

            From: Eric Tiongson <tiongks@...>
            Sender: scrumdevelopment@yahoogroups.com
            Date: Fri, 9 Nov 2012 13:12:37 +0800
            To: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
            ReplyTo: scrumdevelopment@yahoogroups.com
            Cc: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
            Subject: Re: [scrumdevelopment] Well done waterfall+agile

             
            Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

            However you can still use agile practices (not processes) within a waterfall processes.

            Sent from my iPhone

            On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

             
            No.
            Don't do this.
            If you want to do waterfall. Just do that.
            Good luck.
            Don't fake it.
            Mike Vizdos
            On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
             
            Hi all,

            I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

            I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

            Could you point to those articles or papers, or experiences?

            Thank you very much in advance.



          • Cass Dalton
            But you can learn from the agile community and greatly improve your waterfall process: - Use automated tests; and make sure they are easy to run, quickly
            Message 5 of 27 , Nov 9, 2012
            • 0 Attachment
              But you can learn from the agile community and greatly improve your waterfall process:
               - Use automated tests; and make sure they are easy to run, quickly identify specifics of a problem, and are run frequently.
               - Use continuous integration;  Check in frequently and fix problems as soon as they appear. DON'T EVER ACCEPT BROKEN BUILDS


              On Fri, Nov 9, 2012 at 12:21 AM, Ashish Mahajan <agileashish@...> wrote:
               

              Agreed.
              If you are good at swimming in water(fall),fine.
              If you are good at cycling(scrum cycles), fine.
              But trying cycling in water may be fatal.

              Regards
              Ashish

              Sent from my BlackBerry® smartphone

              From: Eric Tiongson <tiongks@...>
              Date: Fri, 9 Nov 2012 13:12:37 +0800
              Subject: Re: [scrumdevelopment] Well done waterfall+agile

               

              Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

              However you can still use agile practices (not processes) within a waterfall processes.

              Sent from my iPhone

              On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

               

              No.

              Don't do this.

              If you want to do waterfall. Just do that.

              Good luck.

              Don't fake it.

              Mike Vizdos

              On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
               

              Hi all,

              I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

              I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

              Could you point to those articles or papers, or experiences?

              Thank you very much in advance.


            • Cass Dalton
              Oops, hit send instead of enter... - Bring your developers closer to the stakeholders; get devs involved in the requirements analysis - Ensure that development
              Message 6 of 27 , Nov 9, 2012
              • 0 Attachment
                Oops, hit send instead of enter...
                 - Bring your developers closer to the stakeholders; get devs involved in the requirements analysis
                 - Ensure that development isn't "done" until something is tested in a deployed environment
                 - Break down work into small bite sized chunks;  Everything everyone in the community says about small user stories (INVEST) can be applied to any work.
                 - Integrate a feature all the way to the end before adding a new one
                 - Embed the benefits of an iterative, empirical approach into your process;  Get something tangible in front of stakeholders early.  Call it a prototype if you want, just build something before you design everything.

                You will get much more benefit from improving your development philosophy and culture that you will from your process.  


                On Fri, Nov 9, 2012 at 6:57 AM, Cass Dalton <cassdalton73@...> wrote:
                But you can learn from the agile community and greatly improve your waterfall process:
                 - Use automated tests; and make sure they are easy to run, quickly identify specifics of a problem, and are run frequently.
                 - Use continuous integration;  Check in frequently and fix problems as soon as they appear. DON'T EVER ACCEPT BROKEN BUILDS


                On Fri, Nov 9, 2012 at 12:21 AM, Ashish Mahajan <agileashish@...> wrote:
                 

                Agreed.
                If you are good at swimming in water(fall),fine.
                If you are good at cycling(scrum cycles), fine.
                But trying cycling in water may be fatal.

                Regards
                Ashish

                Sent from my BlackBerry® smartphone

                From: Eric Tiongson <tiongks@...>
                Date: Fri, 9 Nov 2012 13:12:37 +0800
                Subject: Re: [scrumdevelopment] Well done waterfall+agile

                 

                Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

                However you can still use agile practices (not processes) within a waterfall processes.

                Sent from my iPhone

                On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

                 

                No.

                Don't do this.

                If you want to do waterfall. Just do that.

                Good luck.

                Don't fake it.

                Mike Vizdos

                On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
                 

                Hi all,

                I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

                I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

                Could you point to those articles or papers, or experiences?

                Thank you very much in advance.



              • woynam
                Actually, the latest episode of Mythbusters demonstrated that it is possible to cycle under water. Just don t try going uphill. :-) I agree with the others.
                Message 7 of 27 , Nov 9, 2012
                • 0 Attachment
                  Actually, the latest episode of Mythbusters demonstrated that it is possible to cycle under water. 'Just don't try going uphill. :-)

                  I agree with the others. If you're crazy enough to sign a fixed bid contract to execute a fixed scope project, then you're going to have to face the music. There's nothing agile about this. I guarantee you that if you attempt to apply an agile label to this effort, when it crashed and burns (95% certainty), waterfall will not get the blame. It will all be agile's fault.

                  Mark


                  --- In scrumdevelopment@yahoogroups.com, "Ashish Mahajan" <agileashish@...> wrote:
                  >
                  > Agreed.
                  > If you are good at swimming in water(fall),fine.
                  > If you are good at cycling(scrum cycles), fine.
                  > But trying cycling in water may be fatal.
                  >
                  > Regards
                  > Ashish
                  > Sent from my BlackBerry® smartphone
                  >
                  > -----Original Message-----
                  > From: Eric Tiongson <tiongks@...>
                  > Sender: scrumdevelopment@yahoogroups.com
                  > Date: Fri, 9 Nov 2012 13:12:37
                  > To: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                  > Reply-To: scrumdevelopment@yahoogroups.com
                  > Cc: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                  > Subject: Re: [scrumdevelopment] Well done waterfall+agile
                  >
                  > Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.
                  >
                  > However you can still use agile practices (not processes) within a waterfall processes.
                  >
                  > Sent from my iPhone
                  >
                  > On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:
                  >
                  > > No.
                  > >
                  > > Don't do this.
                  > >
                  > > If you want to do waterfall. Just do that.
                  > >
                  > > Good luck.
                  > >
                  > > Don't fake it.
                  > >
                  > > Mike Vizdos
                  > >
                  > > On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
                  > >>
                  > >> Hi all,
                  > >>
                  > >> I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.
                  > >>
                  > >> I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.
                  > >>
                  > >> Could you point to those articles or papers, or experiences?
                  > >>
                  > >> Thank you very much in advance.
                  > >
                  > >
                  >
                • Adam Sroka
                  The actual business question is can we deliver what the customer wants in the timeframe they want it and still make money? However you figure that out it is an
                  Message 8 of 27 , Nov 9, 2012
                  • 0 Attachment
                    The actual business question is can we deliver what the customer wants in the timeframe they want it and still make money? However you figure that out it is an interesting question. 

                    The problem with the suggested approach is that it is a lot like the tale of the Emperor's New Clothes. We are crafting a plan that we all know is bullshit and trying to fudge it in such a way that none of us looks like the guy who got it wrong. But, in actual fact we all know that it is bullshit and that there's no possible way it is going to go down exactly like we are saying.

                    I used to think that something was wrong with everyone else, but over the years I have begun to understand that it is actually me. For some reason normal people think it is okay to do things that don't make any sense if someone is paying them to do it. I am pathologically incapable of that. 

                    On Fri, Nov 9, 2012 at 6:49 AM, woynam <woyna@...> wrote:
                     


                    Actually, the latest episode of Mythbusters demonstrated that it is possible to cycle under water. 'Just don't try going uphill. :-)

                    I agree with the others. If you're crazy enough to sign a fixed bid contract to execute a fixed scope project, then you're going to have to face the music. There's nothing agile about this. I guarantee you that if you attempt to apply an agile label to this effort, when it crashed and burns (95% certainty), waterfall will not get the blame. It will all be agile's fault.

                    Mark



                    --- In scrumdevelopment@yahoogroups.com, "Ashish Mahajan" <agileashish@...> wrote:
                    >
                    > Agreed.
                    > If you are good at swimming in water(fall),fine.
                    > If you are good at cycling(scrum cycles), fine.
                    > But trying cycling in water may be fatal.
                    >
                    > Regards
                    > Ashish
                    > Sent from my BlackBerry® smartphone

                    >
                    > -----Original Message-----
                    > From: Eric Tiongson <tiongks@...>
                    > Sender: scrumdevelopment@yahoogroups.com
                    > Date: Fri, 9 Nov 2012 13:12:37
                    > To: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                    > Reply-To: scrumdevelopment@yahoogroups.com
                    > Cc: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                    > Subject: Re: [scrumdevelopment] Well done waterfall+agile
                    >
                    > Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.
                    >
                    > However you can still use agile practices (not processes) within a waterfall processes.
                    >
                    > Sent from my iPhone
                    >
                    > On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:
                    >
                    > > No.
                    > >
                    > > Don't do this.
                    > >
                    > > If you want to do waterfall. Just do that.
                    > >
                    > > Good luck.
                    > >
                    > > Don't fake it.
                    > >
                    > > Mike Vizdos
                    > >
                    > > On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
                    > >>
                    > >> Hi all,
                    > >>
                    > >> I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

                    > >>
                    > >> I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.
                    > >>
                    > >> Could you point to those articles or papers, or experiences?
                    > >>
                    > >> Thank you very much in advance.
                    > >
                    > >
                    >


                  • woynam
                    Yea, we all know that the folks in the agile community are just a bunch of misfit troublemakers. :-) The software development industry was going along just
                    Message 9 of 27 , Nov 9, 2012
                    • 0 Attachment
                      Yea, we all know that the folks in the agile community are just a bunch of misfit troublemakers. :-)

                      The software development industry was going along just fine until the signers of the Agile Manifesto decided to apply a bit of empiricism to the process, and it's been down hill ever since.

                      Large consulting firms made billions using waterfall. They didn't actually produce anything of value for their customers, (well, not without a crap load of lucrative change orders), but hey, it worked out well for them.

                      Mark

                      --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                      >
                      > The actual business question is can we deliver what the customer wants in
                      > the timeframe they want it and still make money? However you figure that
                      > out it is an interesting question.
                      >
                      > The problem with the suggested approach is that it is a lot like the tale
                      > of the Emperor's New Clothes. We are crafting a plan that we all know is
                      > bullshit and trying to fudge it in such a way that none of us looks like
                      > the guy who got it wrong. But, in actual fact we all know that it is
                      > bullshit and that there's no possible way it is going to go down exactly
                      > like we are saying.
                      >
                      > I used to think that something was wrong with everyone else, but over the
                      > years I have begun to understand that it is actually me. For some reason
                      > normal people think it is okay to do things that don't make any sense if
                      > someone is paying them to do it. I am pathologically incapable of that.
                      >
                      > On Fri, Nov 9, 2012 at 6:49 AM, woynam <woyna@...> wrote:
                      >
                      > > **
                      > >
                      > >
                      > >
                      > > Actually, the latest episode of Mythbusters demonstrated that it is
                      > > possible to cycle under water. 'Just don't try going uphill. :-)
                      > >
                      > > I agree with the others. If you're crazy enough to sign a fixed bid
                      > > contract to execute a fixed scope project, then you're going to have to
                      > > face the music. There's nothing agile about this. I guarantee you that if
                      > > you attempt to apply an agile label to this effort, when it crashed and
                      > > burns (95% certainty), waterfall will not get the blame. It will all be
                      > > agile's fault.
                      > >
                      > > Mark
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, "Ashish Mahajan" <agileashish@>
                      > > wrote:
                      > > >
                      > > > Agreed.
                      > > > If you are good at swimming in water(fall),fine.
                      > > > If you are good at cycling(scrum cycles), fine.
                      > > > But trying cycling in water may be fatal.
                      > > >
                      > > > Regards
                      > > > Ashish
                      > > > Sent from my BlackBerry® smartphone
                      > >
                      > > >
                      > > > -----Original Message-----
                      > > > From: Eric Tiongson <tiongks@>
                      > > > Sender: scrumdevelopment@yahoogroups.com
                      > > > Date: Fri, 9 Nov 2012 13:12:37
                      > > > To: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                      > > > Reply-To: scrumdevelopment@yahoogroups.com
                      > > > Cc: scrumdevelopment@yahoogroups.com<scrumdevelopment@yahoogroups.com>
                      > > > Subject: Re: [scrumdevelopment] Well done waterfall+agile
                      > > >
                      > > > Agree with what Michael said, you'll just find yourself in a heap of
                      > > trouble if you do that.
                      > > >
                      > > > However you can still use agile practices (not processes) within a
                      > > waterfall processes.
                      > > >
                      > > > Sent from my iPhone
                      > > >
                      > > > On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@> wrote:
                      > > >
                      > > > > No.
                      > > > >
                      > > > > Don't do this.
                      > > > >
                      > > > > If you want to do waterfall. Just do that.
                      > > > >
                      > > > > Good luck.
                      > > > >
                      > > > > Don't fake it.
                      > > > >
                      > > > > Mike Vizdos
                      > > > >
                      > > > > On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@> wrote:
                      > > > >>
                      > > > >> Hi all,
                      > > > >>
                      > > > >> I am looking for articles or papers that talk about the details of
                      > > how to successfully execute a development project with a waterfall façade
                      > > to the upper-management layer and an agile approach for the development
                      > > team. All is new in the project: the team, the users, the application, the
                      > > technology. Note that with «waterfall» I mean strict sequential stages of
                      > > requirements, analysis, design, coding, testing, deployment to production,
                      > > and three months of maintenance; along with a fixed-price/fixed-scope
                      > > contract, and a single Gantt chart as part of the signed contract. This
                      > > Gantt chart will work as the criteria for payments at the end of each stage
                      > > against stated deliverables in the contract.
                      > >
                      > > > >>
                      > > > >> I have heard, from time to time, that some teams have done precisely
                      > > that and very well done. Yet, I have not checked the evidence to believe it.
                      > > > >>
                      > > > >> Could you point to those articles or papers, or experiences?
                      > > > >>
                      > > > >> Thank you very much in advance.
                      > > > >
                      > > > >
                      > > >
                      > >
                      > >
                      > >
                      >
                    • Jose Solera
                      I beg to disagree with those who say not to do it. If you have to, you have to. I had to do it once (no choice, believe me!) What I did: I layered an approach
                      Message 10 of 27 , Nov 9, 2012
                      • 0 Attachment
                        I beg to disagree with those who say not to do it. If you have to, you have to. I had to do it once (no choice, believe me!)

                        What I did: I layered an approach developed at Intel for their semiconductor design projects and now known as "Commitment Based Project Management" or CBPM for short. It is a domain-agnostic (it's been used not only in semiconductor design and software development, but also construction, defense projects, medical device development, education, event-planning, and numerous other domains).

                        It starts with what we call "map days". These are planning days through which the entire team develops a rolling plan. Details are planned as far out as the team is comfortable with, typically 6-8 weeks. Owners make commitments as to when they'll deliver an item. They work with the consumers or users of these deliverables to ensure agreement on what is being delivered. Subsequent map days are scheduled, one at a time, at the end of the previous map day.

                        Regularly (at least three times a week some times daily) progress is reviewed and adjustments made to the plans. Issues are encouraged to be brought to light as soon as possible.

                        Deliverables and status are tracked through an automated Excel spreadsheet.

                        More details are available in Timm Esque's book describing its development: No Surprises Project Management, at the LinkedIn group Project Acceleration thru Commitment Based Project Management (http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops that Timm and I deliver, in a white paper I published (let me know if you are interested), in Timm's company website (http://ensemblemc.com/) and in a white paper he's published (http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf).

                        To get back to my story: I had to use a home-grown waterfall methodology. We planned the effort using CBPM, avoided saying yes to the unrealistic date requested by the customer by demonstrating its impossibility in the first map day, made a commitments early on (second map day since we needed to see if we could deliver portions of the software -- Agile!) and hit each and everyone of our commitments on the nose. "There were no fires!" was the best comment I heard.

                        Would I use this instead of Scrum or XP? No! Those approaches are designed for software development. But if I have to use waterfall, yes. Or for some other less-SW-development time of IT projects such as migrating applications to a new security system, deploying servers, etc.

                        Contact me or Timm (through his website) if you want more details.

                        All the best,

                        Jose Solera, MBA, PMP®, CSM, CSPO, CSP

                      • woynam
                        That s a nice write-up, Jose, but I don t see how it s going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving
                        Message 11 of 27 , Nov 9, 2012
                        • 0 Attachment
                          That's a nice write-up, Jose, but I don't see how it's going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving a completely new team in a new domain. This is classical crash and burn territory.

                          It doesn't sound like they have the option to have multiple planning sessions every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan at the beginning, and they'll be held against it.

                          On top of that, they won't deliver *any* working software until the very end of the process, but somehow it will have to work exactly as the customer wants it. Hmmm. Yea, right.

                          This is a train wreck waiting to happen. The only way they're going to make money on the project is if they sell tickets to the crash.

                          Mark


                          --- In scrumdevelopment@yahoogroups.com, Jose Solera <JOSE.SOLERA@...> wrote:
                          >
                          > I beg to disagree with those who say not to do it. If you have to, you have
                          > to. I had to do it once (no choice, believe me!)
                          >
                          > What I did: I layered an approach developed at Intel for their
                          > semiconductor design projects and now known as "Commitment Based Project
                          > Management" or CBPM for short. It is a domain-agnostic (it's been used not
                          > only in semiconductor design and software development, but also
                          > construction, defense projects, medical device development, education,
                          > event-planning, and numerous other domains).
                          >
                          > It starts with what we call "map days". These are planning days through
                          > which the entire team develops a rolling plan. Details are planned as far
                          > out as the team is comfortable with, typically 6-8 weeks. Owners make
                          > commitments as to when they'll deliver an item. They work with the
                          > consumers or users of these deliverables to ensure agreement on what is
                          > being delivered. Subsequent map days are scheduled, one at a time, at the
                          > end of the previous map day.
                          >
                          > Regularly (at least three times a week some times daily) progress is
                          > reviewed and adjustments made to the plans. Issues are encouraged to be
                          > brought to light as soon as possible.
                          >
                          > Deliverables and status are tracked through an automated Excel spreadsheet.
                          >
                          > More details are available in Timm Esque's book describing its development:
                          > *No Surprises Project Management*, at the LinkedIn group Project
                          > Acceleration thru Commitment Based Project Management (
                          > http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
                          > that Timm and I deliver, in a white paper I published (let me know if you
                          > are interested), in Timm's company website (http://ensemblemc.com/) and in
                          > a white paper he's published (
                          > http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
                          > ).
                          >
                          > To get back to my story: I had to use a home-grown waterfall methodology.
                          > We planned the effort using CBPM, avoided saying yes to the unrealistic
                          > date requested by the customer by demonstrating its impossibility in the
                          > first map day, made a commitments early on (second map day since we needed
                          > to see if we could deliver portions of the software -- Agile!) and hit each
                          > and everyone of our commitments on the nose. "There were no fires!" was the
                          > best comment I heard.
                          >
                          > Would I use this instead of Scrum or XP? No! Those approaches are designed
                          > for software development. But if I have to use waterfall, yes. Or for some
                          > other less-SW-development time of IT projects such as migrating
                          > applications to a new security system, deploying servers, etc.
                          >
                          > Contact me or Timm (through his website) if you want more details.
                          >
                          > All the best,
                          >
                          > Jose Solera, MBA, PMP®, CSM, CSPO, CSP
                          >
                        • Cass Dalton
                          It also depends on how closely the customer is looking at the project execution. You can do an agile process internally and project waterfall milestone out.
                          Message 12 of 27 , Nov 9, 2012
                          • 0 Attachment
                            It also depends on how closely the customer is looking at the project execution.  You can do an agile process internally and project waterfall milestone out.  If the customer is at your site every day or you are at theirs, you're SOL.  And if the coding/implementation phase is large enough, you can do agile within this phase and stay waterfall on the front and back end.  Don't listen to the people that say it's impossible.  I work in DoD contracting and it can be done.  We do it here more and more.  But nothing you do will every really be scrum, and many people will claim that what you're doing isn't agile.  But that goes back to my point about taking the philosophy of the agile community over the actual process.  Good developers will have been working in a somewhat agile personal process inside your waterfall shell already.
                            One compromise is break the work into phases (still one Gantt chart) and call it spiral development.  The DoD has been doing this for years.  Another compromise is to "scrum" out your waterfall phases (e.g. 1 sprint for requirements analysis, 2 sprints for design, that sort of thing) so that when you get to coding, you already have a cadence.  And behind the scenes you can start "prototyping" code for the purpose of "fleshing out requirements" or "fleshing out the design".  But you have to know and accept that you're cheating.  You're cheating the waterfall process because you're tainting their perfectly planned process with some empirical filth, and you're cheating the agile process because you are not bringing the customer close to you and you're still doing a lot of BUFD.  You will make everyone happy if the coding sprints develop each small piece to a deployed state and your integration and maintenance phases are painless.  You also need to be careful about your requirement analysis phase.  Those set-in-stone requirements are what will keep you from really being agile.  It is of the utmost importance that you craft the requirements with the same type of thinking that goes into user stories: Don't design through requirements. Write from the perspective of what you need to do with the system, not what you think the end system should be.  Write requirements so that a number of different solutions can satisfy them and sort out the correct solution in design and/or code.

                            There are hybrids.  Where the critics and pundits get their fuel for predicting the end of the world is all of the people that try to shoehorn a couple of agile buzzwords into a traditional mindset and expect to get agile hyper-performance.  You won't get the performance that others are getting.  But you can incorporate some good ideas from the agile community to improve the process.  You may not want to show your external customers the product of the first few sprints, but you can be looking internally to make sure that the "prototypes" are actually looking and acting the way the designers expected.

                            And I don't know what industry you work in, but even my strict, traditional waterfall DoD world, there's always a path to change course if something comes up that has a serious impact on the original design.  They call it "re-baselining".  The government has gotten burned so many times from throwing good money after bad that even though they may say that they want a plan set in stone and you can't change it, they will listen if you say that new evidence says that the current design is risky.  If you give them options along with the bad news, and one of those options is still within budget and schedule, they can make the decision to modify the scope.  And if it comes from them instead of you telling them "well, the project is now going to cost twice as much", they feel like they are actually in control.


                            On Fri, Nov 9, 2012 at 4:44 PM, woynam <woyna@...> wrote:
                             


                            That's a nice write-up, Jose, but I don't see how it's going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving a completely new team in a new domain. This is classical crash and burn territory.

                            It doesn't sound like they have the option to have multiple planning sessions every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan at the beginning, and they'll be held against it.

                            On top of that, they won't deliver *any* working software until the very end of the process, but somehow it will have to work exactly as the customer wants it. Hmmm. Yea, right.

                            This is a train wreck waiting to happen. The only way they're going to make money on the project is if they sell tickets to the crash.

                            Mark



                            --- In scrumdevelopment@yahoogroups.com, Jose Solera <JOSE.SOLERA@...> wrote:
                            >
                            > I beg to disagree with those who say not to do it. If you have to, you have
                            > to. I had to do it once (no choice, believe me!)
                            >
                            > What I did: I layered an approach developed at Intel for their
                            > semiconductor design projects and now known as "Commitment Based Project
                            > Management" or CBPM for short. It is a domain-agnostic (it's been used not
                            > only in semiconductor design and software development, but also
                            > construction, defense projects, medical device development, education,
                            > event-planning, and numerous other domains).
                            >
                            > It starts with what we call "map days". These are planning days through
                            > which the entire team develops a rolling plan. Details are planned as far
                            > out as the team is comfortable with, typically 6-8 weeks. Owners make
                            > commitments as to when they'll deliver an item. They work with the
                            > consumers or users of these deliverables to ensure agreement on what is
                            > being delivered. Subsequent map days are scheduled, one at a time, at the
                            > end of the previous map day.
                            >
                            > Regularly (at least three times a week some times daily) progress is
                            > reviewed and adjustments made to the plans. Issues are encouraged to be
                            > brought to light as soon as possible.
                            >
                            > Deliverables and status are tracked through an automated Excel spreadsheet.
                            >
                            > More details are available in Timm Esque's book describing its development:
                            > *No Surprises Project Management*, at the LinkedIn group Project

                            > Acceleration thru Commitment Based Project Management (
                            > http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
                            > that Timm and I deliver, in a white paper I published (let me know if you
                            > are interested), in Timm's company website (http://ensemblemc.com/) and in
                            > a white paper he's published (
                            > http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
                            > ).
                            >
                            > To get back to my story: I had to use a home-grown waterfall methodology.
                            > We planned the effort using CBPM, avoided saying yes to the unrealistic
                            > date requested by the customer by demonstrating its impossibility in the
                            > first map day, made a commitments early on (second map day since we needed
                            > to see if we could deliver portions of the software -- Agile!) and hit each
                            > and everyone of our commitments on the nose. "There were no fires!" was the
                            > best comment I heard.
                            >
                            > Would I use this instead of Scrum or XP? No! Those approaches are designed
                            > for software development. But if I have to use waterfall, yes. Or for some
                            > other less-SW-development time of IT projects such as migrating
                            > applications to a new security system, deploying servers, etc.
                            >
                            > Contact me or Timm (through his website) if you want more details.
                            >
                            > All the best,
                            >
                            > Jose Solera, MBA, PMP®, CSM, CSPO, CSP
                            >


                          • Michael Vizdos
                            So um, as eloquent as a lot of these explanations are (they are good rationalizations!) I still stand by my first recommendation. Don t do it. But then again
                            Message 13 of 27 , Nov 10, 2012
                            • 0 Attachment

                              So um, as eloquent as a lot of these explanations are (they are good rationalizations!) I still stand by my first recommendation.

                              Don't do it.

                              But then again that is a choice I make and I will not work under those conditions. Of course I do work with many teams in cleaning up crap like this so feel free to call me to kill this project now or to clean up later.

                              Still, good luck.

                              Mike Vizdos

                              On Nov 10, 2012 6:24 PM, "Cass Dalton" <cassdalton73@...> wrote:
                               

                              Oops, hit send instead of enter...

                               - Bring your developers closer to the stakeholders; get devs involved in the requirements analysis
                               - Ensure that development isn't "done" until something is tested in a deployed environment
                               - Break down work into small bite sized chunks;  Everything everyone in the community says about small user stories (INVEST) can be applied to any work.
                               - Integrate a feature all the way to the end before adding a new one
                               - Embed the benefits of an iterative, empirical approach into your process;  Get something tangible in front of stakeholders early.  Call it a prototype if you want, just build something before you design everything.

                              You will get much more benefit from improving your development philosophy and culture that you will from your process.  


                              On Fri, Nov 9, 2012 at 6:57 AM, Cass Dalton <cassdalton73@...> wrote:
                              But you can learn from the agile community and greatly improve your waterfall process:
                               - Use automated tests; and make sure they are easy to run, quickly identify specifics of a problem, and are run frequently.
                               - Use continuous integration;  Check in frequently and fix problems as soon as they appear. DON'T EVER ACCEPT BROKEN BUILDS


                              On Fri, Nov 9, 2012 at 12:21 AM, Ashish Mahajan <agileashish@...> wrote:
                               

                              Agreed.
                              If you are good at swimming in water(fall),fine.
                              If you are good at cycling(scrum cycles), fine.
                              But trying cycling in water may be fatal.

                              Regards
                              Ashish

                              Sent from my BlackBerry® smartphone

                              From: Eric Tiongson <tiongks@...>
                              Date: Fri, 9 Nov 2012 13:12:37 +0800
                              Subject: Re: [scrumdevelopment] Well done waterfall+agile

                               

                              Agree with what Michael said, you'll just find yourself in a heap of trouble if you do that.

                              However you can still use agile practices (not processes) within a waterfall processes.

                              Sent from my iPhone

                              On Nov 9, 2012, at 12:52 PM, Michael Vizdos <mvizdos@...> wrote:

                               

                              No.

                              Don't do this.

                              If you want to do waterfall. Just do that.

                              Good luck.

                              Don't fake it.

                              Mike Vizdos

                              On Nov 8, 2012 6:08 PM, "marcodorantes" <marcodorantes@...> wrote:
                               

                              Hi all,

                              I am looking for articles or papers that talk about the details of how to successfully execute a development project with a waterfall façade to the upper-management layer and an agile approach for the development team. All is new in the project: the team, the users, the application, the technology. Note that with «waterfall» I mean strict sequential stages of requirements, analysis, design, coding, testing, deployment to production, and three months of maintenance; along with a fixed-price/fixed-scope contract, and a single Gantt chart as part of the signed contract. This Gantt chart will work as the criteria for payments at the end of each stage against stated deliverables in the contract.

                              I have heard, from time to time, that some teams have done precisely that and very well done. Yet, I have not checked the evidence to believe it.

                              Could you point to those articles or papers, or experiences?

                              Thank you very much in advance.



                            • George Dinwiddie
                              Marco, ... I ve seen a number of teams who think they re doing Agile development, but are, instead, trying to burn through a fixed backlog by using iterative
                              Message 14 of 27 , Nov 10, 2012
                              • 0 Attachment
                                Marco,

                                On 11/8/12 7:00 PM, marcodorantes wrote:
                                > Hi all,
                                >
                                > I am looking for articles or papers that talk about the details of
                                > how to successfully execute a development project with a waterfall
                                > façade to the upper-management layer and an agile approach for the
                                > development team. All is new in the project: the team, the users, the
                                > application, the technology. Note that with «waterfall» I mean strict
                                > sequential stages of requirements, analysis, design, coding, testing,
                                > deployment to production, and three months of maintenance; along with
                                > a fixed-price/fixed-scope contract, and a single Gantt chart as part
                                > of the signed contract. This Gantt chart will work as the criteria
                                > for payments at the end of each stage against stated deliverables in
                                > the contract.
                                >
                                > I have heard, from time to time, that some teams have done precisely
                                > that and very well done. Yet, I have not checked the evidence to
                                > believe it.
                                >
                                > Could you point to those articles or papers, or experiences?

                                I've seen a number of teams who think they're doing Agile development,
                                but are, instead, trying to burn through a fixed backlog by using
                                iterative processes. Theoretically, that could work. It would even give
                                you a better indicator of progress (or lack of it). I've never seen it
                                go well, however. It has all the fragility of waterfall plus the
                                frustration of not being allowed to use what you learn as you go.

                                If you can't change the backlog, it's not, by any means, Agile under the
                                covers. It's still waterfall, even if you use some practices that are
                                commonly associated with Agile.

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • Aaron Seipel
                                What you re describing really seems like the normal way most old-school waterfall teams adapt to Agile.  You start small and prove the benefits to management,
                                Message 15 of 27 , Nov 11, 2012
                                • 0 Attachment
                                  What you're describing really seems like the normal way most old-school waterfall teams adapt to Agile.  You start small and prove the benefits to management, so you can adopt more Agile practices.  I've gone through this process myself.  It takes time to convert the masses, but it isn't impossible.  The only advise I have is adding a single product owner to your team early will make your Agile adoption will be much smoother.  Depending on the environment, this can be very difficult...
                                   
                                  Good luck,
                                   
                                  Aaron Seipel

                                  From: George Dinwiddie <lists@...>
                                  To: scrumdevelopment@yahoogroups.com
                                  Sent: Saturday, November 10, 2012 8:54 PM
                                  Subject: Re: [scrumdevelopment] Well done waterfall+agile
                                   
                                  Marco,

                                  On 11/8/12 7:00 PM, marcodorantes wrote:
                                  > Hi all,
                                  >
                                  > I am looking for articles or papers that talk about the details of
                                  > how to successfully execute a development project with a waterfall
                                  > façade to the upper-management layer and an agile approach for the
                                  > development team. All is new in the project: the team, the users, the
                                  > application, the technology. Note that with «waterfall» I mean strict
                                  > sequential stages of requirements, analysis, design, coding, testing,
                                  > deployment to production, and three months of maintenance; along with
                                  > a fixed-price/fixed-scope contract, and a single Gantt chart as part
                                  > of the signed contract. This Gantt chart will work as the criteria
                                  > for payments at the end of each stage against stated deliverables in
                                  > the contract.
                                  >
                                  > I have heard, from time to time, that some teams have done precisely
                                  > that and very well done. Yet, I have not checked the evidence to
                                  > believe it.
                                  >
                                  > Could you point to those articles or papers, or experiences?

                                  I've seen a number of teams who think they're doing Agile development,
                                  but are, instead, trying to burn through a fixed backlog by using
                                  iterative processes. Theoretically, that could work. It would even give
                                  you a better indicator of progress (or lack of it). I've never seen it
                                  go well, however. It has all the fragility of waterfall plus the
                                  frustration of not being allowed to use what you learn as you go.

                                  If you can't change the backlog, it's not, by any means, Agile under the
                                  covers. It's still waterfall, even if you use some practices that are
                                  commonly associated with Agile.

                                  - George

                                  --
                                  ----------------------------------------------------------
                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                  Software Development http://www.idiacomputing.com
                                  Consultant and Coach http://www.agilemaryland.org
                                  ----------------------------------------------------------

                                • JoseS
                                  Thanks, Mark. In my experience, though, there s room to be flexible even when told you have to do it a certain way. Senior managers don t have time to
                                  Message 16 of 27 , Nov 11, 2012
                                  • 0 Attachment
                                    Thanks, Mark. In my experience, though, there's room to be flexible even when told you have to do it a certain way. Senior managers don't have time to micromanage what is going on. The role of the PM is to figure out how to make the space so that the team can be successful. Don't call it a Map Day, but a Planning Day. You'll come out with a very good plan out of the first day. Subsequent meetings will be to assess where we are and "refine the plan." Senior managers will be OK with that.

                                    It may be still, as you say, a train wreck. But that's no reason to run away. Still, we may agree to disagree.

                                    All the best,

                                    Jose

                                    --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                    >
                                    >
                                    > That's a nice write-up, Jose, but I don't see how it's going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving a completely new team in a new domain. This is classical crash and burn territory.
                                    >
                                    > It doesn't sound like they have the option to have multiple planning sessions every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan at the beginning, and they'll be held against it.
                                    >
                                    > On top of that, they won't deliver *any* working software until the very end of the process, but somehow it will have to work exactly as the customer wants it. Hmmm. Yea, right.
                                    >
                                    > This is a train wreck waiting to happen. The only way they're going to make money on the project is if they sell tickets to the crash.
                                    >
                                    > Mark
                                    >
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com, Jose Solera <JOSE.SOLERA@> wrote:
                                    > >
                                    > > I beg to disagree with those who say not to do it. If you have to, you have
                                    > > to. I had to do it once (no choice, believe me!)
                                    > >
                                    > > What I did: I layered an approach developed at Intel for their
                                    > > semiconductor design projects and now known as "Commitment Based Project
                                    > > Management" or CBPM for short. It is a domain-agnostic (it's been used not
                                    > > only in semiconductor design and software development, but also
                                    > > construction, defense projects, medical device development, education,
                                    > > event-planning, and numerous other domains).
                                    > >
                                    > > It starts with what we call "map days". These are planning days through
                                    > > which the entire team develops a rolling plan. Details are planned as far
                                    > > out as the team is comfortable with, typically 6-8 weeks. Owners make
                                    > > commitments as to when they'll deliver an item. They work with the
                                    > > consumers or users of these deliverables to ensure agreement on what is
                                    > > being delivered. Subsequent map days are scheduled, one at a time, at the
                                    > > end of the previous map day.
                                    > >
                                    > > Regularly (at least three times a week some times daily) progress is
                                    > > reviewed and adjustments made to the plans. Issues are encouraged to be
                                    > > brought to light as soon as possible.
                                    > >
                                    > > Deliverables and status are tracked through an automated Excel spreadsheet.
                                    > >
                                    > > More details are available in Timm Esque's book describing its development:
                                    > > *No Surprises Project Management*, at the LinkedIn group Project
                                    > > Acceleration thru Commitment Based Project Management (
                                    > > http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
                                    > > that Timm and I deliver, in a white paper I published (let me know if you
                                    > > are interested), in Timm's company website (http://ensemblemc.com/) and in
                                    > > a white paper he's published (
                                    > > http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
                                    > > ).
                                    > >
                                    > > To get back to my story: I had to use a home-grown waterfall methodology.
                                    > > We planned the effort using CBPM, avoided saying yes to the unrealistic
                                    > > date requested by the customer by demonstrating its impossibility in the
                                    > > first map day, made a commitments early on (second map day since we needed
                                    > > to see if we could deliver portions of the software -- Agile!) and hit each
                                    > > and everyone of our commitments on the nose. "There were no fires!" was the
                                    > > best comment I heard.
                                    > >
                                    > > Would I use this instead of Scrum or XP? No! Those approaches are designed
                                    > > for software development. But if I have to use waterfall, yes. Or for some
                                    > > other less-SW-development time of IT projects such as migrating
                                    > > applications to a new security system, deploying servers, etc.
                                    > >
                                    > > Contact me or Timm (through his website) if you want more details.
                                    > >
                                    > > All the best,
                                    > >
                                    > > Jose Solera, MBA, PMP®, CSM, CSPO, CSP
                                    > >
                                    >
                                  • Michael James
                                    As I meant to write earlier, I always appreciate hearing experience reports, such as the one you wrote Jose. I wouldn t choose to do waterfall for software
                                    Message 17 of 27 , Nov 11, 2012
                                    • 0 Attachment
                                      As I meant to write earlier, I always appreciate hearing experience reports, such as the one you wrote Jose.

                                      I wouldn't choose to do waterfall for software development, but if that were beyond my control I'd at least introduce some feedback loops (as you did) to reduce the risks.

                                      --mj
                                      (Michael)

                                      On Nov 11, 2012, at 12:37 PM, "JoseS" <JOSE.SOLERA@...> wrote:

                                       

                                      Thanks, Mark. In my experience, though, there's room to be flexible even when told you have to do it a certain way. Senior managers don't have time to micromanage what is going on. The role of the PM is to figure out how to make the space so that the team can be successful. Don't call it a Map Day, but a Planning Day. You'll come out with a very good plan out of the first day. Subsequent meetings will be to assess where we are and "refine the plan." Senior managers will be OK with that.

                                      It may be still, as you say, a train wreck. But that's no reason to run away. Still, we may agree to disagree.

                                      All the best,

                                      Jose

                                      --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                      >
                                      >
                                      > That's a nice write-up, Jose, but I don't see how it's going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving a completely new team in a new domain. This is classical crash and burn territory.
                                      >
                                      > It doesn't sound like they have the option to have multiple planning sessions every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan at the beginning, and they'll be held against it.
                                      >
                                      > On top of that, they won't deliver *any* working software until the very end of the process, but somehow it will have to work exactly as the customer wants it. Hmmm. Yea, right.
                                      >
                                      > This is a train wreck waiting to happen. The only way they're going to make money on the project is if they sell tickets to the crash.
                                      >
                                      > Mark
                                      >
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, Jose Solera <JOSE.SOLERA@> wrote:
                                      > >
                                      > > I beg to disagree with those who say not to do it. If you have to, you have
                                      > > to. I had to do it once (no choice, believe me!)
                                      > >
                                      > > What I did: I layered an approach developed at Intel for their
                                      > > semiconductor design projects and now known as "Commitment Based Project
                                      > > Management" or CBPM for short. It is a domain-agnostic (it's been used not
                                      > > only in semiconductor design and software development, but also
                                      > > construction, defense projects, medical device development, education,
                                      > > event-planning, and numerous other domains).
                                      > >
                                      > > It starts with what we call "map days". These are planning days through
                                      > > which the entire team develops a rolling plan. Details are planned as far
                                      > > out as the team is comfortable with, typically 6-8 weeks. Owners make
                                      > > commitments as to when they'll deliver an item. They work with the
                                      > > consumers or users of these deliverables to ensure agreement on what is
                                      > > being delivered. Subsequent map days are scheduled, one at a time, at the
                                      > > end of the previous map day.
                                      > >
                                      > > Regularly (at least three times a week some times daily) progress is
                                      > > reviewed and adjustments made to the plans. Issues are encouraged to be
                                      > > brought to light as soon as possible.
                                      > >
                                      > > Deliverables and status are tracked through an automated Excel spreadsheet.
                                      > >
                                      > > More details are available in Timm Esque's book describing its development:
                                      > > *No Surprises Project Management*, at the LinkedIn group Project
                                      > > Acceleration thru Commitment Based Project Management (
                                      > > http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
                                      > > that Timm and I deliver, in a white paper I published (let me know if you
                                      > > are interested), in Timm's company website (http://ensemblemc.com/) and in
                                      > > a white paper he's published (
                                      > > http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
                                      > > ).
                                      > >
                                      > > To get back to my story: I had to use a home-grown waterfall methodology.
                                      > > We planned the effort using CBPM, avoided saying yes to the unrealistic
                                      > > date requested by the customer by demonstrating its impossibility in the
                                      > > first map day, made a commitments early on (second map day since we needed
                                      > > to see if we could deliver portions of the software -- Agile!) and hit each
                                      > > and everyone of our commitments on the nose. "There were no fires!" was the
                                      > > best comment I heard.
                                      > >
                                      > > Would I use this instead of Scrum or XP? No! Those approaches are designed
                                      > > for software development. But if I have to use waterfall, yes. Or for some
                                      > > other less-SW-development time of IT projects such as migrating
                                      > > applications to a new security system, deploying servers, etc.
                                      > >
                                      > > Contact me or Timm (through his website) if you want more details.
                                      > >
                                      > > All the best,
                                      > >
                                      > > Jose Solera, MBA, PMP®, CSM, CSPO, CSP
                                      > >
                                      >


                                    • jerzyklek
                                      Hi, I am quite new to this and and have been lurking for some time. I have one question to this comment since I am in a bit similar situation: we have a huge
                                      Message 18 of 27 , Nov 16, 2012
                                      • 0 Attachment
                                        Hi,

                                        I am quite new to this and and have been lurking for some time.
                                        I have one question to this comment since I am in a bit similar
                                        situation: we have a huge backlog of things which all
                                        are wanted by some customers, prioritized by the customer importance,
                                        and usually we can go through quite a few sprint before something new gets into the backlog on top of it, having a higher priority.

                                        I also understand that Agile emerged in places where the customer did not know what he/she wanted, and main impact of "learn and adapt" principle on project success was by enabling the result of one iteration/sprint to influence the remaining product backlog.

                                        We don't have much of that, but sprint reviews allow us adapt our ways of working on a team level: how we plan, estimate, test... what we document and so on... I think it's another aspect of "agility":
                                        we do not adapt the backlog, but adapt our ways of working.
                                        Not "fully agile" then, but still a bit.

                                        I am pretty sure that out POs could use the reviews more to our benefit, but anyway...

                                        //Jerzy

                                        --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                        >
                                        > Marco,
                                        >
                                        > On 11/8/12 7:00 PM, marcodorantes wrote:
                                        > > Hi all,
                                        > >
                                        > > I am looking for articles or papers that talk about the details of
                                        > > how to successfully execute a development project with a waterfall
                                        > > façade to the upper-management layer and an agile approach for the
                                        > > development team. All is new in the project: the team, the users, the
                                        > > application, the technology. Note that with «waterfall» I mean strict
                                        > > sequential stages of requirements, analysis, design, coding, testing,
                                        > > deployment to production, and three months of maintenance; along with
                                        > > a fixed-price/fixed-scope contract, and a single Gantt chart as part
                                        > > of the signed contract. This Gantt chart will work as the criteria
                                        > > for payments at the end of each stage against stated deliverables in
                                        > > the contract.
                                        > >
                                        > > I have heard, from time to time, that some teams have done precisely
                                        > > that and very well done. Yet, I have not checked the evidence to
                                        > > believe it.
                                        > >
                                        > > Could you point to those articles or papers, or experiences?
                                        >
                                        > I've seen a number of teams who think they're doing Agile development,
                                        > but are, instead, trying to burn through a fixed backlog by using
                                        > iterative processes. Theoretically, that could work. It would even give
                                        > you a better indicator of progress (or lack of it). I've never seen it
                                        > go well, however. It has all the fragility of waterfall plus the
                                        > frustration of not being allowed to use what you learn as you go.
                                        >
                                        > If you can't change the backlog, it's not, by any means, Agile under the
                                        > covers. It's still waterfall, even if you use some practices that are
                                        > commonly associated with Agile.
                                        >
                                        > - George
                                        >
                                        > --
                                        > ----------------------------------------------------------------------
                                        > * George Dinwiddie * http://blog.gdinwiddie.com
                                        > Software Development http://www.idiacomputing.com
                                        > Consultant and Coach http://www.agilemaryland.org
                                        > ----------------------------------------------------------------------
                                        >
                                      • George Dinwiddie
                                        Jerzy, ... I suggest that your understanding is not quite correct. Perhaps sometimes, but that s not the general case. More commonly, the customer DID know
                                        Message 19 of 27 , Nov 16, 2012
                                        • 0 Attachment
                                          Jerzy,

                                          On 11/16/12 10:51 AM, jerzyklek wrote:
                                          > Hi,
                                          >
                                          > I am quite new to this and and have been lurking for some time.
                                          > I have one question to this comment since I am in a bit similar
                                          > situation: we have a huge backlog of things which all
                                          > are wanted by some customers, prioritized by the customer importance,
                                          > and usually we can go through quite a few sprint before something new
                                          > gets into the backlog on top of it, having a higher priority.
                                          >
                                          > I also understand that Agile emerged in places where the customer did
                                          > not know what he/she wanted,

                                          I suggest that your understanding is not quite correct. Perhaps
                                          sometimes, but that's not the general case. More commonly, the customer
                                          DID know what they wanted, but were able to take advantage of things
                                          learned during development to achieve something better or sooner.

                                          > and main impact of "learn and adapt"
                                          > principle on project success was by enabling the result of one
                                          > iteration/sprint to influence the remaining product backlog.
                                          >
                                          > We don't have much of that, but sprint reviews allow us adapt our
                                          > ways of working on a team level: how we plan, estimate, test... what
                                          > we document and so on... I think it's another aspect of "agility": we
                                          > do not adapt the backlog, but adapt our ways of working. Not "fully
                                          > agile" then, but still a bit.
                                          >
                                          > I am pretty sure that out POs could use the reviews more to our
                                          > benefit, but anyway...
                                          >
                                          > //Jerzy
                                          >
                                          > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                          >>
                                          >> Marco,
                                          >>
                                          >> On 11/8/12 7:00 PM, marcodorantes wrote:
                                          >>> Hi all,
                                          >>>
                                          >>> I am looking for articles or papers that talk about the details of
                                          >>> how to successfully execute a development project with a waterfall
                                          >>> façade to the upper-management layer and an agile approach for the
                                          >>> development team. All is new in the project: the team, the users, the
                                          >>> application, the technology. Note that with «waterfall» I mean strict
                                          >>> sequential stages of requirements, analysis, design, coding, testing,
                                          >>> deployment to production, and three months of maintenance; along with
                                          >>> a fixed-price/fixed-scope contract, and a single Gantt chart as part
                                          >>> of the signed contract. This Gantt chart will work as the criteria
                                          >>> for payments at the end of each stage against stated deliverables in
                                          >>> the contract.
                                          >>>
                                          >>> I have heard, from time to time, that some teams have done precisely
                                          >>> that and very well done. Yet, I have not checked the evidence to
                                          >>> believe it.
                                          >>>
                                          >>> Could you point to those articles or papers, or experiences?
                                          >>
                                          >> I've seen a number of teams who think they're doing Agile development,
                                          >> but are, instead, trying to burn through a fixed backlog by using
                                          >> iterative processes. Theoretically, that could work. It would even give
                                          >> you a better indicator of progress (or lack of it). I've never seen it
                                          >> go well, however. It has all the fragility of waterfall plus the
                                          >> frustration of not being allowed to use what you learn as you go.
                                          >>
                                          >> If you can't change the backlog, it's not, by any means, Agile under the
                                          >> covers. It's still waterfall, even if you use some practices that are
                                          >> commonly associated with Agile.
                                          >>
                                          >> - George

                                          --
                                          ----------------------------------------------------------------------
                                          * George Dinwiddie * http://blog.gdinwiddie.com
                                          Software Development http://www.idiacomputing.com
                                          Consultant and Coach http://www.agilemaryland.org
                                          ----------------------------------------------------------------------
                                        • RonJeffries
                                          Hi ... ... The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted. Ron Jeffries www.XProgramming.com You never
                                          Message 20 of 27 , Nov 16, 2012
                                          • 0 Attachment
                                            Hi ...

                                            On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:

                                            I also understand that Agile emerged in places where the customer did
                                            not know what he/she wanted,

                                            I suggest that your understanding is not quite correct. Perhaps 
                                            sometimes, but that's not the general case. More commonly, the customer 
                                            DID know what they wanted, but were able to take advantage of things 
                                            learned during development to achieve something better or sooner.

                                            The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted.
                                            You never know what is enough unless you know what is more than enough. -- William Blake

                                          • jerzyklek
                                            Hi, I think you mean that even when they know what they want, this is not what they need :-) Very true! We do embedded stuff, where some thick spec mandated by
                                            Message 21 of 27 , Nov 18, 2012
                                            • 0 Attachment
                                              Hi,

                                              I think you mean that even when they know what they want,
                                              this is not what they need :-)
                                              Very true!
                                              We do embedded stuff, where some thick spec mandated by law
                                              can take many sprints, so it's more difficult to be in this situation...

                                              thanks for the insight!

                                              /Jerzy

                                              --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                              >
                                              > Hi ...
                                              >
                                              > On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:
                                              >
                                              > >> I also understand that Agile emerged in places where the customer did
                                              > >> not know what he/she wanted,
                                              > >
                                              > > I suggest that your understanding is not quite correct. Perhaps
                                              > > sometimes, but that's not the general case. More commonly, the customer
                                              > > DID know what they wanted, but were able to take advantage of things
                                              > > learned during development to achieve something better or sooner.
                                              >
                                              >
                                              > The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted.
                                              >
                                              > Ron Jeffries
                                              > www.XProgramming.com
                                              > You never know what is enough unless you know what is more than enough. -- William Blake
                                              >
                                            • changjiang1124@gmail.com
                                              Hi guys: I am new to this group, should have much to learn from you guys. I see here we always talk about customer , does Scrum only fit kinda outsourcing
                                              Message 22 of 27 , Nov 19, 2012
                                              • 0 Attachment
                                                Hi guys:

                                                I am new to this group, should have much to learn from you guys.

                                                I see here we always talk about "customer", does Scrum only fit kinda outsourcing development? What about doing your own products? That means, you will always get feedbacks from your customers, like bugs or wanted features, sometimes you need to reply them within several hours. And you still need to keep pace on your own milestones. 


                                                Best regards
                                                Chang, Jiang



                                                On Nov 17, 2012, at 3:41 AM, RonJeffries <ronjeffries@...> wrote:

                                                 

                                                Hi ...


                                                On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:

                                                I also understand that Agile emerged in places where the customer did
                                                not know what he/she wanted,

                                                I suggest that your understanding is not quite correct. Perhaps 
                                                sometimes, but that's not the general case. More commonly, the customer 
                                                DID know what they wanted, but were able to take advantage of things 
                                                learned during development to achieve something better or sooner.

                                                The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted.
                                                You never know what is enough unless you know what is more than enough. -- William Blake



                                              • Cass Dalton
                                                This feels like its own question. You should repost as a new question to the group On Nov 19, 2012 9:01 AM, changjiang1124@gmail.com
                                                Message 23 of 27 , Nov 19, 2012
                                                • 0 Attachment

                                                  This feels like its own question.  You should repost as a new question to the group

                                                  On Nov 19, 2012 9:01 AM, "changjiang1124@..." <changjiang1124@...> wrote:
                                                   

                                                  Hi guys:


                                                  I am new to this group, should have much to learn from you guys.

                                                  I see here we always talk about "customer", does Scrum only fit kinda outsourcing development? What about doing your own products? That means, you will always get feedbacks from your customers, like bugs or wanted features, sometimes you need to reply them within several hours. And you still need to keep pace on your own milestones. 


                                                  Best regards
                                                  Chang, Jiang



                                                  On Nov 17, 2012, at 3:41 AM, RonJeffries <ronjeffries@...> wrote:

                                                   

                                                  Hi ...


                                                  On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:

                                                  I also understand that Agile emerged in places where the customer did
                                                  not know what he/she wanted,

                                                  I suggest that your understanding is not quite correct. Perhaps 
                                                  sometimes, but that's not the general case. More commonly, the customer 
                                                  DID know what they wanted, but were able to take advantage of things 
                                                  learned during development to achieve something better or sooner.

                                                  The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted.
                                                  You never know what is enough unless you know what is more than enough. -- William Blake



                                                • George Dinwiddie
                                                  Chang, ... There is always a customer (or several) even when they re within your own organization. - George -- ... * George Dinwiddie *
                                                  Message 24 of 27 , Nov 19, 2012
                                                  • 0 Attachment
                                                    Chang,

                                                    On 11/19/12 3:35 AM, changjiang1124@... wrote:
                                                    >
                                                    >
                                                    > Hi guys:
                                                    >
                                                    > I am new to this group, should have much to learn from you guys.
                                                    >
                                                    > I see here we always talk about "customer", does Scrum only fit kinda
                                                    > outsourcing development? What about doing your own products? That means,
                                                    > you will always get feedbacks from your customers, like bugs or wanted
                                                    > features, sometimes you need to reply them within several hours. And you
                                                    > still need to keep pace on your own milestones.

                                                    There is always a customer (or several) even when they're within your
                                                    own organization.

                                                    - George

                                                    --
                                                    ----------------------------------------------------------------------
                                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                                    Software Development http://www.idiacomputing.com
                                                    Consultant and Coach http://www.agilemaryland.org
                                                    ----------------------------------------------------------------------
                                                  • changjiang1124@gmail.com
                                                    Sorry, guys, I will repost this. Best regards Chang, Jiang
                                                    Message 25 of 27 , Nov 19, 2012
                                                    • 0 Attachment
                                                      Sorry, guys, I will repost this.


                                                      Best regards
                                                      Chang, Jiang



                                                      On Nov 19, 2012, at 10:48 PM, Cass Dalton <cassdalton73@...> wrote:

                                                       

                                                      This feels like its own question.  You should repost as a new question to the group

                                                      On Nov 19, 2012 9:01 AM, "changjiang1124@..." <changjiang1124@...> wrote:
                                                       

                                                      Hi guys:


                                                      I am new to this group, should have much to learn from you guys.

                                                      I see here we always talk about "customer", does Scrum only fit kinda outsourcing development? What about doing your own products? That means, you will always get feedbacks from your customers, like bugs or wanted features, sometimes you need to reply them within several hours. And you still need to keep pace on your own milestones. 


                                                      Best regards
                                                      Chang, Jiang



                                                      On Nov 17, 2012, at 3:41 AM, RonJeffries <ronjeffries@...> wrote:

                                                       

                                                      Hi ...


                                                      On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:

                                                      I also understand that Agile emerged in places where the customer did
                                                      not know what he/she wanted,

                                                      I suggest that your understanding is not quite correct. Perhaps 
                                                      sometimes, but that's not the general case. More commonly, the customer 
                                                      DID know what they wanted, but were able to take advantage of things 
                                                      learned during development to achieve something better or sooner.

                                                      The first XP project, still one of the best, was payroll. The customer knew EXACTLY what they wanted.
                                                      You never know what is enough unless you know what is more than enough. -- William Blake






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