When Scrum was still in its infancy, a number of events contributed to its formation and its eventual, resulting form.
Jeff Sutherland, one of the agile development method’s co-founders, formerly owned a company next to MIT. At the time, he would pluck young minds from MIT’s Media Lab just as they were graduating. Once outside the lab, they brought with them a mantra that would go on to influence Scrum deeply. They called it “Demo or Die.”
And as a result of Demo or Die, Scrum went on to encapsulate the idea that it’s imperative, as part of a best practices process, to include a demonstration phase prior to a roll-out. It was simply a necessary facet.
Later, all of this would give birth to the idea of the sprint review. The breakneck development phase necessitated a review period, and so the sprint review came to be. For more information on this topic, watch the full video from OpenView Labs featuring Jeff Sutherland.
Jeff Sutherland: In the early days, as I said, the company that I had before the first company that did Scrum was using a predecessor to the Scrum model, and we were located right adjacent to the MIT campus. I actually hired people out of the MIT Media Lab, and that was at the height of the MIT Media Lab, where they were building really cool things that could be demonstrated and their motto was “Demo or Die.”
So we started Scrum. We said, “One of the most important things that we
need to do is demonstrate actually working software in a way that the
people who would use that would really experience it.” They couldn’t
experience all of it, but any features that we worked on, during that
sprint, they could see them and they could use them, and ideally it would
get them excited and they would give us a lot of input on what to do next
and how to do it.
So that demo became a critical part. In fact, the first Scrum team had
problems with the first demo. They were doing a month long sprint, and we
decided to actually do demo every week. I would get people from the
surrounding engineering community, from other companies, some of the
technical experts from other companies to come in every Friday, and our
team would do a demo to them. They would do things like say, “Why are you
building it that way? Haven’t you looked at what Microsoft or Borland is
doing to that? The way you built that really sucks.”
My team, after that meeting, they would all put their heads on the table,
and they would say, “We don’t know if we can do another one of these
demos.” I would say to them, “You have a choice. You can be just another
software development team or you can be a great team, and to be great you
need this feedback.” So they would pick up their heads and say, “Okay.
We’ll do one more demo.” So you can see how critical this would be to build
a really cool product, having that dynamic feedback from people who really
understand what needs to be built.
Now, at the same time, we would meet after that demo and we’d talk about,
well how can we do better in the next cycle? That review has come to be
called a retrospective, where the team goes through, “Okay. What have we
done? What did we like? What didn’t we like? What are the process
improvements that we can make?” So the retrospective follows right after
what we have come now to call the sprint review or the demo of the product.