You are not alone

Welcome to our blog where we give you practical advice on facilitating change.

Contact us

Getting into the demo rhythm

How do you facilitate demos when you are in an Infrastructure department who doesn’t produce ‘shippable products’ every sprint but are configuring, optimizing, updating, and fixing issues on systems?

In this blog post, agile coach Rasmus Lund-Jensen is providing insights on how he helped start up and maintain a demo environment that continues to be a safe space for constructive feedback, helps people become even greater at what they do, and provides transparency for everyone about what is going on.

  • If you don’t have a natural customer to demo to, consider demoing to your colleagues.
  • Actively help the engineers to find the ‘red thread’ in their stories.
  • Make the demo session a safe space that is clearly stated as a ‘non-performing session’.
  • Be watchful of the tone in the demos. Everyone has positive intentions but sometimes questions and comments can come out in a way that is not perceived as constructive.
  • Keeping demo sessions online – even though you are able to meet up in person – can be a good thing.

Want training, consulting or inspirational talks on this subject?

Rasmus Lund-Jensen was the initiator of the demo sessions in the IT Infrastructure department we worked in back in 2019 when we had our first trial runs. He has run the demo sessions as a facilitator slash TV host ever since. Recently, we spent a Friday afternoon talking about the why’s, what’s and how’s of our demo journey, and we decided to share some behind the scenes reflections. We hope this can be of inspiration to you if you are also struggling with the concept of demos.

What we did


The demo sessions last for up to 2 hours with up to 8 demos and are held every 14 days. The agenda is sent out in advance of the event (see example below) so that everyone can plan whether to participate for the entire session or opt in and out. All demos are timeboxed strictly to facilitate that people can opt in and out depending on their interest: 10 min for each demo and 5 min for Q&A. Demos are also recorded and made available on the intranet for people to watch asynchronously.


Everything is online. This introduces more communication channels, as participants can have a parallel dialogue in the chat, posing and answering questions, and providing (positive) indications to support and praise their colleagues and their ideas. The online medium also takes away some of the intimidating feeling of “being on a stage” and the size of the crowd (50 or 500) is less important. The event is facilitated by Rasmus, the agile coach, who keeps time, mediates questions and ensures that sessions are recorded.


In the beginning, the invitation was sent to all of the Infrastructure department (120 people), but as we have matured we have invited other stakeholders from IT and the business, and in February this year we expanded the session to include all of IT (800), with around 300 participating at each session. We invite our external partners as well. We believe that people are adults and will make sure that their time is spent in the best way possible and are the best to judge for themselves on whether it is meaningful for them to attend.

Why we started

We begin at the beginning and I ask Rasmus why we started the demo sessions. He recalls that the intentions were innocent: it was all about showing what were doing.

“If you work with Scrum and iteratively as we do, you should showcase what you do in a structured way – potentially you should show your shippable products. And that was our starting point: to show what we had done for the last 14 days. Because up until then, showcasing was simply not something we did.

We had done it somewhat in the past, as a part of the projects we were contributing to. In the projects we showcased to the Steering Committee and to selected users and customers, but we were now transforming towards becoming product-oriented and projects were a thing of the past.

Now the entire department of 100-120 people showcased a product (or deliverable) maybe every 3 months. Our new ambition was to showcase up to 8 things every 14 days. That was a huge step.”

In short, the demo initiative was initially a way to reboot how we presented our products to the world.

“It was all about bottom-up sharing and showing the craftsmanship of the organization.”

But the desire to start doing demos and showcase what were were doing was not just a need to show off – or to follow the text book on Scrum:

“Nobody had a clear idea about what was going on outside their little bubble in the department, and we wanted to increase transparency around that. We wanted people not to do duplicate work but instead realize that someone else had solved their problem, and we wanted to create the space for the engineers to talk to each other about that. We wanted people to realize that a lot of exciting things were going on, and we wanted to enable everyone to provide input and ideas for improvement to help each other.

In short, we tried to mitigate that ‘we don’t know what we don’t know’.”

A need for greater transparency was the main driver but we quickly discovered that there were other positive effects. One of them was that the demo sessions became educational. The demos allowed us to have conversations that converged us towards the same understanding of how we should do things in the the department, like (if and) how to utilize the public cloud and our service management system, and (if and) how to ensure that solutions were GDPR compliant.

Demo to your customers – if you can find them

I had another pressing question, related to the text books on Scrum: why did we start demoing to each other and not to our customers? Rasmus’ smile tells me he has heard this question before:

“We wanted to showcase to our customers but at that time, we didn’t know who our customers were and who to invite.”

‘Infrastructure’ is usually consumed by a large and diverse customer group, i.e. all of the 14,000 IT users in the company, or all 500 IT engineers in the company, so it had been difficult for us to pinpoint persons who could represent our customers in demo sessions. In the old days, project Steering Committees had been proxies of customers, but now we no longer had SteerCos.

“To get started, we decided to show stuff to our colleagues. And it made sense because in many cases they were also our customers. It turned out that the demo was actually a great occasion to start talking about who our customers were.”

The discussions gave us some clarity and even though we were still not able to pinpoint exactly who our customers were we could see the contours of customer groups (i.e. software developers) to certain product groups (developer platform products). We began to structure our demos around those groups and that way we were able to slowly start to identify and invite interested stakeholders (i.e. individual software developers) to attend the specific demo sessions:

“We organized the demos around three product groups: Infrastructure and security products, which is something that we all use but where there are few direct ‘buyers’ or customers. The customer in this case is pretty much invisible to the product teams. Then it was End user products, that is all the products we provide to employees in the company such as computers, meeting room equipment, phones etc. And finally, it was products that we delivered to other IT teams, Platform products. The purpose of those products was to remove cognitive load and make things easier for them. For instance, we could demo our efforts to make ‘getting a server’ an off-the-shelf service.”

An example of a demo session where we addressed the first and last product group is shown below.

Example of demo agenda

The many reasons for not getting on the stage

Working with ‘infrastructure’ is many different things, but in most cases it means a lot of system configuring, optimizing, updating, and fixing issues. The big question is: how do you showcase that? And furthermore: will people listen?

“It was difficult to get people to sign up to do demos in the beginning. People didn’t understand the demo concept very well and there were fundamental questions: what can be shown? What is the frame around all of this? But really, the main barrier for people were insecurity – and a bit of ‘Jante lov’. Do I do something in my daily life that is meaningful to show to others? What questions will I get?

When you are a software developer, you might have a lot in common with others, and find it interesting when others have found cool ways to do some tooling for instance. But if you are maintaining an infrastructure it is more difficult to see what you have in common with others – it is fundamentally different to configure a network, run an SAP batch or set up a PC.”

Another barrier for the engineers was that they ultimately just wanted to do well. If they were to do a demo, they wanted it to work 110 %, and doing anything that felt like less would take them out of their comfort zone.

“I have talked a lot with the engineers about that what they are showing does not have to be finished. That it is more than OK that it is work in progress. There is always something you want to get more on top of – and that feeling we had to work with. And we still work with it.”

All of these thoughts made ‘demoing’ feel like extra work. And the engineers really just wanted to work on their systems and their tasks. So there was a significant task in getting them on board.

What we did to get it to take off

There were significant barriers for people to get on the stage for a demo: understanding the structure, finding the red thread and the golden nuggets in ones own work and story, and not being afraid of getting on the stage. The only way to make the demos a success was to talk to the engineers about their concerns. We helped people dare to get on the stage through dialogue:

“I had dialogues with all the teams who wanted to show something but were insecure or thought they didn’t have something. They all ended up with cool stories. You have to support and help them see and tell the story by helping them find the red thread.

Most people want to tell a story if there are people who are interested, who listen. What I did was to do ‘mini demos’ with them. I told them to forget who would be the audience at the real demo and just tell me what they were doing. That is basically all they needed to do. With the knowledge I had of the organization I could help them by telling them to underline X, Y or Z, because I could see that this would be relevant to others – I knew it would relatable.”

Rasmus made a huge effort in getting the engineers to understand the structure, the purpose, and see the red (interesting) thread in their own work. But another equally important element was helping people to dare. And this part of the facilitator job is mostly about getting people to feel that the stage and the room is a safe space:

“As a facilitator, I am setting the bar for what we expect of the event. I set it low by telling intentionally bad jokes and maybe have an asparagus behind my ear, because that leaves rooms for others to get a little crazy – and that increases the feeling of safety. It is NOT a performance situation. It is an informal, loose situation. It is fun and games – but with a purpose.”

Rasmus in his role as “demo host” on the stage (no asparagus)

The final key aspect of the facilitator role was to ensure that a dialogue starts after the demo in the Q&A section, when the engineer has presented his/her story. As the facilitator and the demoing engineers have met up before the actual demo to discuss the demo, the facilitator has a unique insight that can be actively used:

“I always come with questions for the Q&A. Sometimes the dialogue happens by itself and I don’t need to give input, but other times it gets a bit heavy – especially the silence online can feel enormous if no one is there to start the conversation.”

We use the chat function in our online meeting app to keep the dialogue going. This way people can ask questions as the demo progresses without interrupting, and team members and colleagues can pitch in on behalf of the person who does the demo. And finally, the chat can function as a place to add more humor to the event, where people can comment with gifs and memes, which helps shape the community.

Building the right culture with the audience

Getting people to put themselves and their work out there in the line of fire is not easy. The facilitator can be a positive element but it takes all of the participants to create a great experience:

“Building a culture where we show stuff that is not ready – or maybe not fully aligned with Management who have not formally approved it yet – or what other concerns you might have, that is the key. And tearing that positive, safe culture down is twice as fast as building it up. The audience come with what is almost always well intended feedback such as ‘you need to be aware of this’, or ‘have you thought about that’, but especially in the beginning it is difficult to hit the right tone the feedback is given in. It does not always feel constructive.

As a facilitator it is necessary to be aware of this. And when someone in the audience uses a tone that can feel intimidating or unconstructive, you need to make the person aware of this. Both in the meeting, but also take them aside outside: they are making a really good point, so if they want maximum impact of that point, you help them see how a more friendly approach can help them achieve that.”

The ‘tone’ of the demo is a delicate case to handle as a facilitator. There is a fine balance between intervening in the demo and doing it ‘offline’ person to person.

“After a rough exchange of opinions, the involved parties – the presenter and the feedback giver – might continue the dialogue after the meeting where they patch things up and find each other. The issue is that all of the people who are watching and are potential ‘demoers’ have watched a heated discussion and are thinking: ‘if I have a hole in pants, I will certainly be notified by this crowd!’. They are unaware of the patching up that happens afterwards.”

Setting the expectations – constantly – is the most important role of the facilitator of the demo:

“We need to talk about what is expected of the people who do demos, and the feedback we get is all about getting us to talk about what professional expectations there are. But the form of feedback has to be constructive: the people who showcase do not do it to flash that they don’t care about policies, or that they don’t care about what others have learned. They do their best and they make themselves vulnerable. It is really easy to see the errors – and it is really difficult to showcase. And potentially, we are all showcasing at some point, so let us make it as great an experience as we can.”

How to get an audience

So far in our conversation, Rasmus and I have talked about how to get people on the stage and ensure that the demo is a positive experience for the ones who do the demo. But a demo is nothing if the audience does not show up. In our case, they have showed up: we have seen that around 50-60 % of the invited people have chosen to prioritize to attend, which has – to say it mildly – surprised us in a good way. I asked Rasmus why he thought that the audience keep showing up.

“The demos show that new things are happening all the time. It keeps being relevant that way as there are new technologies and new initiatives that we can present. But we also work for the attendance percentage. We try to find champions in the different teams – also outside our own area – to ensure that we have a broad and relevant menu, and ensure that we have people attending who will get things out of watching – and are likely to ask questions. Actual customers but also internal team members who understand the value of participation and giving back.

We theme our sessions to focus them on customer groups. That makes it easier to invite people from outside our department and it gives synergy in the demos. One demo input can act as a facilitator for the next.”

The future of our demos

The past couple of years of demos have been a success, but can we expect this to continue? When asked about the future of our demos, Rasmus replies:

“Right now, we are expanding to a larger audience and a large pool of potential Demoers by including all of the 800 people in the IT department. But if the participation is declining we need to reconsider if it serves the purpose we are seeking – and if this is the right way to do it.

For instance, if we start to see that many teams are doing demos outside this forum, we should maybe consider reducing the frequency.”

When asked about life after Covid-19, where we can start to meet again in person, Rasmus is clear about his recommendation:

“We will continue to do this online. There might be smaller groups who will attend from a meeting room just to enjoy being together, but with the experiences we have, where the chat is also a big part of the demo session, and to include our colleagues globally – and support more working from home, we will continue this as an online event. It is much easier to opt in and out online, and the second channel of dialogue – the chat – is a big part of the success of the event where people can write comments, questions and support their colleagues.”

Curious to learn more?

Want training, inspirational talks of consulting on the topic?

No Responses

Leave a Reply

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