Strategy for a Valuable Sprint Demo
Are you Really Finishing a Sprint Successfully?
Looking back over a decade of leading agile software
development teams, there seems to be a trend with teams that are not mature in
agile with completely ignoring the needs for the end of sprint ceremonies. When you think of Demos and Retrospectives at
the end of the sprint, so many times the team waves them off to quickly dive
into the backlog to start planning out the next sprint. High fives all around to the team for completing
the sprint – but did they? Let’s take a
quick look at the growth and value that is being missed by ignoring demos and
retrospectives. In addition, I want to
share some best practices on Demos in this blog post that you can use to make immediate
value to the scrum team. A follow-on
post Part 2 post will be for Retrospectives.
Two Common Practices around Sprint Demos that I have seen
that you need to be aware of is:
- It’s only infrastructure or bugs
- PowerPoint or magic hand waving demos
It’s Just Internal Engineering
When thinking about a sprint, hopefully potentially
shippable product increments come to mind.
The first trigger of a scrum team not producing potentially shippable
increments is not performing a demo. I’ve
heard excuses that they only worked on product infrastructure and items
customers would not ‘directly’ use or it was only bugs in this release.
The real world gotchas in this scenario is that the team has
either not fully completed the functionality, feels like these should not be
demonstrated from a value perspective, or does not see the link between code
developed to customer value. Even if it
is a quick demo to showcase how an internal pipeline handles double the volume
of data from an algorithmic change, that is important to show. Although the customer would not see the
change per say, they would be affected by impact for the user story
completion. Using mock services to show
some of these changes has also been a common occurrence so that we make sure
when we say we are Done; the story really is Done and can be deployed.
Furthermore, the mature and in tune to the customer teams would
be able to link even engineering stories to how it would affect the customer
experience. Either way, consistently
showing the team’s progress across a prioritized backlog that delivers value to
customers should be the theme for every sprint.
Do not let this reason allow the team to sweep a Demo under the rug and
not complete the ceremony. This may be
controversial in some engineering circles, but by having this demo even for
infrastructure/bug sprints, it keeps the team to a higher standard of value
delivery.
Key Tip: Record Your Demo
Live demos are for the scrum team itself and to showcase to
the product owner the value created.
However, over the years, I’ve seen other scrum teams wanting to see what
other teams have produced or even executives that want to pop in to view
without adding the stress to the teams. In
our global world, there is a high possibility scrum teams although co-located,
might be spread across the world in China for one scrum team, Bangalore for
another, and Durham for a third. I have seen
interest from one scrum team to another on what they accomplished/how they
accomplished certain functionality but could not attend to listen due to time
zone. This is where a central repo of
recorded scum demos comes into play. There
is no downside to recording and making available for others to listen in their
leisure and I have seen more cohesive engineering organizations come together
when they see the products being developed across the world.
In my case, I like to pop in to see the team’s progress,
make sure the features are aligning to the product strategy, and to make sure working
code is being developed. I cannot tell
you how many times I have seen team’s start presenting PowerPoint instead of
working code. This is not what
executives or managers want to see during these demos nor is it what I want
engineering to spend their time on. Working
Code is KEY!
Working Code Not PowerPoint Magic
I’ve been to enough demos where engineers think they need to
show a PowerPoint and start talking about what things ‘should’ do or they just
bring up JIRA to say they worked on JIRA-12345 and it is marked Done. This is NOT what an effective software organization
should be including in their demo. If
they do, it should be no more than 15-30 seconds of time and they are focusing
on showing working code. Show us what
was accomplished, that the code works, and it is potentially shippable. Using PowerPoint’s as a magic wave of the
hands to distract from working code is not effective. If it did not fully complete, that is ok,
there is typically reasons for why it did not complete vs the team just didn’t
do the work. In my eyes, let the code do
the talking.
Wrapping it Up
Having a team demo is so critical to the health and
viability of the software product. Working
code is King if I have not said that enough and the team should be constantly
understanding the customer value it is creating. If missing that customer link or demos are
not producing value, it quickly could be impacting the success of the product.
What other tips has the community found that helps continue
the Demo ceremony and make sure it is focusing on value delivered?
I would love to hear from the community in comments!!
0 Comments