Agile projects are built on trust, and the best way to establish trust is through transparency.
Regular demos for users are one of the best ways for teams to be transparent about what
progress has been made.
Development should not be a black box from the user’s perspective.
The end users should be able to watch the software developing and provide feedback as
it takes shape.
Regular demos can help accomplish this.
Most users who have experienced a few software development projects are very familiar with
projects that are scheduled to take 12 months that spend the first 10 months getting to
90% completion--and another 12 months finishing the remaining 10%.
Demos help solve this problem in several different ways.
First, demos help focus the development work on pieces of functionality that are actually
usable.
This may mean building some parts of the application in a simpler way, just so other parts can
be demoed.
This might seem trivial, but a focus on getting the application to a point where a feature
is actually usable makes a huge difference in avoiding the false progress many projects
see at the beginning that is followed by a dramatic slowdown at the end.
Second, the focus on creating functionality that can be demonstrated means that if the
business owners are not happy with the timeline for when software is going to be ready to
use, they can cut scope to finish sooner.
If a team has not been focusing on software that can be demonstrated, the code that has
been written is going to be much further from being in a usable state.
Even if all the remaining scope is cut, there is still going to be a massive amount of work
to get the “completed” features usable.
Third, demos help reduce the amount of rework that occurs.
The simple fact is that no matter how hard users and developers try to communicate, there
will be times where things will not be clear until they sit down and use the software.
The sooner this happens, the less code will be built on incorrect assumptions.
I was working with a team that was building some software for the Treasury that was doing
demos every two weeks.
At one of the demos, the team walked through how to use the application for a particular
function.
The business owner questioned whether it was following the business rules correctly.
Several of the users said it was correct, but after some more discussion, it became
apparent that there were nuances to the business rules that even the users did not fully understand.
Had it not been for the demo, this would not have been discovered until much later on and
much more of the application would have been built on top of the faulty understanding.
T> It is ideal to have an actual user or a business owner controlling the software in
a demo.
What if they do something that wasn't expected and it breaks?
That is exactly why they **should** be doing it instead of a developer.
Demos need to demonstrate real working software.
Walking through a series of screen mockups may be useful, but it does not count as a
demonstration of working software.
Demos should prioritize transparency over polish.
If you have to manually load something into a database table to illustrate part of the
user interface, do not hide that part from your demo.
Everyone needs to know what has been built and what has not.
##Demo Frequency
How often should you do software demos?
It depends, but most projects have some sort of cadence that creates a natural place to
demonstrate the functionality that has been built.
If you are using sprints, it probably makes sense to do a demo at the end of each sprint.
If you are not using sprints, you may need to pick something of an arbitrary length of
time.
For most projects, two weeks is usually a reasonable interval.
For some projects, one week will work better.
Some projects even work well with a demo every morning—especially if the developers are
working from the other side of the world and demonstrate what they have completed at the
end of their workday to stakeholders who are just starting theirs.
If demos are too frequent, it may be difficult to get high-level stakeholders to attend every
one.
On the other hand, with less frequent demos, if someone misses a single meeting they will
not be able to participate in another demo for quite some time.
Usually, longer periods between demos is more risky than the risk of some people occasionally
not attending.
Keep in mind, demos are establishing trust through transparency.
For some high-level stakeholders, the knowledge that you are doing a demo that they *could*
attend may provide a level of trust even if they are not able to actually be there.
There is a tendency to schedule demos around how much work is ready to demonstrate.
While no one wants to have a meeting to demonstrate software and not have anything to show, it
is important to carefully distinguish between a problem with demos being too frequent and
a problem with not building in small enough slices of work.
We explore this in more depth in the chapters on Better Stories and Deliver Small Changes.
Not having anything to demonstrate is likely a symptom of the real problem.
If a team does not have anything to demonstrate every two weeks, you should first try to redefine
the work into smaller pieces so you will have new functionality in a state that you can
demonstrate.
Do not forget you are striving for transparency over polish.
If you need to demonstrate how the application lets you fill out a form but do not have the
page that displays the data, show that the data gets saved into the database.
It shows what work has actually been accomplished and maintains the transparency that is vital
for high-trust teamwork to occur.
##How To Run A Demo
If the idea of a “software demo” makes your organization think of a slick presentation
with one person standing on a stage in front of a huge screen walking through a new piece
of software, then call the demos something else.
Your demos are not to put on a show or make the software look better or more complete
than it is.
The goal is to honestly communicate what features are complete and how they work.
If possible, you want the person driving the computer to be the person who will use the
feature being demoed.
This helps make sure that the demo shows what a real user is going to do.
It also helps make sure that the demo does not look like a staged walkthrough of a mock-up.
---------------------
So what is your experience doing software demos?
If you have any tips or tricks, please share them in the comments.
And if you have any horror stories of software demos gone horribly wrong please share those
as well.
If you like the videos, please take a moment to subscribe or give the videos a thumbs up
so more people will see it.
If you'd like more information about how to practice Agile in your organization, there
is a link in the description to a mailing list you can sign up for.
I occasionally send out information about resources I've produced or found for teams
that are really wanting to develop their agility.
Thanks for taking the time to watch this video.