Is your team doing agile software development and perhaps using Scrum as project methodology? If so then you most certainly are doing demos for your customers at the end of each sprint. This was the case for us. We were a quite wellformed team, we had worked together as a group for maybe 10 sprints and had been able to come a pretty long way with our application.
Personally, I am a consultant and at this point I was working at a large bank in Sweden building an internal web application for the investment advisors in the bank. The project was pretty large and had been running for about a year when I joined it, and the project was going into a phase where my specialty as a Java EE frontend and GUI developer was needed.
Anyway, to put it short, in the development team we were doing our best to stay agile. We used many of XP:s well proven techniques like pair programming and TDD and as I mentioned we used Scrum as project methodology. And the story you are about to read is actually a very good example of how using an agile and adaptable way of working really can benefit a project.
Identifying the problem
The team had just completed a really good sprint. All stories hade moved from Todo to Done and normally everything would have been fine. But since our team consisted mainly of individuals that had the ambition to become great instead of good it was not perfect. There was something that bothered us. At the demos and sometimes also during the sprint the customer, meaning the business people that were on the receiving end and for whom we were building the application, did not seem interested. And the other listeners at the demo did not seem interested either. We had to fight hard even to get them to come to our demos. All over the room there were people who probably rather played games or checked the latest news on their mobile phones instead of listening to our demos. And I can not really blame them, because our presentation of the progress that had been made during this sprint was pretty lame. In front there was a developer sitting down looking at the screen and showing the new functions in the application in a boring and tiresome way. I could barely stay awake myself. But I am a consultant so I pinched my arm and tried to focus. But why was it like this?
Like people leaving a funeral we all left the meeting room after the demo and went to lunch. After lunch we had our Retrospective, a meeting that some people see as the most important meeting in Scrum. It gives the team a chance to make improvements to the development process, which is great because we can improve stuff that is not so great. And in this case those people were right. At this particular meeting, when doing the Mad, Sad, Glad activity many sticky notes ended up in the Mad and Sad column. We were Mad the the customers were uninterested in our work, and we were Sad that our demos were so boring. That was when I stepped forward and said: ”We must stop complaining about the others. We must work with our presentation skills.”
We all agreed to the topic being worth to investigate further since we all had the feeling that we could do much better at the demos. So we decided to dig deeper into it. Using a cause/effect diagram we realized that the effect of this problem, that our demos suck, was that since nobody is really paying attention to the demos, or even worse not showing up at all, we do not get the feedback from the customer that we need in order to know if we are building the correct stuff. This was serious. What if we were building a great application that did the wrong things? Root cause of the problem was that our demos were unplanned, and therefore turned out to be unstructured and uninteresting. This was really serious, and we had a situation we definitely needed to deal with. We had worked hard for two weeks and still we were not proud enough to present the work done to the business side in a good way.
During this retro we created only one action to work with in the upcoming sprint: Make a demo we were proud of!
Implement the solution
So how on earth would we address this problem? We needed both to make the demos more attractive to the audience and also structure the content of the presentation better. Without structure it could not have been easy for the customers to understand all that was shown during the demo. And without the customers understanding it could not have been easy for them to give relevant feedback during or after the demo.
After a day or two into the sprint one of the more experienced members of the team, Adam, came up with an idea. He told us that he had been watching TV late last night and now suggested that we should give the presentation in the same way as they do on TV shop! Naturally the team’s first reaction to this was that he had gone crazy, but after having discussed it further we all realized that it was brilliant. In TV shop they have one person asking relevant, and often very simple and sometimes even stupid, questions regarding the product. Then they have another person, the expert, giving all the answers. This format of the presentation could give us a chance to communicate the changes we made since last demo in a structured way. The one asking questions could set the context and the one giving answers could demonstrate how the application solved it all in an excellent way.
This idea got all our brains working and I came up with another idea to complement the TV Shop idea. Just the day before I have had the chance to watch Robert C. Martin, also known as Uncle Bob, in action. He was talking about Test Driven Development, and the way he delivered the presentation was almost breathtaking. If you have seen him make a speach you know what I am talking about. He never stands still on scene and he is such a good speaker that I bet nobody is falling asleep during his presentations. He mixes acting with real content in a great way. I bet we could try that. I proposed that we should also add drama to the demo, to make the presentation more appealing to the audience.
This could be fun and we decided that I and Adam should handle the first demo in this new way. The two of us taking care of the first demo came pretty naturally since we definitely were the two within the team that were most excited by this new format. We were also the ones that probably had most experience in presentation and did not mind acting in front of our colleagues.
We realized that we could not come unprepared to the demos anymore. So, during the last day of the sprint we reserved some time for preparation of the demo. For about two hours we sat down and came up with characters to play and a manuscript. The manuscript did not only contain the order in which the completed stories would be presented but also the things our characters would talk about in each of these stories. The characters we choose for this first demo in the new way, the premiere, were Adam the Advisor and Per the Confident Developer.
9:30 the following morning it was time. Before the meeting we had talked a little bit to our colleagues about that we had worked on our presentation technique and that there might even be a bit of drama during this demo.
Advisor: Hey Per! I have one of the most important clients in the bank on phone, and they say the want to see how their total assets are currently allocated between different asset classes. They say they might want to make some changes. Can I do that in the application?
Confident Developer: Yes of course. We have actually built just that functionality in this sprint. If you click on the Holdings tab in the application you can see a pie chart showing you just that information. See, your important client have 50% Shares, 30% Bonds and 20% Cash.
Advisor: Good! But my client also wants to see in what way their current asset class allocation differs from what the bank recommends. I’m sure the application can not do that as well!? I’m probably screwed…
Confident developer: Calm down, if you look to the right of the previous pie chart that showed you the current allocation you can see another pie chart. That one actually shows what type of asset class allocation the bank recommends.
Advisor: Great, now I and the client can compare those two charts and see if any changes should be made. Thanks!
And so it went on for about another 10 minutes, the Advisor asking relevant questions and the Confident Developer giving answers and showing the application. After the demo was done we instantly could tell that we had succeeded. We both got applause from the crowd and we also, and most importantly, got good feedback from the customer.
The demo had been a success. Both the customer and us in the team were pleased with how the demo had turned out. It felt as if the customer had become more interested in what we had done during the sprint and that they, for the first time in a long time, actually reviewed the outcome of the sprint. The questions and comments during and after the demo really told us that they were paying attention.
Everyone in the team also agreed that we had more fun during this demo than in any other before. And having fun is an important part of your work. If you like what you are doing at least I think that you automatically perform better. It was no question about it that this new way of presenting the team’s work was a keeper. We were proud of it and we decided to accept it as a part of our development process.
By the way I want to mention that after a couple of weeks I bumped into a guy working at the same consulting firm as I do. He was also working as a consultant at the same bank, but at another department. I mentioned the things we had done to improve our demos and to my (happy) surprise he said: ”So you were the guys!? I’ve heard people at my project speaking about at team that were acting on their demos.” People were talking about our performance. 🙂
Adapt our current way of working
So we decided that from now on our demos would be something that people would want to come to and look forward to, and not something we and the customers were trying to avoid. We adapted our way of working and continued to book two hours the day before the demo for preparation. We needed this to feel confident when going into the demo room the next morning. Those two hours were not spent on any development anyway since the deployment to the test environment was done at 15:00.
After a while it became clear that being well prepared for the demo was quite hard and took some significant amount of time. Most of the preparation time was spent on finding good test customers and deciding on what to demo in each story. So instead of doing all that for all stories at the end of the sprint we added a task on each story called ”Prepare demo”that you had to do in order to be done with the story. To complete this task one would have to find a well suited test client to demo that particular story with, and also write down a short scenario on how to demo and describe the story. This task was very easy and did not take long time to do since you were already working on the story and had all the facts currently in your head. Having these notes on each story really helped when it was time to prepare the full demo, and it saved a lot of time. After this tweaking of the work process the preparation of the demo was reduced to about one hour.
We also decided to keep the TV Shop style of doing the demo. One person would drive the demo with questions and make sure the structure of the demo was kept, and the other person would give the clarifying answers and show the new functions in the application.
I addition to the setup with two people performing on stage we found it was helpful to assign a character to each of the persons. Having characters and a manuscript made it easier to relax because it felt like you were just playing a role, instead of speaking in front of important people. Adding drama to the demo made it more fun to prepare, realize and most certainly to watch and we used many different characters and scenarios besides from the Advisor and Confident Developer. For instance:
– An overworked Project manager going from very nervous to very calm during the demo when he realized that all of the customers demands had actually already been built during this sprint.
– Time travellers using a time machine to present how the application looked two weeks ago compared to how it looked on the day of the demo.
– A reporter from Sports News doing an interview with the coach of the (development) team to see what their feelings were about the last game (sprint) and also have a look at some highlights (functions in the application).
– At the last demo before Christmas Santa Claus paid us a visit with a long list of wishes for the application. Fortunately almost all of these wishes had already come through.
Of course, I must add, it was important that the drama did not take too much control of the demo. The main goal was still to deliver the message to the customers about what was done during the sprint and to get their feedback. So we mainly used drama for the intro and the ending of the demo.
Other success factors worth mentioning, and that goes for all presentation, were of course to stand up, look happy and speak clearly. We also tried to stay away from tools like Power Point as far as possible and instead talk a lot and show the functions directly in the application.
I would like to end with a funny anecdote. During the time that we introduced this new way of doing demos we had an Indian consultant on our team. He was a tester that was working locally here in Sweden for a couple of months before he went home to India to continue working with us. We thought that everyone should know the application well enough to be able to demo it. And what was a better way to assure that than to take turn and let everyone make a demo. This time the turn had come to the Indian consultant, and since he was quite shy and a bit of a low talker I had my concerns for him.
When it was time to prepare for the demo I remember that Adam, who was teaming up with the Indian consultant to hold the demo, told him that it was very important to speak loud and clear so everyone could here him. He also told him that it always is funny if you add some gestures to the presentation to give it some extra spice. They decided that Adam should sit by the computer acting a developer and answering questions, and that the Indian consultant should act the role as a stressed out tester.
Next morning and time for demo:
Tester: Hi Adam, I need to find the link to the test environment. I have looked everywhere and I can’t find it. I am getting a bit stressed since I am going to do a demo tomorrow.
Developer: Calm down, the link is here somewhere on the Wiki. Give me a second and I will try and find it.
Tester: WHERE IS THE LINK!!! I NEED IT NOW!!!
The last line was delivered screaming, with arms waiving and with such feeling that everyone watching sat up straight in their chairs wondering what on earth just happened. I bet nobody was falling a sleep during that demo…
So, to sum up. If you have a situation like ours, spice up your demo with drama. Use the new DDD – Drama Driven Demo! And remember, if our shy Indian consultant could do it, so can you!
Co-founder of Drama Driven Demo
Here is a link to a speech given by Adam, in Swedish, about Drama Driven Demo at the conference Agile Sweden 2012