In our retrospective this week I wanted to look at the “definition of done”, but during the opening one of my team brought up some issues with the sprint demos, so we talked about that instead!

What is the sprint demo?

Also called the “Sprint Review”, the demo is one of the “continuous improvement” activities. It serves to communicate the current state of the product to the stakeholders, and provides an opportunity to inspect and adapt based on the feedback they offer. Constantly reflecting on the state of the product is an essential part of building an agile team, without the opportunities to inspect the current product and adapt the direction we’re developing it in, we wouldn’t be very agile.

The demo should be attended by the entire Scrum team, and anyone who is interested in affecting the direction of the product.

Our Demo

Unfortunately, the problem raised with our demos was a significant falloff in the number of attendees. One of the causes is that our sales team is often out on the road, and so unable to attend - but recently we’ve had no-one from the sales team attend, which is a problem because it means we’re missing vital feedback from the people who have the most frequent interactions with our customers. This first problem is mine to solve, and unsurprisingly, we can solve it using individuals and interactions! By meeting with the sales team we should be able to arrange that some members are available to attend the demos, especially when features are being released that are targeted at the customers belonging to specific individuals.

The second problem is that, so far, our demos haven’t been terribly slick. I’m a big believer that we should be demonstrating working software, and that the software should (ideally) speak for itself - but sometimes a little polish is necessary to help our stakeholders see the value in attending the demo. If the value of attending the demo is perceived to be low, then it’s not surprising that attendance would drop off.

Who gives the demo?

The first thing we talked about is who was going to give the demo, my initial position was that I wanted the individual team members to present what they had worked on. My argument for this is that I want my team to be proud of their work, and part of that is feeling confident to stand up in front of our stakeholders and talk about what they’ve done. On the flip side, if they’ve done work they’re not proud of then presenting that work would help to reinforce that what we (as a team) want from our software is high quality.

On this point it turns out I’m wrong, the team (rightly) pointed out that the sprint is a team effort - and if work is presented individually it will naturally result in the stakeholders assessing the performance of individuals rather than the team as a whole. In turn, this will mean the team is incentivised to work as a collection of individuals rather than a whole!

There isn’t an Agile tenet or principle that calls this out as wrong, except that it discourages individuals and interactions, however, it is clearly goes against the concept of the Scrum team acting as a single cohesive unit.

Instead, for this sprint, I will give the demo. In future sprints I expect we will rotate the duty through the more senior members of the team.

Having one person act as representative for the team reinforces the idea that the demo is a presentation of the team’s work as a whole. It will also help to make the demo smoother, as the individual can more easily transition from one feature to the next.

Showing value

The Agile principles have quite a lot to say about what we should be demonstrating:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

The only things that matter are “valuable software” and “working software”. Everything else we do is to serve us in the producing software that meets those criteria. The value in new features is often easy to show, just demonstrate the feature! Even bug fixes aren’t too difficult, and there are certain bugs we’ve fixed that have raised a cheer from the audience. But what about things like performance improvements? This came up recently for us, as we’ve been working on speeding up our synchronisation. At the demo we set-up an old version and demonstrated how long it took to synchronise the data from one of our sites (it was quite a while), then we set-up the new system and did the same operation - which was around 100 times faster. The difference was easily demonstrated, and the audience was suitably blown away.

Next we come to the more difficult areas of technical debt and spikes. My team argued that there was no way to demonstrate the benefit of refactoring, and my argument is that if there is no visible benefit then why would we do the work?

I’m no stranger to the idea of technical debt, I’ve written plenty of code that I know could be better and I’ve worked with plenty of code others have written that obviously needs to be refactored in order to ease the maintenance burden. I firmly believe that we should strive towards as clean and manageable a code-base as possible - but I also believe that this can’t be at the expense of being able to deliver valuable and working software!

Strategies for dealing with refactoring and technical debt is an article on it’s own, so for now I’ll focus on a few ways to demonstrate value:

1. Attached the refactoring to a valuable feature. This is by far the easiest, and fits well with the idea of tackling debt when you encounter it. After all, if you’re not working with code which needs refactoring then you are not paying any interest on the debt - refactoring that code only serves to introduce risk and waste resources.
2. Do two sets of estimates for stories that touch the code you want to refactor, one with the refactoring done and one without. At the demo use your velocity estimate to show how much more you will get done as a result of the refactoring.
3. Add tests for the refactored code, and demonstrate the tests running at the demo and show a report of the results. Testing is valuable, and helps to build confidence that the developed software is working software - so show the results of the testing!

Last of all, there are research spikes. It’s difficult to describe how to show the value in a research spike, because every spike will be different, but I still believe the team should search for ways to present the value in the work they’ve done. A spike to select the correct database-backend for example might include researching licensing, architecture, resilience, performance, scalability and various other aspects. The stakeholders are unlikely to want detailed technical explanations of how eventually consistent models work - but they might care that your research has identified that MongoDB will scale much better than PostreSQL for their application.

That’s it for this post, hopefully I’ll get to “definition of done” at the next retrospective so I can write about it here!