You’ve completed the sprint – the goal was hit and you’re ready to demo your new changes! But it’s only you and the product owner who have turned up to the session – the other stakeholders “couldn’t make it”. You continue with your slides showing code samples and architecture diagrams to show how your cool new integration piece pushes data from this component to another.
It can be difficult for non-technical people to engage with demos when the work you’re demonstrating is highly technical, especially when the format is slide-based and full of code that they can’t read, never mind understand! In this post I share some examples of how teams have made their demo’s more engaging when the content is highly technical.
Architecture diagrams can be hard for non-technical people to follow – so you could try simplifying by using emojis! I saw this done really well to explain how much of an integration piece had been completed and how much was left to go. Let’s take a simple example of a new app that’s being built where users can search for pictures of their favourite cats. You’ve built a database of cats already and this sprint you’ve made a search API but not yet managed to make that work in the app. The below image could be used to give context for those who can’t follow an API call demonstration fully.
Sometimes there is no front-end but you do lots of hard work to make a series of calls between services. Take authX for example, there can be lots of passing of ‘tokens’, ‘certificates’, and ‘secrets’ from ‘trusted parties’ which might not make sense to less technical audience members. Having people role play each of the services or parties involved and giving them physical objects that represents the coded objects in the exchange can help bring to life what’s going on behind your code.
Use the impact to users
Sometimes time is spent just making updates to stop dependencies falling out of service windows, to fix vulnerabilities or to clear up some bugs. These can all be dreadfully boring to talk about but there is still value in this work. If you can tie it back to the user for the audience then it gives them a better idea of what’s going on. For example, with a bug, show the behaviour before and the behaviour after so people can see the improvement in user experience. If it’s vulnerability patches, share how a malicious actor might have been able to exploit the system (in simple terms, perhaps by using emojis!) and explain how that’s now fixed. If it’s tech debt, explain what efficiencies have been made and what impact this has on the user too – is their experience faster, or does clearing this item up mean they are less likely to run into a certain undesired behaviour?
When something is technically complex, it can be daunting for non-technical audience members to approach. By simplifying terms and putting them in context of our users, we can help make these topics more approachable and more relevant for the audience.
How do you like to show off more technical work to non-technical audiences?
*Image from ingeniousdesign.co.uk