Re: nothing to demo at end of sprint?
- --- In firstname.lastname@example.org, Paul Hodgetts
> Schoof wrote:For teams where Scrum is their first step in the Agile direction,
> > 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.
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 wrongI agree. If the customer wasn't involved in selecting which bugs to
> > 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.
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.
>Yes, this can build confidence - they learn that you are aware of your
> 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.
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?Customers sometimes like this... if they'e been involved during
> 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.
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.
>My last team started identifying "what needs to be demo'd" at the
> 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?
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!
> Paul Hodgetts