My First Agile Project Part 3: Viral Videos and Bad Jokes in Scrum Demos
Originally published on AgileSoftwareDevelopment.com
Welcome to the 3rd part of my series on my first agile project. This time, I’ll be talking about every introverted programmer’s favorite part of Scrum, the end-of-sprint Demo. More specifically I’ll talk about how we cracked wise, showed internet videos, heckled each other, annoyed our management, and occasionally showed off the work we had completed during the previous sprint.
Even though we usually dreaded them, our demos almost always went off okay and we all came out alive. If you’re not familiar with them, the demo is where the team shows off the work they’ve done during the previous sprint. We were doing 4 week sprints so we usually had quite a few things done by the demo. It’s sometimes the first chance your teammates have to actually see what you’ve been doing and to to catch up the rest of the team in a more concrete way than the daily stand-up meeting. It’s also where you’re supposed to get the feedback of the stakeholders and customers involved in the project. With our billing application project, we were interacting with a bunch of different departments in the company so we had a lot of stakeholders. In theory, all of these people will see the product and give feedback. In reality, this doesn’t always end up working like you’d hope. Getting your demo right is much more important than we initially thought.
—
Integration Project Demoing Challenges
Demoing an integration project isn’t a topic I see discussed very much. A lot of the writing about Agile in general is geared toward new product development, not configuration or integration of existing products. Demoing an integration project is a lot harder than the literature on demos would suggest. With a new product, you can show off a new piece of functionality or screen, something like that. On a project like ours, we had a product that was mostly complete looking. And since you’re showing your work off to business people, how it looks is most of what they’re getting out of your presentation. Even interface configuration changes can be subtle and uninteresting, which is extra important if the change is very valuable since you want people to pay attention.
We had a lot of “behind the scenes” processes and integrations with other systems to build as well, which presents a whole different set of demoing challenges. In a billing system, the interface consists of lots of numbers. For a lot of our integrations, you literally work for a month on something and your demo ends up being “I’m going to simulate Event X in this other program by pushing this button and Voila! this number appears in the billing system.” Our team was split roughly into integration programmers, configuration specialists, and database specialists. For the programmers, most of what we did was this kind of thing. “Once a month, this process will run and generate this not-human-readable file to send to the bank.” This isn’t as much of a problem showing off to your team but to the stakeholders, this is nap-time. Part 4 in this series will go into the issues we ran into with disinterested management. It’s a big topic and one that deserves more space than I can give it here.
We had 10 to 12 people demoing and another 10+ in the audience so we did our demos in a conference room on a large projection screen, not at the developer’s workstation as a lot of people do. Doing a demo on a big screen lets more people see it but a lot of what people think of something is based on actually using it. We’ve put in tons of fixes nobody suggested at the demo but came up immediately when the same people sat down and actively used the product. I really recommend getting people to sit down and use your product as early as possible, it’s extremely helpful.
Coping Mechanisms
Getting up in front of a bunch of people and showing off your work doesn’t tend to land high on most programmers’ list of favorite activities. For some people, this means getting stage fright of varying seriousness. We decided early on not to take too much time from doing our real work to try to work on our presentation skills. We just did our best and every demo we got better. Of course we had some people who aren’t good at presenting but since we knew what they were talking about we tried to help each other as best as we could. I’m a shy person by nature so I don’t enjoy presenting but I compensate by making jokes and basically entertaining myself while up at the podium. As long as you’re not taking up too much time with non-work stuff, people don’t mind the joking around. Since we had 10 to 12 people on the team and a month of work to show, our demos lasted a few hours usually and the audience was as ready to break up the flow as I was. One of our team members is very funny and always did the best presentations. Once during his presentation he told everybody “that buzzing you’re feeling in your head is your mind being blown”, which cracked everybody up. One month I used the Dramatic Chipmunk video in my demo before an important thing happened. Then after that I introduced our champion presenter using the Dramatic Lemur video, which uses the THX sound you hear before movies. This definitely helps to break up the demo for everybody so I would encourage letting people “off the leash” a bit and try to make their demo a little more entertaining.
We’re trying to figure out the best way of doing our demos so please share your demo stories below. I guarantee my team won’t be the only ones interested in your experiences and ideas. As always, thanks for reading.
Welcome to the 3rd part of my series on my first agile project. This time, I’ll be talking about every introverted programmer’s favorite part of Scrum, the end-of-sprint Demo. More specifically I’ll talk about how we cracked wise, showed internet videos, heckled each other, annoyed our management, and occasionally showed off the work we had completed during the previous sprint.
Even though we usually dreaded them, our demos almost always went off okay and we all came out alive. If you’re not familiar with them, the demo is where the team shows off the work they’ve done during the previous sprint. We were doing 4 week sprints so we usually had quite a few things done by the demo. It’s sometimes the first chance your teammates have to actually see what you’ve been doing and to to catch up the rest of the team in a more concrete way than the daily stand-up meeting. It’s also where you’re supposed to get the feedback of the stakeholders and customers involved in the project. With our billing application project, we were interacting with a bunch of different departments in the company so we had a lot of stakeholders. In theory, all of these people will see the product and give feedback. In reality, this doesn’t always end up working like you’d hope. Getting your demo right is much more important than we initially thought.
—
Integration Project Demoing Challenges
Demoing an integration project isn’t a topic I see discussed very much. A lot of the writing about Agile in general is geared toward new product development, not configuration or integration of existing products. Demoing an integration project is a lot harder than the literature on demos would suggest. With a new product, you can show off a new piece of functionality or screen, something like that. On a project like ours, we had a product that was mostly complete looking. And since you’re showing your work off to business people, how it looks is most of what they’re getting out of your presentation. Even interface configuration changes can be subtle and uninteresting, which is extra important if the change is very valuable since you want people to pay attention.
We had a lot of “behind the scenes” processes and integrations with other systems to build as well, which presents a whole different set of demoing challenges. In a billing system, the interface consists of lots of numbers. For a lot of our integrations, you literally work for a month on something and your demo ends up being “I’m going to simulate Event X in this other program by pushing this button and Voila! this number appears in the billing system.” Our team was split roughly into integration programmers, configuration specialists, and database specialists. For the programmers, most of what we did was this kind of thing. “Once a month, this process will run and generate this not-human-readable file to send to the bank.” This isn’t as much of a problem showing off to your team but to the stakeholders, this is nap-time. Part 4 in this series will go into the issues we ran into with disinterested management. It’s a big topic and one that deserves more space than I can give it here.
We had 10 to 12 people demoing and another 10+ in the audience so we did our demos in a conference room on a large projection screen, not at the developer’s workstation as a lot of people do. Doing a demo on a big screen lets more people see it but a lot of what people think of something is based on actually using it. We’ve put in tons of fixes nobody suggested at the demo but came up immediately when the same people sat down and actively used the product. I really recommend getting people to sit down and use your product as early as possible, it’s extremely helpful.
Coping Mechanisms
Getting up in front of a bunch of people and showing off your work doesn’t tend to land high on most programmers’ list of favorite activities. For some people, this means getting stage fright of varying seriousness. We decided early on not to take too much time from doing our real work to try to work on our presentation skills. We just did our best and every demo we got better. Of course we had some people who aren’t good at presenting but since we knew what they were talking about we tried to help each other as best as we could. I’m a shy person by nature so I don’t enjoy presenting but I compensate by making jokes and basically entertaining myself while up at the podium. As long as you’re not taking up too much time with non-work stuff, people don’t mind the joking around. Since we had 10 to 12 people on the team and a month of work to show, our demos lasted a few hours usually and the audience was as ready to break up the flow as I was. One of our team members is very funny and always did the best presentations. Once during his presentation he told everybody “that buzzing you’re feeling in your head is your mind being blown”, which cracked everybody up. One month I used the Dramatic Chipmunk video in my demo before an important thing happened. Then after that I introduced our champion presenter using the Dramatic Lemur video, which uses the THX sound you hear before movies. This definitely helps to break up the demo for everybody so I would encourage letting people “off the leash” a bit and try to make their demo a little more entertaining.
We’re trying to figure out the best way of doing our demos so please share your demo stories below. I guarantee my team won’t be the only ones interested in your experiences and ideas. As always, thanks for reading.