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

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

Expand Messages
  • 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 1 of 24 , Sep 9, 2008
    • 0 Attachment

      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!



      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
      > > 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
      > > 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
      > > worked great last sprint. Now show me the same thing, but with
      > > 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
      > > 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,
      > > > 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
      > were
      > > > > developed and there is nothing customer-facing to demo.
      There are
      > > many
      > > > > options, such as running unit tests, going over design
      > > > > possibly powerpoint presentations, etc, but I am not sure
      > > > > best.
      > > >
      > > > Well, hmm. I fear that the right answer may be "Don't do
      > > >
      > > > Did the Product Owner specify acceptance tests?
      > > >
      > > > Did the Product Owner actually /ask/ for this? Or did the
      > > > 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
      > > > "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
      > > > 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.