Experiences with Scrum – Part 1: Sprint Demo

Over the past couple of years, I have used Scrum as the main project management methodology on my projects. I adapt the exact methodology from project to project or team to team and usually it is a pretty light weight, unsophisticated and / or bastardized variant.

That said, I often get asked about my experience with Scrum so I thought I’d do a little series. First up, my favourite: the sprint demo.

Why is it my favourite? Several reasons but in short, it allows you to build a better product by building a better team (which I guess is true of the entire Scrum process).

Most importantly, I am a strong believer that when you use a software product you can feel how well the team understood the problem space, cared about quality, etc. As the sprint demo shows an early, iterative version of the product, it allows you to catch these kind of problems early that would otherwise maybe go undetected until the final milestones of the product lifecycle.

It is also a great tool to help the team develop “outcome-based thinking” which is especially critical with a young, inexperienced team:

1. You imagine / set an outcome at sprint planning
2. Work for generally a very short period on what you think will be the most effective / efficient action steps to reach that outcome
3. Demo whatever you have actually accomplished at the end of the sprint (proof is in the pudding)
4. Repeat

Slowly but surely, you will see the team getting better at setting outcomes, better at reaching them and better at selling them in the demo. You often see 3 different stages:

• PHASE 1: Several team members don’t have a demo prepared. This is especially true for new graduates. Without getting too psycho-babbly on you, the underlying reasons are typically the following:
  • They did not get anything done as they do not yet know how to do “knowledge work” efficiently and effectively and end up frittering away much of their time. This “pathology” can often be resolved through the Scrum process itself and some on-the-job mentoring.
  • They want to produce great work and they just do not feel that any of the work is good enough or worthy enough to demo (“I have got a PhD for **** sake and this demo is just a webpage with an algorithm I learned in Statistics 101″). In short, they need to learn some “humility” and to acknowledge and celebrate their small wins.
• PHASE 2: Individual team members start to enjoy demo-ing and looking forward to it. The whole event becomes a celebration and you feel momentum building. Outcomes and demo’s become crisper and gradually more and more ambitious.
• PHASE 3: The team starts to collaborate to build cooler demo’s. Team members starts to leverage each others skills to get to bigger and better outcomes. That is when you know you are on a roll.

It is a great thrill to see a team getting better and better after each iteration, and a product slowly emerging from what was first just an idea in someone’s mind.

So, in short: demo EARLY and demo OFTEN and by doing that build a BETTER team!

Advertisement