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

Re: Potentially releasable software

Expand Messages
  • 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 1 of 20 , Nov 2, 2007
      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 2 of 20 , Nov 2, 2007
        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 3 of 20 , Nov 4, 2007
          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 4 of 20 , Nov 4, 2007
            --- 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 5 of 20 , Nov 6, 2007
              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 6 of 20 , Nov 7, 2007
                --- 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 7 of 20 , Nov 7, 2007

                  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 8 of 20 , Nov 7, 2007
                    --- 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.