Being a part of a multinational company composed of many entities around the world brings itself a great privilege but also a huge responsibility and challenge at the same time. It requires that the project teams of experts from Serbia, Netherlands, Belgium, Turkey and other countries are usually combined.
This kind of collaboration has lots of benefits, but also downsides when it comes to the multi-geographically point. Due to impossibilities to have a team in one place, entire communication demands to be virtual. When it comes to presenting implemented features to the client, everything happens through various communication tools (Zoom, Slack, Teams, etc.) which sometimes can be very tricky, especially when it is about demonstrating complex business logic.
Explaining “technical users stories” where most things happen “under the hood”, might be quite challenging in terms of keeping the client impressed and interested in carefully listening to your presentation without any misconception.
The lecture “Let’s demo” has the main goal to remind us why a good presentation is so important and how to make it more effective with a few tips and tricks.
I would like to point out that this handbook is focused on running sprint reviews (scrum methodology) that is, demonstrating functionalities, without analysing the skills of giving lectures in front of a large audience, body language, etc.
1) Why is a good presentation important?
You will never get a second chance to make a first impression. – Will Rogers
Sprint review or popularly called “demo”, represents a meeting where a broader circle of stakeholders are introduced with the features that the team has developed in the current sprint (iteration).
By presenting a certain functionality to the audience, they subconsciously create the first impression about its quality and purpose (does a developed functionality meet the requirements). With a good presentation, we not only obtain credibility but also we are increasing the trust between clients and minimizing the chances to be misunderstood or misinterpreted.
The clarity is essential in nourishing business relationships with a client, so that’s why a good presentation is so important.
2) Business context!
Keep in mind that every functionality which we implement needs to have a business aspect. Therefore, while making a demo, try to emphasize the business context of that newly developed feature.
In order to achieve this, our presentation can begin with the answer to two very simple questions: purpose and motivation?
Purpose should explain what this feature does, that is, what goal we want to achieve with it, while motivation should explain why we did that, that is what motivated us to do that.
At first sight, this seems pretty similar and we need to do some mental gymnastics to be able to make a distinction between these two things. However, if we look at one simple example, it is really easy to understand the difference.
“We built a validation engine on integration layer for catalogs importer…
so we can easily detect invalid data from ERP systems and protect our business flow from irregularity caused by those data.”
Here’s another example:
“We refactored microservice for processing gift cards to be more generic…
so we can easily support different gift card integrations and increase code coverage while spending less time on development. This approach will reduce maintenance time and our system will become more stable.”
If we start presenting our “user story” in this way, we are more likely to draw listeners’ attention and make them more interested in the topic.
3) Know your audience!
It is crucial that we know the audience to which we are holding the presentation. This will help us in defining how far we can go with explaining the technical details. This especially refers when it comes to presenting “technical user stories” where we made some refactoring of the code etc.
In case our stakeholders are, for instance, system architects, or engineers with extensive technical knowledge, it is perfectly acceptable to go with class or a sequence diagram. If that is not the case, try to focus more on business benefits that your refactoring brings. For example: “With this refactoring we speeded up the functioning of microservice by X percentage, etc.”
4) Learn happy flow and do not improvise
Not rarely I had a chance to attend a sprint review where a presenter started clicking on a new feature randomly and practically improvised. This kind of approach usually ended badly because it usually led to bugs or cases that nobody expected along the way.
Sprint demo is not the place to test the product! Therefore, my strong advice is to learn the steps you want to demonstrate beforehand and repeat them a few times before the presentation. Otherwise, you are more likely to put yourself in an awkward position in front of the audience.
5) 1-6-6 rule
While making slides, make sure you respect the golden 1-6-6 rule.
This rule tells us the following:
– 1 topic on the slide
– 6 bullets maximum
– 6 words maximum per bullet point
In this way our slides can be easily viewed without refocusing the audience’s attention from the speaker. However, if we don’t stick to this, we can easily end up showing slides full of text causing the audience to stop listening to the speaker and focus on reading that huge text.
If your slide has too much text, somebody or something is superfluous. You or the slide.
6) Visualisation: A picture is worth a thousand words
In order to keep our audience’s attention, we mustn’t neglect the aspect of visualisation. Make sure to enrich your slide with some graphics or even a video.
For example, in case you are talking about a new automatic test, it’s completely fine to play the video of how it is performed. In this way you will skip the preparation phase to run the test, and you will eliminate the risk of things going awry. On the other hand, the audience will be able to understand the thing you have automated and see how it really works. If you mention that you have covered a certain number of unit tests, make sure you also include a pie chart that shows the percentage.
In this way you will make your audience memorise the things they have heard during your presentation.
7) The best way to present mobile responsiveness in your presentation
When you want to present responsiveness of the web application on a phone screen, keep in mind to turn on a mobile frame. This will help your stakeholders get a real look and feel how the application will behave on a smaller frame. Google Chrome has an excellent option that enables you to turn this feature on in just a few clicks.
8) Turn on caching
Usually, during the development process, we intentionally turn off the browser caching mechanism so we can continuously fetch the latest changes in our codebase from the server. This results in decreasing the performance of the web application. When we present the product, it is important that we simulate how it will work for the end-user and this is why you shouldn’t neglect the speed of application response. Therefore, make sure you turn on the default option of caching during the presentation.
9) Remove development console
In case there are errors in the development console, make sure that you handle all of the error and warning messages. If, for some reason, this is not possible, try not to present it during the demonstration of the product. Presenters sometimes forget to hide the development console which directly influences the audience’s opinion about the product’s quality.
10) Put your messaging tools on mute or busy mode
We can agree that it is quite inappropriate when messages start popping out during the presentation, where we share the screen with the audience. This can distract us from the lecture and even embarrass in front of the viewers.
11) Dress code
Professional dress code is mandatory. Always keep in mind that you represent your team and the company.
12) Good preparation takes time
I often had a chance to see that very experienced engineer having difficulty presenting the functionality that they had developed.
As a sprint (iteration) comes to the end, we often fail to set aside enough time to think about a concept of how we are gonna present the feature during the demo session. This increases the chance for mistakes and sometimes leads to miscommunication in terms of forgetting to emphasize important parts of the software.
Feeling anxious and uncomfortable before the presentation is something all of us struggle with. It takes time to overcome the fear of public speaking. As an advice, try to go several times through the presentation and practice it as much as you need until you start feeling more self-confident.
Repetitio est mater studiorum
Knowledge sharing sessions as Emakina.RS’ trademark
Besides the fact that our colleagues learn many new things when they visit conferences in a country and abroad, we try hard to make the process of learning continuous and to discuss various topics regularly.
One of the ways to exchange knowledge within our company are knowledge-sharing sessions. Eventually, as our team expanded, we started to realise the potential this type of meetings could have and we quickly started implementing them.
We discussed various topics. We didn’t cover only technical topics. We also covered the ones that are related to organisation. Here you will find a few useful topics:
Every second Wednesday, we organise one voluntary lecture where each of our colleagues can apply to be a speaker. We have had more than 30 knowledge sessions and each time the attendance was surprisingly large. This is also a chance for every colleague to break the ice and try to be a speaker in front of a large audience.
It’s a privilege when someone explains the essence of a certain topic, gives guidelines and encourages you to further think about the topic and do research. The goal of this kind of meeting is to expand the horizons, which is, in essence, our mantra – #ContinuousGrowth.