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

Re: nothing to demo at end of sprint?

Expand Messages
  • Deb
    ... For teams where Scrum is their first step in the Agile direction, there may be no way to do this yet. Which is fine - but the team then needs to be
    Message 1 of 7 , Feb 18, 2005
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Paul Hodgetts
      <phodgetts@a...> wrote:
      > Schoof wrote:
      > > At today's stand-up meeting, I reminded the team that the
      > > end-of-sprint review will be on Monday, to confirm that no
      > > one had unexpected schedule conflicts, etc. About half the
      > > team said they had "nothing to demo" and implied that an
      > > end-of-sprint demo would be pointless. This raises some
      > > questions in my head:
      > >
      > > 1. What might they have to demo that they are overlooking?
      > > How do you demo a bunch of bug fixes?
      > I prefer that the team always has live software around for
      > the review. This forces us to make sure we integrate,
      > build and deploy.

      For teams where Scrum is their first step in the Agile direction,
      there may be no way to do this yet. Which is fine - but the team then
      needs to be creative to display, to their best abiity, what they have
      accomplished. As a last resort, show before/after images (for example,
      of a reporting or UI display problem), or data. For users new to
      Agile, this is already VERY impressive and starts changing their
      perception of your department, simply through the mechanism of
      transparency. Then, when you can finally show them live stuff, they'll
      be even more impressed.

      The show is important psychologically, for the team too - to reinforce
      the fact that the work is FOR THE CLIENT (this bug us costing us
      money/time/customers), not for the satisfaction of the team (there! I
      killed another bug!). I believe that the motivation of working for the
      client is the more powerful of the two.

      > > 2. If they really have "nothing to demo" what is wrong
      > > with our implementation of scrum?
      > It's really hard to evaluate your project situation with
      > just a few comments on a mailing list. But...
      > Normally, you want to include some new features/enhancements
      > that have business value in each sprint. You would complete
      > and show those as a demonstration of the product's progress.

      I agree. If the customer wasn't involved in selecting which bugs to
      fix, then perhaps you really have "nothing to demo", which should warn
      you that you skipped a step :-) But if the customer asked for these
      fixes, you owe them the respect of being accountable by showing them
      proof of your work. When we started doing this, the response was
      astonishment... "this is great! we often don't see, for 6 months, the
      result of what we asked for!" This encouraged them to ask more
      actively for high-value features, because they started to trust our
      department again, that we would deliver what they need, and not
      invisible stuff of doubtful value.

      > If the bug fixes are the highest value to the business, then
      > that's what you work on. If you have nothing but bug fixes,
      > it means you have a lot of quality debt, but it needs to be
      > paid down so you show a lot of bug fixes.
      Yes, this can build confidence - they learn that you are aware of your
      quality debt (because they surely are!) and that you care to improve
      their software. But they must approve this work, every time. One way
      or another, it's their money, in most cases.

      > > 3. How do I turn this into a learning experience?
      > I think if the team has to meet with the stakeholders and
      > can't show them any results from their sprint, *that* is a
      > powerful learning experience on what their purpose is in
      > the business -- to deliver value to the stakeholders.
      > It seems the thought of this concerns the team enough to
      > want to cancel the review. Don't do that. If they really
      > had a bug fix sprint, then challenge them to find a way to
      > show the bug fixes, even if they just walk through the list
      > and it only takes 15 minutes.

      Customers sometimes like this... if they'e been involved during
      development, 15 minutes may be all you need. And goodness knows, they
      don't need another meeting, and will appreciate that you respect their

      This shift to REAL meetings that do real work, not just blowing hot
      air, is another Agile shift that is very welcome by customers. Make
      sure that the people involved are all stakeholders - so no one is
      wasting their time being there. If needed, split into two demos for
      two customer groups whose features don't overlap. (Ex: if you do
      features for Finance and Call Centre in one sprint) to ensure that
      participants are all engaged and customer time is wasted.

      > Make sure you do the second practice you are supposed to do
      > on your last sprint day. Hold your retrospective. Make
      > sure the team discusses what they worked on during the sprint,
      > and what they didn't complete (if that's the case). Ask the
      > product owner if the sprint delivered business value.
      > > Can anyone suggest answers to these questions? Are there
      > > other questions I should also be seeking answers for?
      > Yes, how was it that you got two working days from the end
      > of the sprint before the issue of nothing to review came up?
      > What kind of tracking were you doing?

      My last team started identifying "what needs to be demo'd" at the
      beginning of the sprint, to reinforce the demo practice from the
      beginning. It was just a natural evolution of our process. The few
      things "not demo'd" were provided as a list (things difficult to demo
      given our environment, or small items that were done collaboratively
      with the stakeholder during the sprint, so they have seen it).

      The fact that you are asking these questions is a good sign - you
      clearly have an appreciation for inspect-and-adapt. Keep up the good work!


      > Regards,
      > Paul
      > -----
      > Paul Hodgetts
    Your message has been successfully submitted and would be delivered to recipients shortly.