How to Start a Science Fair
Tired of doing the same old tired demos? Maybe it’s time that you tried a science fair format instead. When we first adopted Agile, we had six teams that were all synchronized on the same sprint cycle. This meant that at the end of the 2 week sprint there was a Friday that was full of demos all day long, back-to-back. Some of our project stakeholders found themselves in the unfortunate position of having to sprint from meeting to meeting, just to keep up with all the demos.
On the flip side, we had teams that complained that they had no idea what other teams were working on. Everyone did their own demo and didn’t have to attend other team’s demos. As a result we had strong silos developing between the teams. To combat this problem we tried what we called a “Science Fair” format for our product demos. The science fair works like this:
The science fair is one-hour long, all the teams and stakeholders show up. This means if you have 5 or 6 teams like we do, that you need a pretty good-sized room with a nice projection system and lots of chairs.
We do food. We arrange to have a couple of platters of sandwiches around so that we can feed the ravening horde…er…developers.
Q&A during the demos is encouraged.
Other than that, it was really pretty simple. We started with just a few rules for the teams.
The rules of the game (first pass):
Each team will need to have a PowerPoint slide prepared with an outline of accomplishments for the last sprint – that way we can post it on the live meeting while you give your update. If there is some cool UI/widget/tool to show off, then bring it on. Send the slides to me and I’ll bundle them up.
The product owner gives a quick intro for each team
Each team gets 10 minutes max to present what they have done over the last sprint.
Demo’s of live software are encouraged
So we put this in place. We had one scrum master serve as the moderator, calling on teams in predetermined order and keeping everyone on time. The initial reaction was that this was a huge improvement over our previous demos. Teams could now see and ask questions about what other teams were working on. In addition, the overall time commitment for demos went from 6 hours of non-stop demos, down to 1 hour. However, there were some trade-offs. Teams only had 10 minutes to give their demo, and some teams felt that this was not enough time to show off what they had done. There was some flexibility in the schedule, so we were able to let some teams do longer demos from time to time. The other problem was that some teams with no obvious UI for their products (transaction processing) had a hard time putting together a meaningful demo. “Hey look! We changed the ‘0L’ to a ‘7F’!” Just didn’t seem to pack the same punch as demos where there was a full-fledged customer UI.
So, we persisted with the Science Fair format for another year. Over that time we noticed a few things happening:
Fewer and fewer demos of working software were happening. Teams would show up with a deck of PowerPoint slides instead.
The audience was dwindling. With less live software being shown, the excitement level was much lower and many stakeholders lost interest. Only part of the team was showing up.
Q&A was missing. When we started the science fair, after it was over the room was buzzing with 1 on 1 conversations where people were quizzing each other on their work. You could feel the curiosity in the air. That had gone away. Now we finished a Science Fair and then we all simply migrated back to our desks.
Realizing this, we decided to change the rules a bit in order to revitalize the Science Fairs. Here are the new rules:
The rules of the game (second pass):
No PowerPoint. Nobody wants to see your stinking PowerPoint.
The product owner gives a quick intro for each team
Each team gets 10 minutes max to present what they have done over the last sprint.
Demo’s of live software are really strongly encouraged, like almost mandatory. Almost.
We added a few other things that helped as well:
Prior to each Science Fair, all of the Scrum Masters get together half an hour in advance and coordinate with each other to lay out the demos. We found we really needed this time to get together and make sure we organized ourselves before the Science Fair. We’d occasionally fail to do this and frankly nothing screams incompetence to your stakeholders like a poorly run demo.
We added a X-Team Summary at the end of the Science Fair where we would talk briefly about department wide progress on goals like quality and time to deliver (some metrics that we use to measure ourselves). It gave people a nice wrap up on the overall progress of the teams as a whole.
These changes to the rules seem to have fairly dramatically revitalized our Science Fairs. We have a packed house every time, and the dialog has returned to its normal mildly combative level (“Are you *sure* that’s a smart idea? What about X?”). Overall, the results seem to have paid off for us. Compared to what we were doing before most people feel that we are making better use of our time. The X-team transfer of knowledge has increased and the feedback for each team is much higher. Teams are generally only bringing working software to the table and they are getting better questions raised as a result.