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

Potentially releasable software

Expand Messages
  • Mark Graybill
    A debate has brewed here regarding a statement someone made that we are not really doing Scrum because we do not have a releasable product at the end of every
    Message 1 of 20 , Oct 31, 2007
    • 0 Attachment
      A debate has brewed here regarding a statement someone made that we are not really doing Scrum because we do not have a releasable product at the end of every Sprint.
       
      The dilemma is this:
       
      - Our software is classified by the FDA as a Class II medical device so getting filing done every 30 days is a challenge.
      - Our full testing suite takes a full week.
      - In order to faciliate quicker ramp-up for the team in assimilating and being productive using Scrum, we are doing 15 day Sprints (in speaking with Mike Cohn I think this is a preference we have in common.) 
      - From a project standpoint, 30 day Sprints are challenging and 15 day Sprints impose a near impossibility to produce a releasable product or even potentially releasable at the end of every Sprint.
      - The idea of deploying at this frequency has not been well received by our customers.
       
      The proposal in debate is this:
       
      - Each user story involves a procedure to bring it to potentially releasable status.
      - The end result is a feature tested and integrated into the product.
      - But the product itself does not go through full testing every Sprint.
      - Have alpha releases that only require an alpha contract and do that every two Sprints.
       
      What are some of your experiences and opinions in this regard?

      Thanks,
      Mark
    • Wolfgang Schulze Zachau
      Hi Mark, potentially releasable does not mean you should go and file for a Class II approval every 4 weeks (or whatever your sprint cycle is). It only means
      Message 2 of 20 , Nov 1, 2007
      • 0 Attachment
        Hi Mark,
         
        "potentially releasable" does not mean you should go and file for a Class II approval every 4 weeks (or whatever your sprint cycle is). It only means that if you wanted to, you could go and do it. Quite clearly there is no sense in actually doing it at that frequency.
        If you need a full week to run a complete cycle of tests, then I would suggest that there are probably improvements to be made to your testing. The vast majority of your testing should be automated and run in less than 15 minutes. There are numerous test frameworks available for just about any programming environment you can think of. That should reduce the number of tests that have to be run manually drastically and therefore shorten that time dramatically.
         
        Scrum is quite clear about the fact that there should be release planning and that the PO and the team should consider doing a "release sprint" prior to an actual release to do all those things that you would not add to a normal sprint. I am not an expert on this, because we write internal software and we actually do release every 2 weeks (but then we don't have to get FDA Class II approval), but I am sure others on this list can say more about this.
         

        Regards,

        Wolfgang

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mark Graybill
        Sent: 01 November 2007 00:40
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Potentially releasable software

        A debate has brewed here regarding a statement someone made that we are not really doing Scrum because we do not have a releasable product at the end of every Sprint.
         
        The dilemma is this:
         
        - Our software is classified by the FDA as a Class II medical device so getting filing done every 30 days is a challenge.
        - Our full testing suite takes a full week.
        - In order to faciliate quicker ramp-up for the team in assimilating and being productive using Scrum, we are doing 15 day Sprints (in speaking with Mike Cohn I think this is a preference we have in common.) 
        - From a project standpoint, 30 day Sprints are challenging and 15 day Sprints impose a near impossibility to produce a releasable product or even potentially releasable at the end of every Sprint.
        - The idea of deploying at this frequency has not been well received by our customers.
         
        The proposal in debate is this:
         
        - Each user story involves a procedure to bring it to potentially releasable status.
        - The end result is a feature tested and integrated into the product.
        - But the product itself does not go through full testing every Sprint.
        - Have alpha releases that only require an alpha contract and do that every two Sprints.
         
        What are some of your experiences and opinions in this regard?

        Thanks,
        Mark

      • Ilja Preuss
        ... I wonder how PatientKeeper is doing it. ... What are you planning to do to decrease this time? ... What are the roadblocks to getting a releasable product
        Message 3 of 20 , Nov 1, 2007
        • 0 Attachment
          Mark Graybill wrote:

          > - Our software is classified by the FDA as a Class II medical device so
          > getting filing done every 30 days is a challenge.

          I wonder how PatientKeeper is doing it.

          > - Our full testing suite takes a full week.

          What are you planning to do to decrease this time?

          > - From a project standpoint, 30 day Sprints are challenging and 15 day
          > Sprints impose a near impossibility to produce a releasable product or
          > even potentially releasable at the end of every Sprint.

          What are the roadblocks to getting a releasable product in that time frame?

          > - The idea of deploying at this frequency has not been well received by
          > our customers.

          That probably means that receiving a deployment is in some way "painful"
          to your customers. Where is that pain coming from, and how could you
          mitigate it? What would be needed to make it a no-brainer?

          > The proposal in debate is this:
          >
          > - Each user story involves a procedure to bring it to potentially
          > releasable status.

          I always thought that was the *definition* of a user story. Isn't it?

          > - The end result is a feature tested and integrated into the product.

          Sure. "Done done".

          > - But the product itself does not go through full testing every Sprint.

          If you don't fully test the product, how do you never whether you are
          really *done*?

          > - Have alpha releases that only require an alpha contract and do that
          > every two Sprints.

          What does "alpha contract" mean in this context, and how would it help?

          Curious, Ilja
        • Robin Dymond
          So you have two very good opinions, both are right, and I recommend you follow both. Patientkeeper releases patient records software weekly to I think around
          Message 4 of 20 , Nov 1, 2007
          • 0 Attachment
            So you have two very good opinions, both are right, and I recommend you follow both.

            Patientkeeper releases patient records software weekly to I think around 200 hospitals. I don't know their FDA requirements. Ilja is asking a perfectly reasonable question. However patient keeper did not do this overnight. It took lots of work and discipline to get to that place.
            Think about what changes you can make this iteration, in the next iteration, etc. so that you too can release to your customers with a push of the button, and it is relatively painless for all. Some companies, like JDA software use Agile, but their customers will only accept a certain frequency of releases. Some customer environments require manual updates to things like terminals or POS or other equipment, so the cost of doing updates can be high.

            Most enterprse software implementations have not HAD to make installations and updates painless, so the effort into release/install automation has not been made. It is a worthwhile investment because of the increased speed to market you and your customers gain. However your business will need to make a decision to get there, and plan to deal with all of the barriers as you would any other feature in the backlog.

            cheers,
            Robin Dymond
            www.innovel.net


            On 11/1/07, Ilja Preuss < it@...> wrote:

            Mark Graybill wrote:

            > - Our software is classified by the FDA as a Class II medical device so
            > getting filing done every 30 days is a challenge.

            I wonder how PatientKeeper is doing it.

            > - Our full testing suite takes a full week.

            What are you planning to do to decrease this time?

            > - From a project standpoint, 30 day Sprints are challenging and 15 day
            > Sprints impose a near impossibility to produce a releasable product or
            > even potentially releasable at the end of every Sprint.

            What are the roadblocks to getting a releasable product in that time frame?

            > - The idea of deploying at this frequency has not been well received by
            > our customers.

            That probably means that receiving a deployment is in some way "painful"
            to your customers. Where is that pain coming from, and how could you
            mitigate it? What would be needed to make it a no-brainer?

            > The proposal in debate is this:
            >
            > - Each user story involves a procedure to bring it to potentially
            > releasable status.

            I always thought that was the *definition* of a user story. Isn't it?

            > - The end result is a feature tested and integrated into the product.

            Sure. "Done done".

            > - But the product itself does not go through full testing every Sprint.

            If you don't fully test the product, how do you never whether you are
            really *done*?

            > - Have alpha releases that only require an alpha contract and do that
            > every two Sprints.

            What does "alpha contract" mean in this context, and how would it help?

            Curious, Ilja




            --
            Robin Dymond
            VP, Managing Partner
            Innovel, LLC
            www.innovel.net
            cell: (804) 239-4329
          • Vikrama Dhiman
            Mark: You raise a very interesting question. Lets examine it quite literally. Potentially shippable software - just because you have potentially
            Message 5 of 20 , Nov 1, 2007
            • 0 Attachment
              Mark:
               
              You raise a very interesting question.
               
              Lets examine it quite literally. "Potentially" shippable "software" - just because you have "potentially" shippable "software" does not mean you should but you can. If it needs to pass through some additional auditing/ test/ regulatory procedures - that should comprise activities which are additional to "main software". I know you can argue that till they pass this, you dont know if the code is shippable or not. I think you have to think of "software" quite literally - is it unit tested, integration tested, packaged, documented so that only the factors that SCRUM team can't control or does not want to [for better productivity or convenience] are left for the release sprint.
               
              Hope that helps!
               
              thanks

              Robin Dymond <robin.dymond@...> wrote:
              So you have two very good opinions, both are right, and I recommend you follow both.

              Patientkeeper releases patient records software weekly to I think around 200 hospitals. I don't know their FDA requirements. Ilja is asking a perfectly reasonable question. However patient keeper did not do this overnight. It took lots of work and discipline to get to that place.
              Think about what changes you can make this iteration, in the next iteration, etc. so that you too can release to your customers with a push of the button, and it is relatively painless for all. Some companies, like JDA software use Agile, but their customers will only accept a certain frequency of releases. Some customer environments require manual updates to things like terminals or POS or other equipment, so the cost of doing updates can be high.

              Most enterprse software implementations have not HAD to make installations and updates painless, so the effort into release/install automation has not been made. It is a worthwhile investment because of the increased speed to market you and your customers gain. However your business will need to make a decision to get there, and plan to deal with all of the barriers as you would any other feature in the backlog.

              cheers,
              Robin Dymond
              www.innovel. net


              On 11/1/07, Ilja Preuss < it@iljapreuss. de> wrote:
              Mark Graybill wrote:

              > - Our software is classified by the FDA as a Class II medical device so
              > getting filing done every 30 days is a challenge.

              I wonder how PatientKeeper is doing it.

              > - Our full testing suite takes a full week.

              What are you planning to do to decrease this time?

              > - From a project standpoint, 30 day Sprints are challenging and 15 day
              > Sprints impose a near impossibility to produce a releasable product or
              > even potentially releasable at the end of every Sprint.

              What are the roadblocks to getting a releasable product in that time frame?

              > - The idea of deploying at this frequency has not been well received by
              > our customers.

              That probably means that receiving a deployment is in some way "painful"
              to your customers. Where is that pain coming from, and how could you
              mitigate it? What would be needed to make it a no-brainer?

              > The proposal in debate is this:
              >
              > - Each user story involves a procedure to bring it to potentially
              > releasable status.

              I always thought that was the *definition* of a user story. Isn't it?

              > - The end result is a feature tested and integrated into the product.

              Sure. "Done done".

              > - But the product itself does not go through full testing every Sprint.

              If you don't fully test the product, how do you never whether you are
              really *done*?

              > - Have alpha releases that only require an alpha contract and do that
              > every two Sprints.

              What does "alpha contract" mean in this context, and how would it help?

              Curious, Ilja



              --
              Robin Dymond
              VP, Managing Partner
              Innovel, LLC
              www.innovel. net
              cell: (804) 239-4329

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com

            • Ilja Preuss
              ... Perhaps more importantly, it won t provide value until they pass it. It is an investment sitting on the shelf waiting to produce value. Waste. Cheers, Ilja
              Message 6 of 20 , Nov 1, 2007
              • 0 Attachment
                Vikrama Dhiman wrote:

                > Lets examine it quite literally. "Potentially" shippable "software" -
                > just because you have "potentially" shippable "software" does not mean
                > you should but you can. If it needs to pass through some additional
                > auditing/ test/ regulatory procedures - that should comprise activities
                > which are additional to "main software". I know you can argue that till
                > they pass this, you dont know if the code is shippable or not.

                Perhaps more importantly, it won't provide value until they pass it. It
                is an investment sitting on the shelf waiting to produce value. Waste.

                Cheers, Ilja
              • Vikrama Dhiman
                In that case I will ask what can I do make the process of passing the audit a bit painless. I am sure you already incorporate automated tests for some/ all
                Message 7 of 20 , Nov 1, 2007
                • 0 Attachment
                  In that case I will ask what can I do make the process of passing the audit a bit painless. I am sure you already incorporate automated tests for some/ all parts of the audit requirements.
                   
                  Is the audit process painful despite that? Are they open to test/ audit frequently [every 30 days]? What happens if you only did test/ audits for each release and not a sprint?

                  Ilja Preuss <it@...> wrote:
                  Vikrama Dhiman wrote:

                  > Lets examine it quite literally. "Potentially" shippable "software" -
                  > just because you have "potentially" shippable "software" does not mean
                  > you should but you can. If it needs to pass through some additional
                  > auditing/ test/ regulatory procedures - that should comprise activities
                  > which are additional to "main software". I know you can argue that till
                  > they pass this, you dont know if the code is shippable or not.

                  Perhaps more importantly, it won't provide value until they pass it. It
                  is an investment sitting on the shelf waiting to produce value. Waste.

                  Cheers, Ilja

                  __________________________________________________
                  Do You Yahoo!?
                  Tired of spam? Yahoo! Mail has the best spam protection around
                  http://mail.yahoo.com

                • Ron Morsicato
                  I assume as a medical device you have embedded software. Here are two very important things to do: 1. Abstract your hardware. Make sure you have a well-defined
                  Message 8 of 20 , Nov 1, 2007
                  • 0 Attachment
                    I assume as a medical device you have embedded software. Here are two very important things to do:

                    1. Abstract your hardware. Make sure you have a well-defined hardware abstract layer. On the hardware side of the interface, develop a mock object that mimics the hardware. (In fact, the mock object can produce non-functional scenarios, such as hazardous conditions or heavy loads, that can help you with other types of testing.)

                    2  Using the mock object,  maintain dual targeting - on the development machine and the embedded hardware. You can then automate testing to the hardware interface. Run automated tests on the development machine using the mock hardware

                    Distinguish between sprint (software integration) testing and release (software/hardware integration) testing. Run your automated tests to your hearts content (which ought to mean often) and the tests with hardware in the loop judiciously (here's where good engineering judgment comes in). In my experience, most errors are logical in nature and will be caught by automated testing on the development environment, if your architecture is as above. Thusly, you have cut down on the number of times you do the lengthy testing (which hopefully is a bear primarily because of dealing with the hardware).

                    Hope this helps,

                    Ron

                    Vikrama Dhiman wrote:
                    In that case I will ask what can I do make the process of passing the audit a bit painless. I am sure you already incorporate automated tests for some/ all parts of the audit requirements.
                     
                    Is the audit process painful despite that? Are they open to test/ audit frequently [every 30 days]? What happens if you only did test/ audits for each release and not a sprint?

                    Ilja Preuss <it@iljapreuss. de> wrote:
                    Vikrama Dhiman wrote:

                    > Lets examine it quite literally. "Potentially" shippable "software" -
                    > just because you have "potentially" shippable "software" does not mean
                    > you should but you can. If it needs to pass through some additional
                    > auditing/ test/ regulatory procedures - that should comprise activities
                    > which are additional to "main software". I know you can argue that till
                    > they pass this, you dont know if the code is shippable or not.

                    Perhaps more importantly, it won't provide value until they pass it. It
                    is an investment sitting on the shelf waiting to produce value. Waste.

                    Cheers, Ilja

                    ____________ _________ _________ _________ _________ __
                    Do You Yahoo!?
                    Tired of spam? Yahoo! Mail has the best spam protection around
                    http://mail. yahoo.com

                  • Rob Park
                    ... That s obviously a big problem. How much is (or could be) automated? Can things be parallelized? Imagine how much better things would be if you could get
                    Message 9 of 20 , Nov 1, 2007
                    • 0 Attachment
                      Can you talk more about this:

                      --- In scrumdevelopment@yahoogroups.com, "Mark Graybill" <Mark@...>
                      wrote:
                      >
                      > - Our full testing suite takes a full week.

                      That's obviously a big problem.

                      How much is (or could be) automated?
                      Can things be parallelized?

                      Imagine how much better things would be if you could get that down to
                      24 hours.

                      .rob.
                    • Rob Park
                      ... That s obviously a big problem. How much is (or could be) automated? Can things be parallelized? Imagine how much better things would be if you could get
                      Message 10 of 20 , Nov 1, 2007
                      • 0 Attachment
                        Can you talk more about this:

                        --- In scrumdevelopment@yahoogroups.com, "Mark Graybill" <Mark@...>
                        wrote:
                        >
                        > - Our full testing suite takes a full week.

                        That's obviously a big problem.

                        How much is (or could be) automated?
                        Can things be parallelized?

                        Imagine how much better things would be if you could get that down to
                        24 hours.

                        .rob.
                      • Mark Graybill
                        Thanks Wolfgang, I agree. We might be ready to file if our sprints were 4 weeks and we can automate most of our tests. Our software is advanced visualization
                        Message 11 of 20 , Nov 1, 2007
                        • 0 Attachment
                          Thanks Wolfgang, I agree.  We might be ready to file if our sprints were 4 weeks and we can automate most of our tests.  Our software is advanced visualization and so a few tests require a person to visually inspect the rendered images.
                           
                          There is more to discuss in this regard, but suffice me to say our test group has managers that are my peers, and we have a long way to go.
                           
                          I'm soliciting the forum to get experience and insight.  When I start hearing talk about whether something does or does not measure up to Scrum or Agile, I get the willies envisioning it all ending up as yet another silver bullet sighting.  While we're looking, time marches on.
                           
                          "Reality is here and is what it is; it doesn't change instantly; and it neve reaches ideal." 
                           
                          ----- Original Message -----
                          Sent: Thursday, November 01, 2007 4:31 AM
                          Subject: RE: [scrumdevelopment] Potentially releasable software

                          Hi Mark,
                           
                          "potentially releasable" does not mean you should go and file for a Class II approval every 4 weeks (or whatever your sprint cycle is). It only means that if you wanted to, you could go and do it. Quite clearly there is no sense in actually doing it at that frequency.
                          If you need a full week to run a complete cycle of tests, then I would suggest that there are probably improvements to be made to your testing. The vast majority of your testing should be automated and run in less than 15 minutes. There are numerous test frameworks available for just about any programming environment you can think of. That should reduce the number of tests that have to be run manually drastically and therefore shorten that time dramatically.
                           
                          Scrum is quite clear about the fact that there should be release planning and that the PO and the team should consider doing a "release sprint" prior to an actual release to do all those things that you would not add to a normal sprint. I am not an expert on this, because we write internal software and we actually do release every 2 weeks (but then we don't have to get FDA Class II approval), but I am sure others on this list can say more about this.
                           

                          Regards,

                          Wolfgang

                           


                          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Mark Graybill
                          Sent: 01 November 2007 00:40
                          To: scrumdevelopment@ yahoogroups. com
                          Subject: [scrumdevelopment] Potentially releasable software

                          A debate has brewed here regarding a statement someone made that we are not really doing Scrum because we do not have a releasable product at the end of every Sprint.
                           
                          The dilemma is this:
                           
                          - Our software is classified by the FDA as a Class II medical device so getting filing done every 30 days is a challenge.
                          - Our full testing suite takes a full week.
                          - In order to faciliate quicker ramp-up for the team in assimilating and being productive using Scrum, we are doing 15 day Sprints (in speaking with Mike Cohn I think this is a preference we have in common.) 
                          - From a project standpoint, 30 day Sprints are challenging and 15 day Sprints impose a near impossibility to produce a releasable product or even potentially releasable at the end of every Sprint.
                          - The idea of deploying at this frequency has not been well received by our customers.
                           
                          The proposal in debate is this:
                           
                          - Each user story involves a procedure to bring it to potentially releasable status.
                          - The end result is a feature tested and integrated into the product.
                          - But the product itself does not go through full testing every Sprint.
                          - Have alpha releases that only require an alpha contract and do that every two Sprints.
                           
                          What are some of your experiences and opinions in this regard?

                          Thanks,
                          Mark

                        • Mark Graybill
                          ... Apples and eggplant. :) ... I cannot do anything officially, unfortunately. The test team has managers that are my peers. Regardless, there are some tests
                          Message 12 of 20 , Nov 1, 2007
                          • 0 Attachment

                             
                            Ilja Preuss wrote:
                             
                            > I wonder how PatientKeeper is doing it.
                             
                            Apples and eggplant. :)
                             
                            > What are you planning to do to decrease this time?
                             
                            I cannot do anything officially, unfortunately.  The test team has managers that are my peers. Regardless, there are some tests that are hopelessly manual and tedious (see my previous post).
                             
                            It is however in my power to do sufficient testing on the development side that their side finds minimal issues.  Plus, we are trying to lead them toward their own change (from inside out).
                             
                            > What are the roadblocks to getting a releasable product in that time
                            frame?
                             
                            The process to getting us ready to file, the testing required, and the defect fixing afterwork and all the tracework and documentation.
                             
                            > That probably means that receiving a deployment is in some way
                            "painful"
                            > to your customers. Where is that pain coming from, and how
                            could you
                            > mitigate it? What would be needed to make it a
                            no-brainer?
                             
                            Good thinking.  Unfortunately, the pain lies in the market.  Special workflows, specific uses of the visualization, and specific DICOM characteristics make careful consideration for each case prudent.  We screw it up now.   So anything from video hardware upgrade requirements to clinical application bioalgorithms to image rendering to new DICOM enigmas, require great care in who gets what when.  It might work for most releases if every site had staging hardware so they can try it out before we screw up their workflow (and no hardware upgrades), but multiply that by about 4000.
                             
                            > I always thought that was the *definition* of a user story. Isn't
                            it?
                             
                            That is what I was thinking.
                             
                            > Sure. "Done done".
                             
                            We have a checklist explicating what "done" means.
                             
                            > If you don't fully test the product, how do you never whether you are
                            > really *done*?
                             
                            Good question...
                             
                            > What does "alpha contract" mean in this context, and how would it
                            help?
                             
                            That is just paperwork.  The FDA requires it.  Until we file, customers have restrictions how they use it.
                             
                            Thanks for the post - it was thought provoking!
                             
                            Cheers!
                            Mark
                          • Scott Preece
                            ... It ... The point of the Scrum approach is to deliver value to the customer. In many cases (maybe most cases) it s not feasible for every iteration to
                            Message 13 of 20 , Nov 2, 2007
                            • 0 Attachment
                              Ilja Preuss wrote:

                              | Vikrama Dhiman wrote:
                              |
                              | > Lets examine it quite literally. "Potentially" shippable "software" -
                              | > just because you have "potentially" shippable "software" does not mean
                              | > you should but you can. If it needs to pass through some additional
                              | > auditing/ test/ regulatory procedures - that should comprise activities
                              | > which are additional to "main software". I know you can argue that till
                              | > they pass this, you dont know if the code is shippable or not.
                              |
                              | Perhaps more importantly, it won't provide value until they pass it.
                              It
                              | is an investment sitting on the shelf waiting to produce value. Waste.
                              ---

                              The point of the Scrum approach is to deliver value to the customer. In
                              many cases (maybe most cases) it's not feasible for every iteration to
                              deliver a complete, shippable *product*, just shippable value. The
                              value delivered may be ready to ship, but it may not constitute
                              a complete product that makes sense for the customer to ship, or the
                              customer may simply not want to ship that product at that time (not
                              enough to satisfy her customers, too soon after the previous release,
                              etc.). The customer determines when there is enough value to
                              actually ship by setting priorities and the release plan. The customer
                              could equally decide at some point to throw in the towel and sell the
                              delivered value to another company.

                              Depending on the nature of the certification testing process, it might
                              make sense to treat that testing as a story that is scheduled for each
                              release or it might make sense to treat it as something the
                              customer
                              does after the software is delivered.

                              regards,
                              scott
                            • Roy Morien
                              I wonder if we are all singing from the same hymn book when we talk about customers and shippable software . My understanding of the concept of customer
                              Message 14 of 20 , Nov 2, 2007
                              • 0 Attachment
                                I wonder if we are all singing from the same hymn book when we talk about 'customers' and 'shippable software'.
                                 
                                My understanding of the concept of 'customer' in an iterative, agile environment does not just include the final user. Other developers whose software depends on your outcomes are also customers. So perhaps "shippable software" means software that is of value to the next 'customer', whoever that next customer may be; including other developers even on the same team.
                                 
                                Do others understand this in the same way as I do? Does making the concept of 'customer' more inclusive in this way help the discussion about 'shippable software'.
                                 
                                What it does do is essentially say that the outcome of every sprint could be 'shippable software', provided that software is useable 'as is' by the next in line 'customer'.
                                 
                                Regards
                                Roy Morien





                                To: scrumdevelopment@yahoogroups.com
                                From: sepreece@...
                                Date: Fri, 2 Nov 2007 08:40:53 -0700
                                Subject: [scrumdevelopment] Re: Potentially releasable software

                                Ilja Preuss wrote:

                                | Vikrama Dhiman wrote:
                                |
                                | > Lets examine it quite literally. "Potentially" shippable "software" -
                                | > just because you have "potentially" shippable "software" does not mean
                                | > you should but you can. If it needs to pass through some additional
                                | > auditing/ test/ regulatory procedures - that should comprise activities
                                | > which are additional to "main software". I know you can argue that till
                                | > they pass this, you dont know if the code is shippable or not.
                                |
                                | Perhaps more importantly, it won't provide value until they pass it.
                                It
                                | is an investment sitting on the shelf waiting to produce value. Waste.
                                ---

                                The point of the Scrum approach is to deliver value to the customer. In
                                many cases (maybe most cases) it's not feasible for every iteration to
                                deliver a complete, shippable *product*, just shippable value. The
                                value delivered may be ready to ship, but it may not constitute
                                a complete product that makes sense for the customer to ship, or the
                                customer may simply not want to ship that product at that time (not
                                enough to satisfy her customers, too soon after the previous release,
                                etc.). The customer determines when there is enough value to
                                actually ship by setting priorities and the release plan. The customer
                                could equally decide at some point to throw in the towel and sell the
                                delivered value to another company.

                                Depending on the nature of the certification testing process, it might
                                make sense to treat that testing as a story that is scheduled for each
                                release or it might make sense to treat it as something the
                                customer
                                does after the software is delivered.

                                regards,
                                scott




                                Find it at www.seek.com.au Your Future Starts Here. Dream it? Then be it!
                              • Ilja Preuss
                                The first time a feature produces real value is when an end user uses it in a production environment. The less delay there is between the development of a
                                Message 15 of 20 , Nov 4, 2007
                                • 0 Attachment
                                  The first time a feature produces "real" value is when an end user uses
                                  it in a production environment. The less delay there is between the
                                  development of a feature and an end user using it, the less waste.

                                  Of course there often is also value in delivering the feature to someone
                                  in between. I think it is generally true that that is less value than
                                  actually delivering to an end user. The better we get at delivering more
                                  often to the end user, the better.

                                  Am I missing something?

                                  Cheers, Ilja

                                  Roy Morien wrote:
                                  > I wonder if we are all singing from the same hymn book when we talk
                                  > about 'customers' and 'shippable software'.
                                  >
                                  > My understanding of the concept of 'customer' in an iterative, agile
                                  > environment does not just include the final user. Other developers whose
                                  > software depends on your outcomes are also customers. So perhaps
                                  > "shippable software" means software that is of value to the next
                                  > 'customer', whoever that next customer may be; including other
                                  > developers even on the same team.
                                  >
                                  > Do others understand this in the same way as I do? Does making the
                                  > concept of 'customer' more inclusive in this way help the discussion
                                  > about 'shippable software'.
                                  >
                                  > What it does do is essentially say that the outcome of every sprint
                                  > could be 'shippable software', provided that software is useable 'as is'
                                  > by the next in line 'customer'.
                                  >
                                  > Regards
                                  > Roy Morien
                                  >
                                  >
                                  >
                                  >
                                  > ------------------------------------------------------------------------
                                  > To: scrumdevelopment@yahoogroups.com
                                  > From: sepreece@...
                                  > Date: Fri, 2 Nov 2007 08:40:53 -0700
                                  > Subject: [scrumdevelopment] Re: Potentially releasable software
                                  >
                                  > Ilja Preuss wrote:
                                  >
                                  > | Vikrama Dhiman wrote:
                                  > |
                                  > | > Lets examine it quite literally. "Potentially" shippable
                                  > "software" -
                                  > | > just because you have "potentially" shippable "software" does
                                  > not mean
                                  > | > you should but you can. If it needs to pass through some additional
                                  > | > auditing/ test/ regulatory procedures - that should comprise
                                  > activities
                                  > | > which are additional to "main software". I know you can argue
                                  > that till
                                  > | > they pass this, you dont know if the code is shippable or not.
                                  > |
                                  > | Perhaps more importantly, it won't provide value until they pass it.
                                  > It
                                  > | is an investment sitting on the shelf waiting to produce value. Waste.
                                  > ---
                                  >
                                  > The point of the Scrum approach is to deliver value to the customer. In
                                  > many cases (maybe most cases) it's not feasible for every iteration to
                                  > deliver a complete, shippable *product*, just shippable value. The
                                  > value delivered may be ready to ship, but it may not constitute
                                  > a complete product that makes sense for the customer to ship, or the
                                  > customer may simply not want to ship that product at that time (not
                                  > enough to satisfy her customers, too soon after the previous release,
                                  > etc.). The customer determines when there is enough value to
                                  > actually ship by setting priorities and the release plan. The customer
                                  > could equally decide at some point to throw in the towel and sell the
                                  > delivered value to another company.
                                  >
                                  > Depending on the nature of the certification testing process, it might
                                  > make sense to treat that testing as a story that is scheduled for each
                                  > release or it might make sense to treat it as something the
                                  > customer
                                  > does after the software is delivered.
                                  >
                                  > regards,
                                  > scott
                                  >
                                  >
                                  >
                                  > ------------------------------------------------------------------------
                                  > Find it at www.seek.com.au Your Future Starts Here. Dream it? Then be
                                  > it!
                                  > <http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT>
                                  >
                                • Michael James
                                  ... Also less risk. Building subsystems while deferring their integration and testing is asking for trouble. Potentially shippable means shippable within
                                  Message 16 of 20 , Nov 4, 2007
                                  • 0 Attachment
                                    --- In scrumdevelopment@yahoogroups.com, Ilja Preuss <it@...> wrote:
                                    >
                                    > The first time a feature produces "real" value is when an end user uses
                                    > it in a production environment. The less delay there is between the
                                    > development of a feature and an end user using it, the less waste.

                                    Also less risk. Building subsystems while deferring their
                                    integration and testing is asking for trouble.

                                    "Potentially shippable" means shippable within one stabilization
                                    sprint, or less. I'd rather have a smaller number of potentially
                                    shippable features than a larger number of features that
                                    haven't been integrated with the end product.

                                    --mj
                                  • Dan Rawsthorne
                                    I don t think you are missing anything. However, it s not so simple. A deliverable feature may take several (in fact, many) stories to develop. The value we
                                    Message 17 of 20 , Nov 6, 2007
                                    • 0 Attachment
                                      I don't think you are missing anything. However, it's not so simple. A
                                      deliverable feature may take several (in fact, many) stories to develop.
                                      The value we deliver with each story may be potentially releasable, but
                                      that does not mean that the feature is usable or understandable by a
                                      "real" user. Therefore, we often need to release to an intermediate user
                                      representative that can understand the difference. This could be a
                                      tester, an analyst, or some other developer -- whatever it takes to
                                      mitigate the risk of if not being the right thing.

                                      Dan Rawsthorne, PhD, CST
                                      Senior Coach, Danube Technologies
                                      dan@..., 425-269-8628



                                      Ilja Preuss wrote:
                                      >
                                      > The first time a feature produces "real" value is when an end user uses
                                      > it in a production environment. The less delay there is between the
                                      > development of a feature and an end user using it, the less waste.
                                      >
                                      > Of course there often is also value in delivering the feature to someone
                                      > in between. I think it is generally true that that is less value than
                                      > actually delivering to an end user. The better we get at delivering more
                                      > often to the end user, the better.
                                      >
                                      > Am I missing something?
                                      >
                                      > Cheers, Ilja
                                      >
                                      > Roy Morien wrote:
                                      > > I wonder if we are all singing from the same hymn book when we talk
                                      > > about 'customers' and 'shippable software'.
                                      > >
                                      > > My understanding of the concept of 'customer' in an iterative, agile
                                      > > environment does not just include the final user. Other developers
                                      > whose
                                      > > software depends on your outcomes are also customers. So perhaps
                                      > > "shippable software" means software that is of value to the next
                                      > > 'customer', whoever that next customer may be; including other
                                      > > developers even on the same team.
                                      > >
                                      > > Do others understand this in the same way as I do? Does making the
                                      > > concept of 'customer' more inclusive in this way help the discussion
                                      > > about 'shippable software'.
                                      > >
                                      > > What it does do is essentially say that the outcome of every sprint
                                      > > could be 'shippable software', provided that software is useable 'as
                                      > is'
                                      > > by the next in line 'customer'.
                                      > >
                                      > > Regards
                                      > > Roy Morien
                                      > >
                                      > >
                                      > >
                                      > >
                                      > > ----------------------------------------------------------
                                      > > To: scrumdevelopment@yahoogroups.com
                                      > <mailto:scrumdevelopment%40yahoogroups.com>
                                      > > From: sepreece@... <mailto:sepreece%40yahoo.com>
                                      > > Date: Fri, 2 Nov 2007 08:40:53 -0700
                                      > > Subject: [scrumdevelopment] Re: Potentially releasable software
                                      > >
                                      > > Ilja Preuss wrote:
                                      > >
                                      > > | Vikrama Dhiman wrote:
                                      > > |
                                      > > | > Lets examine it quite literally. "Potentially" shippable
                                      > > "software" -
                                      > > | > just because you have "potentially" shippable "software" does
                                      > > not mean
                                      > > | > you should but you can. If it needs to pass through some additional
                                      > > | > auditing/ test/ regulatory procedures - that should comprise
                                      > > activities
                                      > > | > which are additional to "main software". I know you can argue
                                      > > that till
                                      > > | > they pass this, you dont know if the code is shippable or not.
                                      > > |
                                      > > | Perhaps more importantly, it won't provide value until they pass it.
                                      > > It
                                      > > | is an investment sitting on the shelf waiting to produce value. Waste.
                                      > > ---
                                      > >
                                      > > The point of the Scrum approach is to deliver value to the customer. In
                                      > > many cases (maybe most cases) it's not feasible for every iteration to
                                      > > deliver a complete, shippable *product*, just shippable value. The
                                      > > value delivered may be ready to ship, but it may not constitute
                                      > > a complete product that makes sense for the customer to ship, or the
                                      > > customer may simply not want to ship that product at that time (not
                                      > > enough to satisfy her customers, too soon after the previous release,
                                      > > etc.). The customer determines when there is enough value to
                                      > > actually ship by setting priorities and the release plan. The customer
                                      > > could equally decide at some point to throw in the towel and sell the
                                      > > delivered value to another company.
                                      > >
                                      > > Depending on the nature of the certification testing process, it might
                                      > > make sense to treat that testing as a story that is scheduled for each
                                      > > release or it might make sense to treat it as something the
                                      > > customer
                                      > > does after the software is delivered.
                                      > >
                                      > > regards,
                                      > > scott
                                      > >
                                      > >
                                      > >
                                      > > ----------------------------------------------------------
                                      > > Find it at www.seek.com.au Your Future Starts Here. Dream it? Then be
                                      > > it!
                                      > >
                                      > <http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT
                                      > <http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT>>
                                      >
                                      > >
                                      >
                                      >
                                    • jsfosdickcsp
                                      ... There are a lot of good comments in this thread already, but I have a couple thoughts one is more theoretical one is a practical answer to the original
                                      Message 18 of 20 , Nov 7, 2007
                                      • 0 Attachment
                                        --- In scrumdevelopment@yahoogroups.com, "Mark Graybill" <Mark@...> wrote:
                                        >
                                        > A debate has brewed here regarding a statement someone
                                        > made that we are not really doing Scrum because we do
                                        > not have a releasable product at the end of every Sprint.

                                        There are a lot of good comments in this thread already, but I have a
                                        couple thoughts one is more theoretical one is a practical answer to
                                        the original question.

                                        Whenever I hear someone, regardless of who it is, say, "You're not
                                        doing Scrum because...," my initial response is always to evaluate the
                                        understanding of Scrum implicit in the statement. Scrum has extremely
                                        few moving parts. That fact makes it extremely flexible, but likewise
                                        open to many different interpretations and, consequently, many
                                        different ways to approach the use of Scrum in practice. Anyone making
                                        such pronouncements should be cautious. Conversely it is possible to
                                        adhere to the "letter of the law but not the spirit". Ultimately our
                                        goal is to do software better. A slavish devotion to a particular
                                        dogma is counterproductive to that aim (and is in fact what has plague
                                        PMI style project management for decades).

                                        Now in terms of the question asked I would say that the terms are in
                                        adequately stated. What is meant by "releaseable product"? It strikes
                                        me that there are crucial modfiers missing from that term. It should
                                        read, "potentially releaseable product increment." It is an absurd
                                        standard to suggest, if this is what's really meant, to have a
                                        releaseable product at the end of every sprint. The first couple of
                                        sprints Scrum frontloads architecture and infrastructure types of
                                        tasks onto the backlog. Those are unlikely to result in a releaseable
                                        product in all but the simplest systems.

                                        So then is it simple pedantry to distinguish between "releaseable
                                        product" and "potentially releaseable product increment"? I would say
                                        no. A releaseable product is, by definition, "ready for primetime".
                                        That is to say its ready for end users on will do something useful.
                                        That is an end goal of the software development enterprise but it is
                                        not an intermediate step. Conversely a "potentially releaseable
                                        product increment" is a small piece of the system that does something,
                                        no matter how small that something is, and which has been as
                                        thoroughly vetted as possible with appropriate levels of design,
                                        coding, unit testing, system testing and MAYBE integration testing.
                                        There is no requirement, in my opinion, that it must do something
                                        useful to the target user by itself.

                                        Jimi Fosdick CSP
                                        blog: scrumblog.scrumpractitioner.com
                                      • Jeff Heinen
                                        I ve found it useful to use the distinction of potentially releasable vs. sellable. Each sprint ends with a delivered product increment that is
                                        Message 19 of 20 , Nov 7, 2007
                                        • 0 Attachment

                                          I’ve found it useful to use the distinction of “potentially releasable” vs. “sellable.”  Each sprint ends with a delivered product increment that is production-ready from a quality standpoint, and the PO could, at their discretion, choose to release it. That doesn’t mean that the product itself is sellable. The decision to actually release it would be contingent on the product having acquired enough business value to be “sellable.” The important point is that each sprint should end with the PO being able to make that choice.

                                           

                                          -Jeff H.

                                           

                                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of jsfosdickcsp
                                          Sent: Wednesday, November 07, 2007 10:14 AM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: [scrumdevelopment] Re: Potentially releasable software

                                           

                                          --- In scrumdevelopment@yahoogroups.com, "Mark Graybill" <Mark@...> wrote:

                                          >
                                          > A debate has brewed here regarding a statement someone
                                          > made that we are not really doing Scrum because we do
                                          > not have a releasable product at the end of every Sprint.

                                          There are a lot of good comments in this thread already, but I have a
                                          couple thoughts one is more theoretical one is a practical answer to
                                          the original question.

                                          Whenever I hear someone, regardless of who it is, say, "You're not
                                          doing Scrum because...," my initial response is always to evaluate the
                                          understanding of Scrum implicit in the statement. Scrum has extremely
                                          few moving parts. That fact makes it extremely flexible, but likewise
                                          open to many different interpretations and, consequently, many
                                          different ways to approach the use of Scrum in practice. Anyone making
                                          such pronouncements should be cautious. Conversely it is possible to
                                          adhere to the "letter of the law but not the spirit". Ultimately our
                                          goal is to do software better. A slavish devotion to a particular
                                          dogma is counterproductive to that aim (and is in fact what has plague
                                          PMI style project management for decades).

                                          Now in terms of the question asked I would say that the terms are in
                                          adequately stated. What is meant by "releaseable product"? It strikes
                                          me that there are crucial modfiers missing from that term. It should
                                          read, "potentially releaseable product increment." It is an absurd
                                          standard to suggest, if this is what's really meant, to have a
                                          releaseable product at the end of every sprint. The first couple of
                                          sprints Scrum frontloads architecture and infrastructure types of
                                          tasks onto the backlog. Those are unlikely to result in a releaseable
                                          product in all but the simplest systems.

                                          So then is it simple pedantry to distinguish between "releaseable
                                          product" and "potentially releaseable product increment"? I would say
                                          no. A releaseable product is, by definition, "ready for primetime".
                                          That is to say its ready for end users on will do something useful.
                                          That is an end goal of the software development enterprise but it is
                                          not an intermediate step. Conversely a "potentially releaseable
                                          product increment" is a small piece of the system that does something,
                                          no matter how small that something is, and which has been as
                                          thoroughly vetted as possible with appropriate levels of design,
                                          coding, unit testing, system testing and MAYBE integration testing.
                                          There is no requirement, in my opinion, that it must do something
                                          useful to the target user by itself.

                                          Jimi Fosdick CSP
                                          blog: scrumblog.scrumpractitioner.com

                                        • Michael James
                                          ... Yes, exactly. Every feature shown should be done/done/done , not just the smoke and mirrors of untested code. Whether it s sufficiently feature rich to
                                          Message 20 of 20 , Nov 7, 2007
                                          • 0 Attachment
                                            --- In scrumdevelopment@yahoogroups.com, "Jeff Heinen" <jheinen@...> wrote:
                                            >
                                            > I've found it useful to use the distinction of "potentially releasable"
                                            > vs. "sellable."

                                            Yes, exactly. Every feature shown should be "done/done/done", not
                                            just the smoke and mirrors of untested code. Whether it's sufficiently
                                            feature rich to release is a Product Owner call. Sometimes we need
                                            a "stabilization Sprint" for polish, not deferred testing.

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