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

RE: [scrumdevelopment] Sprint Demo Review of back-end platform work

Expand Messages
  • Paul Hudson
    Ø There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.
    Message 1 of 24 , Sep 3, 2008

      Ø  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.

       

      I think that depends on what your customer wants to see, and I’m not sure there’s any one answer to “what works best”. Who are you demonstrating to, and what do they want to take away from the demo?

       

      Paul.

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of David Goodman
      Sent: 03 September 2008 19:14
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Sprint Demo Review of back-end platform work

       

      Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.

       

      Any feedback/advice would be appreciated.

       

      Thanks!

      -David

       

       

      Big Fish Games, Inc. A New Game Every Day!™

       

    • Matt Grommes
      I ve had this same issue. We invited all the business/compliance/senior management to our demos and for the first few demos they were bored stiff by demos that
      Message 2 of 24 , Sep 3, 2008
        I've had this same issue. We invited all the business/compliance/senior management to our demos and for the first few demos they were bored stiff by demos that basically went "When I push this button, a bunch of stuff happens behind the scenes, and voila, a number appears over here". We've been trying to think of how to do demos on our next project so we don't drive people away with 2 hours of behind the scenes stuff. I'm afraid if we don't have people there, they'll take that as an excuse to say their input wasn't asked for.


        --
        Matt Grommes
        Mattorama Heavy Industries: http://mattorama.net
        Blind Teeth: http://blindteeth.com
        Idea Propulsion Lab: http://ideapropulsionlab.org


        On Wed, Sep 3, 2008 at 12:13 PM, David Goodman <david.goodman@...> wrote:

        Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.

         

        Any feedback/advice would be appreciated.

         

        Thanks!

        -David


        .




      • Ron Jeffries
        Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you ... Well, hmm. I fear that the right answer may be Don t do that . Did the Product Owner
        Message 3 of 24 , Sep 3, 2008
          Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
          wrote:

          > Hello, I wanted to get some input from the group on the best way to run
          > a Sprint Demo Review where strictly back-end platform components were
          > developed and there is nothing customer-facing to demo. There are many
          > options, such as running unit tests, going over design documents,
          > possibly powerpoint presentations, etc, but I am not sure what works
          > best.

          Well, hmm. I fear that the right answer may be "Don't do that".

          Did the Product Owner specify acceptance tests?

          Did the Product Owner actually /ask/ for this? Or did the developers
          plan this Sprint? If the latter, the P.O. should refuse to pay. :)

          Really. I know you don't like this answer, but what works best is
          "Don't do that". Second best is far behind. I guess I'd tell 'em
          what was done and run the unit tests. But really ... if we don't do
          something with business value, why should we get paid?

          Ron Jeffries
          www.XProgramming.com
          Anyone can make the simple complicated.
          Creativity is making the complicated simple. -- Charles Mingus
        • David Goodman
          Thanks guys, I appreciate your input. From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries Sent:
          Message 4 of 24 , Sep 3, 2008

            Thanks guys, I appreciate your input.

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
            Sent: Wednesday, September 03, 2008 1:04 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Sprint Demo Review of back-end platform work

             

            Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
            wrote:

            > Hello, I wanted to get some input from the group on the best way to run
            > a Sprint Demo Review where strictly back-end platform components were
            > developed and there is nothing customer-facing to demo. There are many
            > options, such as running unit tests, going over design documents,
            > possibly powerpoint presentations, etc, but I am not sure what works
            > best.

            Well, hmm. I fear that the right answer may be "Don't do that".

            Did the Product Owner specify acceptance tests?

            Did the Product Owner actually /ask/ for this? Or did the developers
            plan this Sprint? If the latter, the P.O. should refuse to pay. :)

            Really. I know you don't like this answer, but what works best is
            "Don't do that". Second best is far behind. I guess I'd tell 'em
            what was done and run the unit tests. But really ... if we don't do
            something with business value, why should we get paid?

            Ron Jeffries
            www.XProgramming.com
            Anyone can make the simple complicated.
            Creativity is making the complicated simple. -- Charles Mingus



             

            Big Fish Games, Inc. A New Game Every Day!™


          • James S. Fosdick, PMP, CSP
            I have to agree with Ron. Each sprint should include some direct business value that is demonstrable to the stakeholders and PO. Back-end and infrastructural
            Message 5 of 24 , Sep 3, 2008
              I have to agree with Ron. Each sprint should include some direct
              business value that is demonstrable to the stakeholders and PO.
              Back-end and infrastructural items usually support other things that
              have business value but don't contain any of their own (others will
              disagree). I'd also worry that your team is not developing "vertical
              slices" of functionality but is still developing "horizontally". The
              quick fix is to build a quick and dirty test application or mock UI of
              some kind that hits the back-end stuff. Otherwise you can show the
              unit tests running and passing, but really that's a pretty low value
              result. Did the PO sign off on this set of work in sprint planning?

              --- In scrumdevelopment@yahoogroups.com, "David Goodman"
              <david.goodman@...> wrote:
              >
              > Hello, I wanted to get some input from the group on the best way to run
              > a Sprint Demo Review where strictly back-end platform components were
              > developed and there is nothing customer-facing to demo. There are many
              > options, such as running unit tests, going over design documents,
              > possibly powerpoint presentations, etc, but I am not sure what works
              > best.
              >
              >
              >
              > Any feedback/advice would be appreciated.
              >
              >
              >
              > Thanks!
              >
              > -David
              >
              >
              >
              > Big Fish Games, Inc. A New Game Every Day!
              >
            • David Goodman
              I agree completely. This was a situation where product requirements are coming from the engineering team vs. product owner since the architecture work for the
              Message 6 of 24 , Sep 3, 2008

                I agree completely.  This was a situation where product requirements are coming from the engineering team vs. product owner since the architecture work for the next few sprints are basically mapped out.  Unfortunately the design does not allow for the most vertical development, but it is something to keep pushing for.

                 

                Thanks again

                 

                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of James S. Fosdick, PMP, CSP
                Sent: Wednesday, September 03, 2008 2:31 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                 

                I have to agree with Ron. Each sprint should include some direct
                business value that is demonstrable to the stakeholders and PO.
                Back-end and infrastructural items usually support other things that
                have business value but don't contain any of their own (others will
                disagree). I'd also worry that your team is not developing "vertical
                slices" of functionality but is still developing "horizontally". The
                quick fix is to build a quick and dirty test application or mock UI of
                some kind that hits the back-end stuff. Otherwise you can show the
                unit tests running and passing, but really that's a pretty low value
                result. Did the PO sign off on this set of work in sprint planning?

                --- In scrumdevelopment@yahoogroups.com, "David Goodman"
                <david.goodman@...> wrote:

                >
                > Hello, I wanted to get some input from the group on the best way to run
                > a Sprint Demo Review where strictly back-end platform components were
                > developed and there is nothing customer-facing to demo. There are many
                > options, such as running unit tests, going over design documents,
                > possibly powerpoint presentations, etc, but I am not sure what works
                > best.
                >
                >
                >
                > Any feedback/advice would be appreciated.
                >
                >
                >
                > Thanks!
                >
                > -David
                >
                >
                >
                > Big Fish Games, Inc. A New Game Every Day!
                >

              • Michael Wollin
                I second that thought. If at all possible, implement vertically not horizontally. Deep dive from UI to back end service and back. Sometimes, of course, it
                Message 7 of 24 , Sep 3, 2008
                  Re: [scrumdevelopment] Sprint Demo Review of back-end platform work I second that thought. If at all possible, implement vertically not horizontally. Deep dive from UI to back end service and back. Sometimes, of course, it can’t be helped (As an administrator, I need to use the newer version of MySQL), but usually there is a way.


                  On 9/3/08 4:04 PM, "Ron Jeffries" <ronjeffries@...> wrote:


                   

                  Hello, David.  On Wednesday, September 3, 2008, at 2:13:34 PM, you
                  wrote:

                  > Hello, I wanted to get some input from the group on the best way to run
                  > a Sprint Demo Review where strictly back-end platform components were
                  > developed and there is nothing customer-facing to demo.  There are many
                  > options, such as running unit tests, going over design documents,
                  > possibly powerpoint presentations, etc, but I am not sure what works
                  > best.

                  Well, hmm. I fear that the right answer may be "Don't do that".

                  Did the Product Owner specify acceptance tests?

                  Did the Product Owner actually /ask/ for this? Or did the developers
                  plan this Sprint? If the latter, the P.O. should refuse to pay. :)

                  Really. I know you don't like this answer, but what works best is
                  "Don't do that". Second best is far behind. I guess I'd tell 'em
                  what was done and run the unit tests. But really ... if we don't do
                  something with business value, why should we get paid?

                  Ron Jeffries
                  www.XProgramming.com
                  Anyone can make the simple complicated.
                  Creativity is making the complicated simple. -- Charles Mingus

                   
                      
                • aalanatlas
                  Hi David, I feel your pain. :-) Been there, done that, woulda got the T-shirt but my company is not big on swag. Here s my philosophy: It is worth the effort
                  Message 8 of 24 , Sep 3, 2008
                    Hi David,

                    I feel your pain. :-) Been there, done that, woulda got the T-shirt
                    but my company is not big on swag.

                    Here's my philosophy: "It is worth the effort to make visible the
                    capability that we just built."

                    So you build a demo to demonstrate anything (except for a purely no-
                    new-functions refactoring, which I hope you don't do too much anyway)
                    that your software does. You basically instrument the software and
                    then exercise it.

                    Put in realtime metrics for those behind-the-scenes functions that are
                    otherwise invisible, then display the results in flashy colors. Change
                    the output of system or functional tests to be more dramatic. Build a
                    dashboard to show realtime system status. Component tests that run
                    continuously can work well to show off that new component that runs
                    invisibly, tirelessly, and flawlessly in the background. Throughput,
                    used and free capacity, speed, number of rejected vs. accepted calls,
                    most anything will work and also turn out to be useful.

                    Any demo that shows how a system is working can also be used as a test
                    and/or a monitoring system. What I am suggesting is that you add a
                    task to build the monitoring for your software and when you do it, you
                    simply do it in a flashy, demo-ish way. When you do this, when you
                    make customer-invisible things visible, you end up with tests and
                    monitoring systems that you otherwise might not have had.

                    Anyway, it's an approach you might take. It's a bit of a leap of faith
                    because in effect you are agreeing to build specialized demo software
                    that you wouldn't otherwise need. What I'm saying is that the
                    specialized demo software of this type has a way of becoming useful in
                    and of itself.

                    alan

                    --- In scrumdevelopment@yahoogroups.com, "David Goodman"
                    <david.goodman@...> wrote:
                    >
                    > Hello, I wanted to get some input from the group on the best way to
                    run
                    > a Sprint Demo Review where strictly back-end platform components
                    were
                    > developed and there is nothing customer-facing to demo. There are
                    many
                    > options, such as running unit tests, going over design documents,
                    > possibly powerpoint presentations, etc, but I am not sure what works
                    > best.
                    >
                    >
                    >
                    > Any feedback/advice would be appreciated.
                    >
                    >
                    >
                    > Thanks!
                    >
                    > -David
                    >
                    >
                    >
                    > Big Fish Games, Inc. A New Game Every Day!
                    >
                  • Roy Morien
                    This seems a bit odd to me. A demo is a visual thing, so if there are no visuals, then there really is no demo. Perhaps the demo is Hey, you know how slow it
                    Message 9 of 24 , Sep 4, 2008
                      This seems a bit odd to me. A demo is a visual thing, so if there are no visuals, then there really is no demo.
                       
                      Perhaps the demo is 'Hey, you know how slow it has always been ... well, see how fast it is now because of all the work we have put in behind the scenes'. Perhaps such a demo is necessary to show that you haven't really been stuffing around doing nothing useful for the last couple of weeks.
                       
                      Since the earliest days of software prototyping (which I date from 1980) where a demo of deliverable software was a major part of the prototyping / development cycle, the rule has been the demos are visual activities. Demonstrating a long-winded batch update program on the mainframe, where the main visual was watching the lights on the console cycle through a pattern, was just not on! Yeah ... boring!!
                       
                      But then, if you have a group of people who have contributed, and want to continue to feel involved, a meeting where you list their requests and verify that you have attended to those requests, should be sufficient. Fast, and sufficient. Maybe a bit of an explanation (at their level or dimension of understanding) as to what you did to affect their request, would be useful. Even if it is 'behind the scenes stuff', they should be interested to know that you have done it. I wouldn't think that they would think you are telling them lies, just because you don't have a demo.

                      Regards,
                      Roy Morien






                      8:37 -0600
                      Subject: Re: [scrumdevelopment] Sprint Demo Review of back-end platform work


                      I've had this same issue. We invited all the business/compliance /senior management to our demos and for the first few demos they were bored stiff by demos that basically went "When I push this button, a bunch of stuff happens behind the scenes, and voila, a number appears over here". We've been trying to think of how to do demos on our next project so we don't drive people away with 2 hours of behind the scenes stuff. I'm afraid if we don't have people there, they'll take that as an excuse to say their input wasn't asked for.


                      --
                      Matt Grommes
                      Mattorama Heavy Industries: http://mattorama. net
                      Blind Teeth: http://blindteeth. com
                      Idea Propulsion Lab: http://ideapropulsi onlab.org


                      On Wed, Sep 3, 2008 at 12:13 PM, David Goodman <david.goodman@ bigfishgames. com> wrote:


                      Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.
                       
                      Any feedback/advice would be appreciated.
                       
                      Thanks!
                      -David

                      .







                      Find out: SEEK Salary Centre Are you paid what you're worth?
                    • aalanatlas
                      Ron, I get why you made your comment of Don t do that and I understand how it applies to cases where features are broken up horizontally rather then
                      Message 10 of 24 , Sep 4, 2008
                        Ron,

                        I get why you made your comment of "Don't do that" and I understand
                        how it applies to cases where features are broken up horizontally
                        rather then vertically. But I don't think that's the whole story.

                        Knowing your penchant for examples, I offer you two types of system
                        from my experience that fit David's description of features that don't
                        provide easily visible value. The "features" are vertical within their
                        systems and deliver the value they are meant to deliver. I'd like to
                        understand if you still somehow argue that they shouldn't be built in
                        that way.

                        1. Scalability (and other non-functional requirements)- "Your system
                        worked great last sprint. Now show me the same thing, but with 100,000
                        simultaneous users this time." Do we not take non-functional
                        requirements and turn them into Product Backlog items? It's not an
                        easy thing to make this an exciting demo, but there is great value to
                        the business in providing it.

                        2. Common (i.e., meant to be shared) back-end capabilities such as
                        throttling systems, caching systems, storage systems, or messaging
                        systems to name a few. The customers of these systems are often the
                        builders of other systems. What these systems do tends to be quite
                        invisible, in demo terms. The features of these systems are accessed
                        by their users via API calls or messages. Again, tough to demo, no?
                        Yet these systems have external, paying customers.

                        I've had to try to demo things like these, and it's hard. But it
                        doesn't mean that there is no value there, and I fail to see that it's
                        some kind of agile party foul to build them. If it is, then I'd like
                        to understand a better way to think about this.

                        Thanks.

                        alan

                        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                        <ronjeffries@...> wrote:
                        >
                        > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
                        > wrote:
                        >
                        > > Hello, I wanted to get some input from the group on the best way
                        to run
                        > > a Sprint Demo Review where strictly back-end platform components were
                        > > developed and there is nothing customer-facing to demo. There are
                        many
                        > > options, such as running unit tests, going over design documents,
                        > > possibly powerpoint presentations, etc, but I am not sure what works
                        > > best.
                        >
                        > Well, hmm. I fear that the right answer may be "Don't do that".
                        >
                        > Did the Product Owner specify acceptance tests?
                        >
                        > Did the Product Owner actually /ask/ for this? Or did the developers
                        > plan this Sprint? If the latter, the P.O. should refuse to pay. :)
                        >
                        > Really. I know you don't like this answer, but what works best is
                        > "Don't do that". Second best is far behind. I guess I'd tell 'em
                        > what was done and run the unit tests. But really ... if we don't do
                        > something with business value, why should we get paid?
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > Anyone can make the simple complicated.
                        > Creativity is making the complicated simple. -- Charles Mingus
                        >
                      • David H.
                        ... I think this is a good case for continous performance testing. I think what you mean is with approximately 100,000 simultaneous users . I would doubt that
                        Message 11 of 24 , Sep 4, 2008
                          >
                          > 1. Scalability (and other non-functional requirements)- "Your system
                          > worked great last sprint. Now show me the same thing, but with 100,000
                          > simultaneous users this time." Do we not take non-functional
                          > requirements and turn them into Product Backlog items? It's not an
                          > easy thing to make this an exciting demo, but there is great value to
                          > the business in providing it.
                          >
                          I think this is a good case for continous performance testing. I think
                          what you mean is "with approximately 100,000 simultaneous users". I
                          would doubt that you can perform a proper performance test on the
                          right hardware with the right simulated load within a sprint unless
                          the Product Owner has authorised you to do so, as you will not be
                          delivering a functional increment.

                          > 2. Common (i.e., meant to be shared) back-end capabilities such as
                          > throttling systems, caching systems, storage systems, or messaging
                          > systems to name a few. The customers of these systems are often the
                          > builders of other systems. What these systems do tends to be quite
                          > invisible, in demo terms. The features of these systems are accessed
                          > by their users via API calls or messages. Again, tough to demo, no?
                          > Yet these systems have external, paying customers.
                          >
                          These get called in the demo everytime you show end-to-end functionality, yes?

                          > I've had to try to demo things like these, and it's hard. But it
                          > doesn't mean that there is no value there, and I fail to see that it's
                          > some kind of agile party foul to build them. If it is, then I'd like
                          > to understand a better way to think about this.
                          >
                          What you describe is all very valid, however it should only be present
                          in the full stack. Performance and stress testing to me is a very
                          special case and there are numerous ways to go about it.

                          -d
                          --
                          Sent from gmail so do not trust this communication.
                          Do not send me sensitive information here, ask for my none-gmail accounts.

                          "Therefore the considerations of the intelligent always include both
                          benefit and harm." - Sun Tzu
                        • James Briant
                          This is a great example. Do they care how fast it is? If not, then don t do the work. They do? So how fast it is is something that has business value. Ok,
                          Message 12 of 24 , Sep 4, 2008
                            This is a great example. Do they care how fast it is? If not, then don't do the work. They do? So "how fast it is" is something that has business value. Ok, great, if "how fast it is" is a business value, how do you measure that? "How much it costs" has an entire department managing it, running spreadsheets and accounts software and databases. What do you have to show "How fast it is?".

                            Scrum is about visibility. If you don't have a graph that shows "this is how fast it was", and "this is how fast it is now after spending Persons x $$Salary x weeks" then your meeting will probably be pretty unsuccessful (though you may not know it at the time).

                            Since "How fast it is", is a core business value, are you going to show that graph just once, and then ignore it? What if you do work next week that slows it back down again? How will you know? What if a network switch fails, and it runs slowly: i.e. your tests all run really really fast, but who cares, because the real customer is screwed?

                            So you need to generate that data on-goingly. Gee, doing that by hand every week could be a pain. Sounds like a real-time performance graph is required to do your job, not just a fancy demo for a meeting.

                            And oh yeah, you have something to show for a meeting :-)

                            Jamie

                            On Thu, Sep 4, 2008 at 6:17 AM, Roy Morien <roymorien@...> wrote:

                            This seems a bit odd to me. A demo is a visual thing, so if there are no visuals, then there really is no demo.
                             
                            Perhaps the demo is 'Hey, you know how slow it has always been ... well, see how fast it is now because of all the work we have put in behind the scenes'. Perhaps such a demo is necessary to show that you haven't really been stuffing around doing nothing useful for the last couple of weeks.
                             
                            Since the earliest days of software prototyping (which I date from 1980) where a demo of deliverable software was a major part of the prototyping / development cycle, the rule has been the demos are visual activities. Demonstrating a long-winded batch update program on the mainframe, where the main visual was watching the lights on the console cycle through a pattern, was just not on! Yeah ... boring!!
                             
                            But then, if you have a group of people who have contributed, and want to continue to feel involved, a meeting where you list their requests and verify that you have attended to those requests, should be sufficient. Fast, and sufficient. Maybe a bit of an explanation (at their level or dimension of understanding) as to what you did to affect their request, would be useful. Even if it is 'behind the scenes stuff', they should be interested to know that you have done it. I wouldn't think that they would think you are telling them lies, just because you don't have a demo.

                            Regards,
                            Roy Morien






                            8:37 -0600
                            Subject: Re: [scrumdevelopment] Sprint Demo Review of back-end platform work


                            I've had this same issue. We invited all the business/compliance/senior management to our demos and for the first few demos they were bored stiff by demos that basically went "When I push this button, a bunch of stuff happens behind the scenes, and voila, a number appears over here". We've been trying to think of how to do demos on our next project so we don't drive people away with 2 hours of behind the scenes stuff. I'm afraid if we don't have people there, they'll take that as an excuse to say their input wasn't asked for.


                            --
                            Matt Grommes
                            Mattorama Heavy Industries: http://mattorama.net
                            Blind Teeth: http://blindteeth.com
                            Idea Propulsion Lab: http://ideapropulsionlab.org


                            On Wed, Sep 3, 2008 at 12:13 PM, David Goodman <david.goodman@...> wrote:


                            Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.
                             
                            Any feedback/advice would be appreciated.
                             
                            Thanks!
                            -David


                            .







                            Find out: SEEK Salary Centre Are you paid what you're worth?


                          • James Briant
                            ... If you don t have someone on the team that can knock up a real-time display showing all the simulated customer agents hitting your server, then you
                            Message 13 of 24 , Sep 4, 2008

                              >
                              > 1. Scalability (and other non-functional requirements)- "Your system
                              > worked great last sprint. Now show me the same thing, but with 100,000
                              > simultaneous users this time." Do we not take non-functional
                              > requirements and turn them into Product Backlog items? It's not an
                              > easy thing to make this an exciting demo, but there is great value to
                              > the business in providing it.

                               If you don't have someone on the team that can knock up a real-time display showing all the simulated customer agents hitting your server, then you probably wont be able to write the server either. If it can play the sound of a 1960's science-fiction dynamo like sound winding-up, all the better. Making the lights dim like a power shortage, priceless (you'll need X10 for that btw). :-)
                                
                              >
                              > 2. Common (i.e., meant to be shared) back-end capabilities such as
                              > throttling systems, caching systems, storage systems, or messaging
                              > systems to name a few. The customers of these systems are often the
                              > builders of other systems. What these systems do tends to be quite
                              > invisible, in demo terms. The features of these systems are accessed
                              > by their users via API calls or messages. Again, tough to demo, no?
                              > Yet these systems have external, paying customers.

                              Again, internal customers are a lie. Thats what you tell yourself to pretend that you are doing scrum while simply preserving failed business/political structures.

                              What these systems do is:

                              a) reliability
                              b) speed
                              c) manage power consumption.

                              All are highly demoable, and should be visually displayed at all times on a highly visible screen

                              I'd also be highly suspect of the statement "common (meant to be shared)". Why are they meant to be shared? Examine your thinking there and you will find it has nothing to do with the customer other than "reducing costs". How does it affect responsiveness to customer needs? Does the real customer care about server speed, for example? Who knows this? Bottom line: "reducing costs" is one of many reasons to anything, but those other reasons may be more important and may be better served by not sharing. 

                              Quite often, because the real needs of the customer are now filtered through engineering "customers", into a core team of back-end developers beholden to multiple groups, you find that (a) there are no cost savings and (b) the customers needs are not met. Basically there is no difference between:

                              customer -> design document -> programming team
                              customer -> programming team A -> programming team B

                              If you are doing either of the above, you aren't doing scrum.

                              Jamie

                            • woynam
                              ... No, you don t have to take non-functional requirements and turn them into PB items. Non-functional requires always affects a functional requirement. If you
                              Message 14 of 24 , Sep 4, 2008
                                --- In scrumdevelopment@yahoogroups.com, "aalanatlas" <alanatat@...>
                                wrote:
                                >
                                > Ron,
                                >
                                > I get why you made your comment of "Don't do that" and I understand
                                > how it applies to cases where features are broken up horizontally
                                > rather then vertically. But I don't think that's the whole story.
                                >
                                > Knowing your penchant for examples, I offer you two types of system
                                > from my experience that fit David's description of features that don't
                                > provide easily visible value. The "features" are vertical within their
                                > systems and deliver the value they are meant to deliver. I'd like to
                                > understand if you still somehow argue that they shouldn't be built in
                                > that way.
                                >
                                > 1. Scalability (and other non-functional requirements)- "Your system
                                > worked great last sprint. Now show me the same thing, but with 100,000
                                > simultaneous users this time." Do we not take non-functional
                                > requirements and turn them into Product Backlog items? It's not an
                                > easy thing to make this an exciting demo, but there is great value to
                                > the business in providing it.

                                No, you don't have to take non-functional requirements and turn them
                                into PB items. Non-functional requires always affects a functional
                                requirement. If you add the functional requirement, i.e.
                                story/feature, to the backlog, along with the impact of the
                                non-functional requirement, you'll have something to demo.

                                For example, "As a user, I want to enter an order and have it respond
                                within 2 milliseconds while the system is supporting 100,000 users."

                                The tasks that address the internals of the system are associated with
                                the feature, so you're always addressing something that provides
                                business value. If no story is affected by the non-functional
                                requirement, then why would you do it?

                                >
                                > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                > throttling systems, caching systems, storage systems, or messaging
                                > systems to name a few. The customers of these systems are often the
                                > builders of other systems. What these systems do tends to be quite
                                > invisible, in demo terms. The features of these systems are accessed
                                > by their users via API calls or messages. Again, tough to demo, no?
                                > Yet these systems have external, paying customers.
                                >
                                > I've had to try to demo things like these, and it's hard. But it
                                > doesn't mean that there is no value there, and I fail to see that it's
                                > some kind of agile party foul to build them. If it is, then I'd like
                                > to understand a better way to think about this.

                                Don't these things affect some feature of the system? Why do we cache?
                                To speed things up. OK, so demo a feature with and without the cache
                                to show how it speeds things up. If the PO yawns, then it must have
                                not been a high-priority item to begin with.

                                The other important aspect about always (trying to) tying things to
                                features is that it demonstrates that the software is always ready for
                                prime time. If you build specific components to address non-functional
                                requirements, but you don't integrate and test them in the real
                                software, then you really don't know if it's going to have the desired
                                affect.

                                I've seen plenty of cases where folks spent a great deal of time
                                building the next greatest thing, and when they finally plugged it
                                into the actual application, it didn't have the desired affect. In
                                many cases it was because there were other bottlenecks that were
                                bigger, or hidden.

                                >
                                > Thanks.
                                >
                                > alan
                                >
                                > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                > <ronjeffries@> wrote:
                                > >
                                > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
                                > > wrote:
                                > >
                                > > > Hello, I wanted to get some input from the group on the best way
                                > to run
                                > > > a Sprint Demo Review where strictly back-end platform components
                                were
                                > > > developed and there is nothing customer-facing to demo. There are
                                > many
                                > > > options, such as running unit tests, going over design documents,
                                > > > possibly powerpoint presentations, etc, but I am not sure what works
                                > > > best.
                                > >
                                > > Well, hmm. I fear that the right answer may be "Don't do that".
                                > >
                                > > Did the Product Owner specify acceptance tests?
                                > >
                                > > Did the Product Owner actually /ask/ for this? Or did the developers
                                > > plan this Sprint? If the latter, the P.O. should refuse to pay. :)
                                > >
                                > > Really. I know you don't like this answer, but what works best is
                                > > "Don't do that". Second best is far behind. I guess I'd tell 'em
                                > > what was done and run the unit tests. But really ... if we don't do
                                > > something with business value, why should we get paid?
                                > >
                                > > Ron Jeffries
                                > > www.XProgramming.com
                                > > Anyone can make the simple complicated.
                                > > Creativity is making the complicated simple. -- Charles Mingus
                                > >
                                >
                              • Ron Jeffries
                                Hello, alan. You ve already had some great answers, which I support. I ll comment just a bit anyway, because I can t resist and there is some slim change it
                                Message 15 of 24 , Sep 4, 2008
                                  Hello, alan.

                                  You've already had some great answers, which I support. I'll comment
                                  just a bit anyway, because I can't resist and there is some slim
                                  change it might be useful.

                                  On Thursday, September 4, 2008, at 3:21:21 PM, you wrote:

                                  > I get why you made your comment of "Don't do that" and I understand
                                  > how it applies to cases where features are broken up horizontally
                                  > rather then vertically. But I don't think that's the whole story.

                                  We may be reversing horizontal and vertical. People seem mostly to
                                  use vertical to mean "thin story cutting thru all layers", and
                                  that's how I was using the term.

                                  It is my view that there is no reason ever to have any other kind of
                                  story. I freely grant that this sounds insane, but it isn't. :)

                                  > Knowing your penchant for examples, I offer you two types of system
                                  > from my experience that fit David's description of features that don't
                                  > provide easily visible value. The "features" are vertical within their
                                  > systems and deliver the value they are meant to deliver. I'd like to
                                  > understand if you still somehow argue that they shouldn't be built in
                                  > that way.

                                  > 1. Scalability (and other non-functional requirements)- "Your system
                                  > worked great last sprint. Now show me the same thing, but with 100,000
                                  > simultaneous users this time." Do we not take non-functional
                                  > requirements and turn them into Product Backlog items? It's not an
                                  > easy thing to make this an exciting demo, but there is great value to
                                  > the business in providing it.

                                  As has been pointed out, this is not a non-functional requirement at
                                  all. It is a direct business requirement. It can be demonstrated by
                                  showing the response time of the old system under load, and the new
                                  one. The quality of the loading might of course vary, and you might
                                  have to say something about why the figures you can demonstrate will
                                  scale as requested when you put it on the whole server farm. But it
                                  is eminently demonstrable as far as I can see.

                                  > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                  > throttling systems, caching systems, storage systems, or messaging
                                  > systems to name a few. The customers of these systems are often the
                                  > builders of other systems. What these systems do tends to be quite
                                  > invisible, in demo terms. The features of these systems are accessed
                                  > by their users via API calls or messages. Again, tough to demo, no?
                                  > Yet these systems have external, paying customers.

                                  I'm not sure that I understand this, so if this doesn't make sense,
                                  try again with more specifics.

                                  Suppose someone asks us for a caching system. We ask them what they
                                  mean by that and we ask them how they plan to test it when they get
                                  it. (Since they are acting as Product Owner, they have to be able to
                                  answer that question.)

                                  Then we write the test and show them the test running. Voila, demo.

                                  > I've had to try to demo things like these, and it's hard. But it
                                  > doesn't mean that there is no value there, and I fail to see that it's
                                  > some kind of agile party foul to build them. If it is, then I'd like
                                  > to understand a better way to think about this.

                                  If they can't tell whether you did the feature or not, don't do it.
                                  If they /can/ tell, there's your demo.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Those who believe complexity is elegant or required don't understand
                                  the problem. -- John Streiff
                                • aalanatlas
                                  ... We re using the terms the same way. My phrasing was inside-out, but I meant it in the same way as you. Building features vertically through all parts of
                                  Message 16 of 24 , Sep 5, 2008
                                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                    <ronjeffries@...> wrote:
                                    >
                                    > Hello, alan.
                                    >
                                    > You've already had some great answers, which I support. I'll comment
                                    > just a bit anyway, because I can't resist and there is some slim
                                    > change it might be useful.
                                    >
                                    > On Thursday, September 4, 2008, at 3:21:21 PM, you wrote:
                                    >
                                    > > I get why you made your comment of "Don't do that" and I understand
                                    > > how it applies to cases where features are broken up horizontally
                                    > > rather then vertically. But I don't think that's the whole story.
                                    >
                                    > We may be reversing horizontal and vertical. People seem mostly to
                                    > use vertical to mean "thin story cutting thru all layers", and
                                    > that's how I was using the term.

                                    We're using the terms the same way. My phrasing was inside-out, but I
                                    meant it in the same way as you. Building features vertically through
                                    all parts of the system at once is the correct thing to do. I get
                                    that. I am not advocating build the database access layer and calling
                                    it a feature.

                                    >
                                    > It is my view that there is no reason ever to have any other kind of
                                    > story. I freely grant that this sounds insane, but it isn't. :)

                                    I wholeheartedly agree. Where we seem to differ is that I see examples
                                    where the "top of the stack" ends at an api, which is hard to demo, so
                                    I tried to make the point that you can make those visible and that
                                    there is value in doing so. This discussion started out to be all
                                    about getting away from the "press a button and nothing happens for a
                                    while and then a dot appears on the screen" kind of demo.

                                    >
                                    > > Knowing your penchant for examples, I offer you two types of system
                                    > > from my experience that fit David's description of features that don't
                                    > > provide easily visible value. The "features" are vertical within their
                                    > > systems and deliver the value they are meant to deliver. I'd like to
                                    > > understand if you still somehow argue that they shouldn't be built in
                                    > > that way.
                                    >
                                    > > 1. Scalability (and other non-functional requirements)- "Your system
                                    > > worked great last sprint. Now show me the same thing, but with 100,000
                                    > > simultaneous users this time." Do we not take non-functional
                                    > > requirements and turn them into Product Backlog items? It's not an
                                    > > easy thing to make this an exciting demo, but there is great value to
                                    > > the business in providing it.
                                    >
                                    > As has been pointed out, this is not a non-functional requirement at
                                    > all. It is a direct business requirement. It can be demonstrated by
                                    > showing the response time of the old system under load, and the new
                                    > one. The quality of the loading might of course vary, and you might
                                    > have to say something about why the figures you can demonstrate will
                                    > scale as requested when you put it on the whole server farm. But it
                                    > is eminently demonstrable as far as I can see.

                                    Sorry, I use "nonfunctional requirement" based on learning the term
                                    from Ken in CSM class. It means just what you said, which is a
                                    business requirement that isn't an end user function. except that it
                                    tends to be a really boring demo. My post was simply to point out ways
                                    to make it a more exciting demo.

                                    >
                                    > > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                    > > throttling systems, caching systems, storage systems, or messaging
                                    > > systems to name a few. The customers of these systems are often the
                                    > > builders of other systems. What these systems do tends to be quite
                                    > > invisible, in demo terms. The features of these systems are accessed
                                    > > by their users via API calls or messages. Again, tough to demo, no?
                                    > > Yet these systems have external, paying customers.
                                    >
                                    > I'm not sure that I understand this, so if this doesn't make sense,
                                    > try again with more specifics.
                                    >
                                    > Suppose someone asks us for a caching system. We ask them what they
                                    > mean by that and we ask them how they plan to test it when they get
                                    > it. (Since they are acting as Product Owner, they have to be able to
                                    > answer that question.)
                                    >
                                    > Then we write the test and show them the test running. Voila, demo.

                                    Yes, that's exactly true also. The only problem in practice, which is
                                    what I was responding to originally, is that showing the tests running
                                    is not a compelling demo to many audiences. That's the problem that I
                                    saw discussed in the original post to this thread.

                                    >
                                    > > I've had to try to demo things like these, and it's hard. But it
                                    > > doesn't mean that there is no value there, and I fail to see that it's
                                    > > some kind of agile party foul to build them. If it is, then I'd like
                                    > > to understand a better way to think about this.
                                    >
                                    > If they can't tell whether you did the feature or not, don't do it.

                                    Agree.

                                    > If they /can/ tell, there's your demo.

                                    Only if you're willing to accept an utterly boring demo in some cases.
                                    Otherwise, creativity is called for. That's my only point.

                                    >
                                    > Ron Jeffries
                                    > www.XProgramming.com
                                    > Those who believe complexity is elegant or required don't understand
                                    > the problem. -- John Streiff
                                    >
                                  • aalanatlas
                                    ... Yes, I m of course familiar with that construct. But consider what happens when you only built the system for 1000 users and the unthinkable happened...you
                                    Message 17 of 24 , Sep 5, 2008
                                      --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, "aalanatlas" <alanatat@>
                                      > wrote:
                                      > >
                                      > > Ron,
                                      > >
                                      > > I get why you made your comment of "Don't do that" and I understand
                                      > > how it applies to cases where features are broken up horizontally
                                      > > rather then vertically. But I don't think that's the whole story.
                                      > >
                                      > > Knowing your penchant for examples, I offer you two types of system
                                      > > from my experience that fit David's description of features that don't
                                      > > provide easily visible value. The "features" are vertical within their
                                      > > systems and deliver the value they are meant to deliver. I'd like to
                                      > > understand if you still somehow argue that they shouldn't be built in
                                      > > that way.
                                      > >
                                      > > 1. Scalability (and other non-functional requirements)- "Your system
                                      > > worked great last sprint. Now show me the same thing, but with 100,000
                                      > > simultaneous users this time." Do we not take non-functional
                                      > > requirements and turn them into Product Backlog items? It's not an
                                      > > easy thing to make this an exciting demo, but there is great value to
                                      > > the business in providing it.
                                      >
                                      > No, you don't have to take non-functional requirements and turn them
                                      > into PB items. Non-functional requires always affects a functional
                                      > requirement. If you add the functional requirement, i.e.
                                      > story/feature, to the backlog, along with the impact of the
                                      > non-functional requirement, you'll have something to demo.
                                      >
                                      > For example, "As a user, I want to enter an order and have it respond
                                      > within 2 milliseconds while the system is supporting 100,000 users."
                                      >
                                      > The tasks that address the internals of the system are associated with
                                      > the feature, so you're always addressing something that provides
                                      > business value. If no story is affected by the non-functional
                                      > requirement, then why would you do it?

                                      Yes, I'm of course familiar with that construct. But consider what
                                      happens when you only built the system for 1000 users and the
                                      unthinkable happened...you got successful beyond your wildest dreams.
                                      Now all of a sudden you need to add no new features but a lot of load
                                      handling capability. That makes it a story for me, since the team will
                                      be doing nothing else until the system can handle the new load. And I
                                      can guarantee that there will be anxious executives who really want to
                                      see a demo when you claim you're done. At least at my company.


                                      >
                                      > >
                                      > > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                      > > throttling systems, caching systems, storage systems, or messaging
                                      > > systems to name a few. The customers of these systems are often the
                                      > > builders of other systems. What these systems do tends to be quite
                                      > > invisible, in demo terms. The features of these systems are accessed
                                      > > by their users via API calls or messages. Again, tough to demo, no?
                                      > > Yet these systems have external, paying customers.
                                      > >
                                      > > I've had to try to demo things like these, and it's hard. But it
                                      > > doesn't mean that there is no value there, and I fail to see that it's
                                      > > some kind of agile party foul to build them. If it is, then I'd like
                                      > > to understand a better way to think about this.
                                      >
                                      > Don't these things affect some feature of the system? Why do we cache?
                                      > To speed things up. OK, so demo a feature with and without the cache
                                      > to show how it speeds things up. If the PO yawns, then it must have
                                      > not been a high-priority item to begin with.

                                      Yes I get that too. Now put yourself into the position of being a
                                      separate company that just builds caches. you need to release a fully
                                      production-ready cache to your customers. They will pay to use it and
                                      be happy. They are your customers. Before they see your product, you
                                      will complete a sprint and need to demo the cache to your own company
                                      (and maybe some potential customers also). So what do you do? You find
                                      ways to build a non-boring demo of the cache. That's all this
                                      discussion is about, right? The original question was about building
                                      compelling demos of back-end functionality that often does not demo in
                                      an exciting way.

                                      >
                                      > The other important aspect about always (trying to) tying things to
                                      > features is that it demonstrates that the software is always ready for
                                      > prime time. If you build specific components to address non-functional
                                      > requirements, but you don't integrate and test them in the real
                                      > software, then you really don't know if it's going to have the desired
                                      > affect.
                                      >
                                      > I've seen plenty of cases where folks spent a great deal of time
                                      > building the next greatest thing, and when they finally plugged it
                                      > into the actual application, it didn't have the desired affect. In
                                      > many cases it was because there were other bottlenecks that were
                                      > bigger, or hidden.
                                      >
                                      > >
                                      > > Thanks.
                                      > >
                                      > > alan
                                      > >
                                      > > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                      > > <ronjeffries@> wrote:
                                      > > >
                                      > > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
                                      > > > wrote:
                                      > > >
                                      > > > > Hello, I wanted to get some input from the group on the best way
                                      > > to run
                                      > > > > a Sprint Demo Review where strictly back-end platform components
                                      > were
                                      > > > > developed and there is nothing customer-facing to demo. There are
                                      > > many
                                      > > > > options, such as running unit tests, going over design documents,
                                      > > > > possibly powerpoint presentations, etc, but I am not sure what
                                      works
                                      > > > > best.
                                      > > >
                                      > > > Well, hmm. I fear that the right answer may be "Don't do that".
                                      > > >
                                      > > > Did the Product Owner specify acceptance tests?
                                      > > >
                                      > > > Did the Product Owner actually /ask/ for this? Or did the developers
                                      > > > plan this Sprint? If the latter, the P.O. should refuse to pay. :)
                                      > > >
                                      > > > Really. I know you don't like this answer, but what works best is
                                      > > > "Don't do that". Second best is far behind. I guess I'd tell 'em
                                      > > > what was done and run the unit tests. But really ... if we don't do
                                      > > > something with business value, why should we get paid?
                                      > > >
                                      > > > Ron Jeffries
                                      > > > www.XProgramming.com
                                      > > > Anyone can make the simple complicated.
                                      > > > Creativity is making the complicated simple. -- Charles Mingus
                                      > > >
                                      > >
                                      >
                                    • David Goodman
                                      Wish me luck, I m executing in 10..... J From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of aalanatlas Sent: Friday,
                                      Message 18 of 24 , Sep 5, 2008

                                        Wish me luck, I’m executing in 10….. J

                                         

                                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of aalanatlas
                                        Sent: Friday, September 05, 2008 1:32 PM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                         

                                        --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:

                                        >
                                        > --- In scrumdevelopment@yahoogroups.com,
                                        "aalanatlas" <alanatat@>
                                        > wrote:
                                        > >
                                        > > Ron,
                                        > >
                                        > > I get why you made your comment of "Don't do that" and I
                                        understand
                                        > > how it applies to cases where features are broken up horizontally
                                        > > rather then vertically. But I don't think that's the whole story.
                                        > >
                                        > > Knowing your penchant for examples, I offer you two types of system
                                        > > from my experience that fit David's description of features that
                                        don't
                                        > > provide easily visible value. The "features" are vertical
                                        within their
                                        > > systems and deliver the value they are meant to deliver. I'd like to
                                        > > understand if you still somehow argue that they shouldn't be built in
                                        > > that way.
                                        > >
                                        > > 1. Scalability (and other non-functional requirements)- "Your
                                        system
                                        > > worked great last sprint. Now show me the same thing, but with 100,000
                                        > > simultaneous users this time." Do we not take non-functional
                                        > > requirements and turn them into Product Backlog items? It's not an
                                        > > easy thing to make this an exciting demo, but there is great value to
                                        > > the business in providing it.
                                        >
                                        > No, you don't have to take non-functional requirements and turn them
                                        > into PB items. Non-functional requires always affects a functional
                                        > requirement. If you add the functional requirement, i.e.
                                        > story/feature, to the backlog, along with the impact of the
                                        > non-functional requirement, you'll have something to demo.
                                        >
                                        > For example, "As a user, I want to enter an order and have it respond
                                        > within 2 milliseconds while the system is supporting 100,000 users."
                                        >
                                        > The tasks that address the internals of the system are associated with
                                        > the feature, so you're always addressing something that provides
                                        > business value. If no story is affected by the non-functional
                                        > requirement, then why would you do it?

                                        Yes, I'm of course familiar with that construct. But consider what
                                        happens when you only built the system for 1000 users and the
                                        unthinkable happened...you got successful beyond your wildest dreams.
                                        Now all of a sudden you need to add no new features but a lot of load
                                        handling capability. That makes it a story for me, since the team will
                                        be doing nothing else until the system can handle the new load. And I
                                        can guarantee that there will be anxious executives who really want to
                                        see a demo when you claim you're done. At least at my company.

                                        >
                                        > >
                                        > > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                        > > throttling systems, caching systems, storage systems, or messaging
                                        > > systems to name a few. The customers of these systems are often the
                                        > > builders of other systems. What these systems do tends to be quite
                                        > > invisible, in demo terms. The features of these systems are accessed
                                        > > by their users via API calls or messages. Again, tough to demo, no?
                                        > > Yet these systems have external, paying customers.
                                        > >
                                        > > I've had to try to demo things like these, and it's hard. But it
                                        > > doesn't mean that there is no value there, and I fail to see that
                                        it's
                                        > > some kind of agile party foul to build them. If it is, then I'd like
                                        > > to understand a better way to think about this.
                                        >
                                        > Don't these things affect some feature of the system? Why do we cache?
                                        > To speed things up. OK, so demo a feature with and without the cache
                                        > to show how it speeds things up. If the PO yawns, then it must have
                                        > not been a high-priority item to begin with.

                                        Yes I get that too. Now put yourself into the position of being a
                                        separate company that just builds caches. you need to release a fully
                                        production-ready cache to your customers. They will pay to use it and
                                        be happy. They are your customers. Before they see your product, you
                                        will complete a sprint and need to demo the cache to your own company
                                        (and maybe some potential customers also). So what do you do? You find
                                        ways to build a non-boring demo of the cache. That's all this
                                        discussion is about, right? The original question was about building
                                        compelling demos of back-end functionality that often does not demo in
                                        an exciting way.

                                        >
                                        > The other important aspect about always (trying to) tying things to
                                        > features is that it demonstrates that the software is always ready for
                                        > prime time. If you build specific components to address non-functional
                                        > requirements, but you don't integrate and test them in the real
                                        > software, then you really don't know if it's going to have the desired
                                        > affect.
                                        >
                                        > I've seen plenty of cases where folks spent a great deal of time
                                        > building the next greatest thing, and when they finally plugged it
                                        > into the actual application, it didn't have the desired affect. In
                                        > many cases it was because there were other bottlenecks that were
                                        > bigger, or hidden.
                                        >
                                        > >
                                        > > Thanks.
                                        > >
                                        > > alan
                                        > >
                                        > > --- In scrumdevelopment@yahoogroups.com,
                                        Ron Jeffries
                                        > > <ronjeffries@> wrote:
                                        > > >
                                        > > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM,
                                        you
                                        > > > wrote:
                                        > > >
                                        > > > > Hello, I wanted to get some input from the group on the
                                        best way
                                        > > to run
                                        > > > > a Sprint Demo Review where strictly back-end platform
                                        components
                                        > were
                                        > > > > developed and there is nothing customer-facing to demo.
                                        There are
                                        > > many
                                        > > > > options, such as running unit tests, going over design
                                        documents,
                                        > > > > possibly powerpoint presentations, etc, but I am not sure
                                        what
                                        works
                                        > > > > best.
                                        > > >
                                        > > > Well, hmm. I fear that the right answer may be "Don't do
                                        that".
                                        > > >
                                        > > > Did the Product Owner specify acceptance tests?
                                        > > >
                                        > > > Did the Product Owner actually /ask/ for this? Or did the
                                        developers
                                        > > > plan this Sprint? If the latter, the P.O. should refuse to pay.
                                        :)
                                        > > >
                                        > > > Really. I know you don't like this answer, but what works best
                                        is
                                        > > > "Don't do that". Second best is far behind. I guess
                                        I'd tell 'em
                                        > > > what was done and run the unit tests. But really ... if we don't
                                        do
                                        > > > something with business value, why should we get paid?
                                        > > >
                                        > > > Ron Jeffries
                                        > > > www.XProgramming.com
                                        > > > Anyone can make the simple complicated.
                                        > > > Creativity is making the complicated simple. -- Charles Mingus
                                        > > >
                                        > >
                                        >



                                         

                                        Big Fish Games, Inc. A New Game Every Day!™


                                      • Peter Stevens
                                        Hi Roy, Excitement is definitely the word of the day. SAP does dueling demos at their annual customer gatherings. Lot s of people. Noisemakers. Voting. Time
                                        Message 19 of 24 , Sep 5, 2008
                                          Hi Roy,

                                          Excitement is definitely the word of the day.

                                          SAP does "dueling demos" at their annual customer gatherings. Lot's of people. Noisemakers. Voting. Time Boxed with a countdown clock per contestant. Limit 1 Powerpoint Slide/demo. Prizes for the winners.

                                          The first time I saw such an event, SAP's answer to the vi editor carried the day. Hard to believe what you can accomplish with the right mix of show and enthusiasm!

                                          Cheers,

                                          Peter

                                          Roy Morien schrieb:

                                          This seems a bit odd to me. A demo is a visual thing, so if there are no visuals, then there really is no demo.
                                           
                                          Perhaps the demo is 'Hey, you know how slow it has always been ... well, see how fast it is now because of all the work we have put in behind the scenes'. Perhaps such a demo is necessary to show that you haven't really been stuffing around doing nothing useful for the last couple of weeks.
                                           
                                          Since the earliest days of software prototyping (which I date from 1980) where a demo of deliverable software was a major part of the prototyping / development cycle, the rule has been the demos are visual activities. Demonstrating a long-winded batch update program on the mainframe, where the main visual was watching the lights on the console cycle through a pattern, was just not on! Yeah ... boring!!
                                           
                                          But then, if you have a group of people who have contributed, and want to continue to feel involved, a meeting where you list their requests and verify that you have attended to those requests, should be sufficient. Fast, and sufficient. Maybe a bit of an explanation (at their level or dimension of understanding) as to what you did to affect their request, would be useful. Even if it is 'behind the scenes stuff', they should be interested to know that you have done it. I wouldn't think that they would think you are telling them lies, just because you don't have a demo.

                                          Regards,
                                          Roy Morien






                                          8:37 -0600
                                          Subject: Re: [scrumdevelopment] Sprint Demo Review of back-end platform work


                                          I've had this same issue. We invited all the business/compliance /senior management to our demos and for the first few demos they were bored stiff by demos that basically went "When I push this button, a bunch of stuff happens behind the scenes, and voila, a number appears over here". We've been trying to think of how to do demos on our next project so we don't drive people away with 2 hours of behind the scenes stuff. I'm afraid if we don't have people there, they'll take that as an excuse to say their input wasn't asked for.


                                          --
                                          Matt Grommes
                                          Mattorama Heavy Industries: http://mattorama. net
                                          Blind Teeth: http://blindteeth. com
                                          Idea Propulsion Lab: http://ideapropulsi onlab.org


                                          On Wed, Sep 3, 2008 at 12:13 PM, David Goodman <david.goodman@ bigfishgames. com> wrote:


                                          Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.
                                           
                                          Any feedback/advice would be appreciated.
                                           
                                          Thanks!
                                          -David

                                          .







                                          Find out: SEEK Salary Centre Are you paid what you're worth?


                                          -- 
                                          Peter Stevens, CSM
                                          Scrum Training in German: http://ausbildung.scrum-breakfast.com
                                          http://scrum-breakfast.com
                                          tel: +41 44 586 6450 
                                          
                                        • Peter Stevens
                                          Hi David I coached a team once doing exactly that - building XML API which was to be used to build a customer facing application. My team was also confronted
                                          Message 20 of 24 , Sep 5, 2008
                                            Hi David

                                            I coached a team once doing exactly that - building XML API which was to be used to build a customer facing application. My team was also confronted with the same question.

                                            We invited not just the PO but also the (non-Scrum) application development team to our demo. We used an RPC test tool to show to show how the feature worked, highlighting the user understandable fields with a mouse. The only people who could really ask questions were the application developers.

                                            Second sprint, the app team developed some hello world code to exercise the API, which they demo'd as well.

                                            Third sprint, sr manager comes to see progress as well. App team has written some real application code using the API, which they demo at "our" sprint demo ;-). Sr manager decides he likes monthly demos. (You see where this leads...)

                                            Cheers,

                                            Peter


                                            David Goodman schrieb:

                                            Hello, I wanted to get some input from the group on the best way to run a Sprint Demo Review where strictly back-end platform components were developed and there is nothing customer-facing to demo.  There are many options, such as running unit tests, going over design documents, possibly powerpoint presentations, etc, but I am not sure what works best.

                                             

                                            Any feedback/advice would be appreciated.

                                             

                                            Thanks!

                                            -David



                                             

                                            Big Fish Games, Inc. A New Game Every Day!™




                                            -- 
                                            Peter Stevens, CSM
                                            Scrum Training in German: http://ausbildung.scrum-breakfast.com
                                            http://scrum-breakfast.com
                                            tel: +41 44 586 6450 
                                            
                                          • Ron Jeffries
                                            Hello, aalanatlas. On Friday, September 5, 2008, at 4:17:10 PM, ... Yes. Such things can be demo d. I do not have the same religious zeal for the demo as a
                                            Message 21 of 24 , Sep 9, 2008
                                              Hello, aalanatlas. On Friday, September 5, 2008, at 4:17:10 PM,
                                              you wrote:

                                              >> It is my view that there is no reason ever to have any other kind of
                                              >> story. I freely grant that this sounds insane, but it isn't. :)

                                              > I wholeheartedly agree. Where we seem to differ is that I see examples
                                              > where the "top of the stack" ends at an api, which is hard to demo, so
                                              > I tried to make the point that you can make those visible and that
                                              > there is value in doing so. This discussion started out to be all
                                              > about getting away from the "press a button and nothing happens for a
                                              > while and then a dot appears on the screen" kind of demo.

                                              Yes. Such things can be demo'd. I do not have the same religious
                                              zeal for the demo as a true ScrumPerson might have, however. Someone
                                              who has ordered an API will surely have a different need for bells,
                                              whistles, and lights than a normal human might.

                                              >> If they /can/ tell, there's your demo.
                                              >
                                              > Only if you're willing to accept an utterly boring demo in some cases.
                                              > Otherwise, creativity is called for. That's my only point.

                                              I'm all for creativity. We must be on the same page.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              If you don't have the courage to say what you think,
                                              there isn't much use in thinking it, is there?
                                              --Thomas Jay Peckish II
                                            • mike.dwyer1@comcast.net
                                              Well??? How did itgo? Sent via BlackBerry by AT&T ... From: David Goodman Date: Fri, 5 Sep 2008 13:50:19 To:
                                              Message 22 of 24 , Sep 9, 2008
                                                Well??? How did itgo?

                                                Sent via BlackBerry by AT&T


                                                From: "David Goodman" <david.goodman@...>
                                                Date: Fri, 5 Sep 2008 13:50:19 -0700
                                                To: <scrumdevelopment@yahoogroups.com>
                                                Subject: RE: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                                Wish me luck, I’m executing in 10….. J

                                                 

                                                From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of aalanatlas
                                                Sent: Friday, September 05, 2008 1:32 PM
                                                To: scrumdevelopment@ yahoogroups. com
                                                Subject: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                                 

                                                --- In scrumdevelopment@ yahoogroups. com, "woynam" <woyna@...> wrote:

                                                >
                                                > --- In scrumdevelopment@ yahoogroups. com, "aalanatlas" <alanatat@>
                                                > wrote:
                                                > >
                                                > > Ron,
                                                > >
                                                > > I get why you made your comment of "Don't do that" and I understand
                                                > > how it applies to cases where features are broken up horizontally
                                                > > rather then vertically. But I don't think that's the whole story.
                                                > >
                                                > > Knowing your penchant for examples, I offer you two types of system
                                                > > from my experience that fit David's description of features that don't
                                                > > provide easily visible value. The "features" are vertical within their
                                                > > systems and deliver the value they are meant to deliver. I'd like to
                                                > > understand if you still somehow argue that they shouldn't be built in
                                                > > that way.
                                                > >
                                                > > 1. Scalability (and other non-functional requirements) - "Your system
                                                > > worked great last sprint. Now show me the same thing, but with 100,000
                                                > > simultaneous users this time." Do we not take non-functional
                                                > > requirements and turn them into Product Backlog items? It's not an
                                                > > easy thing to make this an exciting demo, but there is great value to
                                                > > the business in providing it.
                                                >
                                                > No, you don't have to take non-functional requirements and turn them
                                                > into PB items. Non-functional requires always affects a functional
                                                > requirement. If you add the functional requirement, i.e.
                                                > story/feature, to the backlog, along with the impact of the
                                                > non-functional requirement, you'll have something to demo.
                                                >
                                                > For example, "As a user, I want to enter an order and have it respond
                                                > within 2 milliseconds while the system is supporting 100,000 users."
                                                >
                                                > The tasks that address the internals of the system are associated with
                                                > the feature, so you're always addressing something that provides
                                                > business value. If no story is affected by the non-functional
                                                > requirement, then why would you do it?

                                                Yes, I'm of course familiar with that construct. But consider what
                                                happens when you only built the system for 1000 users and the
                                                unthinkable happened...you got successful beyond your wildest dreams.
                                                Now all of a sudden you need to add no new features but a lot of load
                                                handling capability. That makes it a story for me, since the team will
                                                be doing nothing else until the system can handle the new load. And I
                                                can guarantee that there will be anxious executives who really want to
                                                see a demo when you claim you're done. At least at my company.

                                                >
                                                > >
                                                > > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                                > > throttling systems, caching systems, storage systems, or messaging
                                                > > systems to name a few. The customers of these systems are often the
                                                > > builders of other systems. What these systems do tends to be quite
                                                > > invisible, in demo terms. The features of these systems are accessed
                                                > > by their users via API calls or messages. Again, tough to demo, no?
                                                > > Yet these systems have external, paying customers.
                                                > >
                                                > > I've had to try to demo things like these, and it's hard. But it
                                                > > doesn't mean that there is no value there, and I fail to see that it's
                                                > > some kind of agile party foul to build them. If it is, then I'd like
                                                > > to understand a better way to think about this.
                                                >
                                                > Don't these things affect some feature of the system? Why do we cache?
                                                > To speed things up. OK, so demo a feature with and without the cache
                                                > to show how it speeds things up. If the PO yawns, then it must have
                                                > not been a high-priority item to begin with.

                                                Yes I get that too. Now put yourself into the position of being a
                                                separate company that just builds caches. you need to release a fully
                                                production-ready cache to your customers. They will pay to use it and
                                                be happy. They are your customers. Before they see your product, you
                                                will complete a sprint and need to demo the cache to your own company
                                                (and maybe some potential customers also). So what do you do? You find
                                                ways to build a non-boring demo of the cache. That's all this
                                                discussion is about, right? The original question was about building
                                                compelling demos of back-end functionality that often does not demo in
                                                an exciting way.

                                                >
                                                > The other important aspect about always (trying to) tying things to
                                                > features is that it demonstrates that the software is always ready for
                                                > prime time. If you build specific components to address non-functional
                                                > requirements, but you don't integrate and test them in the real
                                                > software, then you really don't know if it's going to have the desired
                                                > affect.
                                                >
                                                > I've seen plenty of cases where folks spent a great deal of time
                                                > building the next greatest thing, and when they finally plugged it
                                                > into the actual application, it didn't have the desired affect. In
                                                > many cases it was because there were other bottlenecks that were
                                                > bigger, or hidden.
                                                >
                                                > >
                                                > > Thanks.
                                                > >
                                                > > alan
                                                > >
                                                > > --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries
                                                > > <ronjeffries@> wrote:
                                                > > >
                                                > > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM, you
                                                > > > wrote:
                                                > > >
                                                > > > > Hello, I wanted to get some input from the group on the best way
                                                > > to run
                                                > > > > a Sprint Demo Review where strictly back-end platform components
                                                > were
                                                > > > > developed and there is nothing customer-facing to demo. There are
                                                > > many
                                                > > > > options, such as running unit tests, going over design documents,
                                                > > > > possibly powerpoint presentations, etc, but I am not sure what
                                                works
                                                > > > > best.
                                                > > >
                                                > > > Well, hmm. I fear that the right answer may be "Don't do that".
                                                > > >
                                                > > > Did the Product Owner specify acceptance tests?
                                                > > >
                                                > > > Did the Product Owner actually /ask/ for this? Or did the developers
                                                > > > plan this Sprint? If the latter, the P.O. should refuse to pay. :)
                                                > > >
                                                > > > Really. I know you don't like this answer, but what works best is
                                                > > > "Don't do that". Second best is far behind. I guess I'd tell 'em
                                                > > > what was done and run the unit tests. But really ... if we don't do
                                                > > > something with business value, why should we get paid?
                                                > > >
                                                > > > Ron Jeffries
                                                > > > www.XProgramming. com
                                                > > > Anyone can make the simple complicated.
                                                > > > Creativity is making the complicated simple. -- Charles Mingus
                                                > > >
                                                > >
                                                >



                                                 

                                                Big Fish Games, Inc. A New Game Every Day!™


                                              • David Goodman
                                                Thank you all for your input. The “demo” went extremely well, however the audience was primarily the engineering team and the product owner. Stakeholders
                                                Message 23 of 24 , Sep 9, 2008

                                                  Thank you all for your input.  The “demo” went extremely well, however the audience was primarily the engineering team and the product owner.  Stakeholders were not present for this demo which actually helped keep the review on-track.  Each developer gave in-depth details on the functionality they implemented and provided examples with their unit tests. 

                                                   

                                                  Overall I would call this review a success because it enabled the whole team to discuss the architecture on a much deeper level and provided confidence in each other that their teamwork was well executed.

                                                   

                                                  Thanks again for all of your viewpoints, it really helped!

                                                  -David

                                                   

                                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mike.dwyer1@...
                                                  Sent: Tuesday, September 09, 2008 8:47 AM
                                                  To: Scrumdevelopment
                                                  Subject: Re: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                                   

                                                  Well??? How did itgo?

                                                  Sent via BlackBerry by AT&T


                                                  From: "David Goodman" <david.goodman@...>
                                                  Date: Fri, 5 Sep 2008 13:50:19 -0700
                                                  To: <scrumdevelopment@yahoogroups.com>
                                                  Subject: RE: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                                  Wish me luck, I’m executing in 10….. J

                                                   

                                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of aalanatlas
                                                  Sent: Friday, September 05, 2008 1:32 PM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work

                                                   

                                                  --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:

                                                  >
                                                  > --- In scrumdevelopment@yahoogroups.com,
                                                  "aalanatlas" <alanatat@>
                                                  > wrote:
                                                  > >
                                                  > > Ron,
                                                  > >
                                                  > > I get why you made your comment of "Don't do that" and I
                                                  understand
                                                  > > how it applies to cases where features are broken up horizontally
                                                  > > rather then vertically. But I don't think that's the whole story.
                                                  > >
                                                  > > Knowing your penchant for examples, I offer you two types of system
                                                  > > from my experience that fit David's description of features that
                                                  don't
                                                  > > provide easily visible value. The "features" are vertical
                                                  within their
                                                  > > systems and deliver the value they are meant to deliver. I'd like to
                                                  > > understand if you still somehow argue that they shouldn't be built in
                                                  > > that way.
                                                  > >
                                                  > > 1. Scalability (and other non-functional requirements)- "Your
                                                  system
                                                  > > worked great last sprint. Now show me the same thing, but with
                                                  100,000
                                                  > > simultaneous users this time." Do we not take non-functional
                                                  > > requirements and turn them into Product Backlog items? It's not an
                                                  > > easy thing to make this an exciting demo, but there is great value to
                                                  > > the business in providing it.
                                                  >
                                                  > No, you don't have to take non-functional requirements and turn them
                                                  > into PB items. Non-functional requires always affects a functional
                                                  > requirement. If you add the functional requirement, i.e.
                                                  > story/feature, to the backlog, along with the impact of the
                                                  > non-functional requirement, you'll have something to demo.
                                                  >
                                                  > For example, "As a user, I want to enter an order and have it respond
                                                  > within 2 milliseconds while the system is supporting 100,000 users."
                                                  >
                                                  > The tasks that address the internals of the system are associated with
                                                  > the feature, so you're always addressing something that provides
                                                  > business value. If no story is affected by the non-functional
                                                  > requirement, then why would you do it?

                                                  Yes, I'm of course familiar with that construct. But consider what
                                                  happens when you only built the system for 1000 users and the
                                                  unthinkable happened...you got successful beyond your wildest dreams.
                                                  Now all of a sudden you need to add no new features but a lot of load
                                                  handling capability. That makes it a story for me, since the team will
                                                  be doing nothing else until the system can handle the new load. And I
                                                  can guarantee that there will be anxious executives who really want to
                                                  see a demo when you claim you're done. At least at my company.

                                                  >
                                                  > >
                                                  > > 2. Common (i.e., meant to be shared) back-end capabilities such as
                                                  > > throttling systems, caching systems, storage systems, or messaging
                                                  > > systems to name a few. The customers of these systems are often the
                                                  > > builders of other systems. What these systems do tends to be quite
                                                  > > invisible, in demo terms. The features of these systems are accessed
                                                  > > by their users via API calls or messages. Again, tough to demo, no?
                                                  > > Yet these systems have external, paying customers.
                                                  > >
                                                  > > I've had to try to demo things like these, and it's hard. But it
                                                  > > doesn't mean that there is no value there, and I fail to see that
                                                  it's
                                                  > > some kind of agile party foul to build them. If it is, then I'd like
                                                  > > to understand a better way to think about this.
                                                  >
                                                  > Don't these things affect some feature of the system? Why do we cache?
                                                  > To speed things up. OK, so demo a feature with and without the cache
                                                  > to show how it speeds things up. If the PO yawns, then it must have
                                                  > not been a high-priority item to begin with.

                                                  Yes I get that too. Now put yourself into the position of being a
                                                  separate company that just builds caches. you need to release a fully
                                                  production-ready cache to your customers. They will pay to use it and
                                                  be happy. They are your customers. Before they see your product, you
                                                  will complete a sprint and need to demo the cache to your own company
                                                  (and maybe some potential customers also). So what do you do? You find
                                                  ways to build a non-boring demo of the cache. That's all this
                                                  discussion is about, right? The original question was about building
                                                  compelling demos of back-end functionality that often does not demo in
                                                  an exciting way.

                                                  >
                                                  > The other important aspect about always (trying to) tying things to
                                                  > features is that it demonstrates that the software is always ready for
                                                  > prime time. If you build specific components to address non-functional
                                                  > requirements, but you don't integrate and test them in the real
                                                  > software, then you really don't know if it's going to have the desired
                                                  > affect.
                                                  >
                                                  > I've seen plenty of cases where folks spent a great deal of time
                                                  > building the next greatest thing, and when they finally plugged it
                                                  > into the actual application, it didn't have the desired affect. In
                                                  > many cases it was because there were other bottlenecks that were
                                                  > bigger, or hidden.
                                                  >
                                                  > >
                                                  > > Thanks.
                                                  > >
                                                  > > alan
                                                  > >
                                                  > > --- In scrumdevelopment@yahoogroups.com,
                                                  Ron Jeffries
                                                  > > <ronjeffries@> wrote:
                                                  > > >
                                                  > > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM,
                                                  you
                                                  > > > wrote:
                                                  > > >
                                                  > > > > Hello, I wanted to get some input from the group on the
                                                  best way
                                                  > > to run
                                                  > > > > a Sprint Demo Review where strictly back-end platform
                                                  components
                                                  > were
                                                  > > > > developed and there is nothing customer-facing to demo.
                                                  There are
                                                  > > many
                                                  > > > > options, such as running unit tests, going over design
                                                  documents,
                                                  > > > > possibly powerpoint presentations, etc, but I am not sure
                                                  what
                                                  works
                                                  > > > > best.
                                                  > > >
                                                  > > > Well, hmm. I fear that the right answer may be "Don't do
                                                  that".
                                                  > > >
                                                  > > > Did the Product Owner specify acceptance tests?
                                                  > > >
                                                  > > > Did the Product Owner actually /ask/ for this? Or did the
                                                  developers
                                                  > > > plan this Sprint? If the latter, the P.O. should refuse to pay.
                                                  :)
                                                  > > >
                                                  > > > Really. I know you don't like this answer, but what works best
                                                  is
                                                  > > > "Don't do that". Second best is far behind. I guess
                                                  I'd tell 'em
                                                  > > > what was done and run the unit tests. But really ... if we don't
                                                  do
                                                  > > > something with business value, why should we get paid?
                                                  > > >
                                                  > > > Ron Jeffries
                                                  > > > www.XProgramming.com
                                                  > > > Anyone can make the simple complicated.
                                                  > > > Creativity is making the complicated simple. -- Charles Mingus
                                                  > > >
                                                  > >
                                                  >

                                                   

                                                   

                                                  Big Fish Games, Inc. A New Game Every Day!™

                                                   

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