A failed Sprint Review

This had been our pattern for the last several weeks. As Product Owner for this project, I found this very frustrating. Particularly because I had been asking for continuous delivery for several sprints, but the team still wasn’t doing it. As a Scrum Trainer, I found it very embarrassing to be having problems with getting things done. My team was embarrassed too. They are a good team. We’re better than this. How did we get into this trap? More importantly how do we get out?

Step 1 is listening. (see From a Blame Culture to Fearless Trust) I believe that when people really listen to each other, great things can happen. My personal challenge was putting away my frustration so we could listen and discuss effectively. Juliano and I sat down on Skype and Hangout and talked and listened to each other. We identified several things:

1. I was concerned that I was doing too much of the thinking about how to solve the problems.
2. Juliano felt the giving the team responsibility for creating the the how-to-demo section had been a good thing, as it encouraged them to really think about the issues.
3. Our definition of Done has included continuous integration with a Jenkins build since the beginning of our project, but for many reasons, we had not actually implemented it. So creating and publishing a build was a lot of work. (see Sample Definition of Done )
4. The team was doing overtime every sprint.
5. The team felt pressure to deliver as many stories as possible, so they were committing to the maximum they could. As a result, they had no time to work on quality issues, like setting up build server or responding to feedback if it arrived during the sprint.
6. The definition of Done was being applied at the Sprint level, not to each individual story. So all the stories were getting delivered shortly before the end of the sprint without any time for feedback.  (see It’s Done! (or is it?) ) 

Particularly these last two items were causing the long Sprint Reviews. After discussing these points, we agreed to emphasize quality over quantity. So now we had a shared commitment that getting some things really done is more important than getting everything sort-of “done.”

As a result, we put one new item in the Product Backlog.

“As Product Owner, I would like a new build when every feature is completed, so I can confirm that stories are really done as soon as possible.”

We prioritized this as number 1 for the next sprint, even higher than unfinished work from the previous sprint. The team focused on getting the build server working, then on getting stories done one after the other, and in the order prioritized. They also reviewed the definition of Done, and how they could better ensure that things were really done.

As I write this, tomorrow is the Sprint review, so this is a work in progress. Some changes are already visible:

1. The features have been coming one by one, which makes it easier to review them and give feedback. The team delivered three releases, probably another one will come before the review. So we have quadrupled our output of potentially releasable software.
2. We discover problems quicker on the way to Done – “hey, this story has no ‘how-to-demo’ defined. How do we know if it works?” or “This doesn’t install on my iPad 4.”
3. We are thinking much harder about how to ensure that stories are really Done. We use TargetProcess to manage our work, so we are exploring how to use the test suite and task creation plugins to automate the routine parts of identifying what has to happen to get a story to done.
4. The quality of the delivered stories has gotten much better. It seems taking off the pressure to deliver quantity enables the team to do better.