Skip to main content

Sprint Review as Agile Enabler

An agile process such as Scrum is built on a number of both project management and engineering practices. The engineering practices support the project management practices and the project practices guide engineering decisions. While it takes more than the presence (or absence) of any one practice to cause your agile project to succeed or fail, some practices can drive your process in a powerful way. Sprint reviews are one practice that, when done with the right attitude, can help teams develop and maintain a good project rhythm.

An iteration process has mechanisms in place to help steer teams. Of all of the practices that support iteration, regular sprint reviews help teams and product owners get the feedback that they need to improve their performance. Reviews are also one practice that I've noticed that teams slack off on, especially when they are first starting out.

A common rationale for not having an iteration review are that there isn't enough to show. When the team is not making progress is the most important time to review progress with the product owner and evaluate how the project is doing and what needs to change. While the first review may be difficult, if everyone on the team is committed to a successful project, a review of less than successful sprint can have many positive consequences:
  • The product owner many be more impressed my the progress than the team thought, freeing the team to take more ownership of their work.
  • The product owner may be better able to understand that the backlog might be the wrong size as the team compares the results of sprint to the backlog, providing the team with the data it needs to have a more attainable backlog.
  • The team may recognize things it can do to work more effectively.
It's important that everyone understand the reviews for what they are: brief, lightweight mechanisms for evaluating progress as a group and and understanding how to do improve. This means that it's OK for things to go wrong in a review. And the team should not spend a lot of time preparing or setting up environments. (With good engineering practices you should be able to build and deploy a "review version" quickly. If you can't considering prioritizing Deploying Early.)

As you identify issues it's also important to review progress on these issues at subsequent reviews. If you let them drop then the people at the review will come to understand that the review feedback is part of an empty exercise. It's OK to acknowledge that a review item wasn't acted upon, or is no longer necessary. But you should discuss each action from a review at the next one.

While this sounds easy, there are some challenges including establishing trust between the product owner and the team, and developing an understanding that they share the same goals. You need to be able to talk about what's not working, and figure out how to make it work, not just assign blame. If the team and the product owner is new to Scrum, and the project is new, you may have to start with a premise of trust. This is hard, but with the regular feedback of a review each sprint, the stakeholders will be able to readily evaluate everyone's dedication to the project.

It's very important to discuss what went well, preferably before covering what needs to be improved. (I tend to favor the attitude I learned from patterns writers workshops.)

Some suggestions for those struggling with agile:
  • Have reviews at the end of each Sprint, using your backlog as an agenda.
  • Show the work done in the simplest way possible.
  • Collect feedback both on the work and the process, and identify things that went well and things to improve.
  • Save the list of things to improve for the next review, and be sure to discuss them.
Agile methods are based on periodic feedback, and a review is a lightweight process to give feedback essential to a team. If your team is struggling with agile, have reviews each sprint, and try to understand what's working and what's not. The review will guide you to the most critical issues (technical and organizational) that you need to address.


Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…