Regular Demos – Creating Agile Software

Regular Demos – Creating Agile Software


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.

4 thoughts to “Regular Demos – Creating Agile Software”

Leave a Reply

Your email address will not be published. Required fields are marked *