Discovering the Value of Pride in Agile Sprint Reviews
In Agile organizations, when a developer is showing their work during a sprint review, it is an important moment. This is when they get feedback from stakeholders and others on functionality they have worked hard on during a two-week sprint. And you want developers to be proud of their contributions, proud of how those positively impact customers.
Being proud generates confidence, and the more confidence developers have, the more risks they’re willing to take for the benefit of your customers. If you have a healthy level of pride, you have passion, and you need passionate explorers to truly ideate and innovate in ways that differentiate your organization by exceeding customer expectations.
But to have pride developers must understand and believe what they’re accomplishing is important, that it matters. If developers aren’t proud, that’s a warning sign. It often means they don’t understand the impact of their work because they don’t understand end-user needs, which is potentially because you haven’t taken time to explain.
Alternatively, and even worse, a lack of pride could signify a lack of passion—unengaged or disengaged people who don’t believe in what they’re doing. Again, this could be because they don’t understand the impact of their work or the user needs. But it could also be because they don’t like the functionality you’re delivering, whether from a technical or UX perspective, even though it’s what the team has decided it needs to deliver based on end-user feedback.
That’s why pride is important to the proper functioning of a customer-focused, Agile team. The sprint review is a great environment to foster this attitude and see where it may be lacking.
Matt’s Experience as a Scrum Master
The sprint review is not only about getting feedback from stakeholders, though that is the largest part of it. One of the other functions of it is to give developers a chance to show off what they have built and to feel good about what they have created.
To help promote a sense of pride during this process, one of the things we do is try to connect everything that we go over in the sprint review to the overarching goals of the team. This makes clear to stakeholders what the team’s progress amounts to, not only on their sprint goals but also on projects that may span multiple sprints.
By doing this, we not only demonstrate that something meets the acceptance criteria, we also demonstrate that it’s well-thought-out and that it connects with our end users. That proves the team understands the problems they are trying to solve, that they are not just coding new things for the sake of newness. It’s much easier to feel proud of things you create when those things are solving real customer needs.
Mark’s Experience as a Product Owner
As a product manager and product owner, I want the developers to be proud of what they have produced for our end users. I want the team to feel proud of their accomplishments. To me the sprint review is a perfect time to see that.
But setting the stage for them to feel proud precedes the sprint review. Even before coding begins, I need to make sure things are in place for developers to create useful functionality end users love.
For instance, I need to provide developers with well-crafted stories that end users have vetted, including their priorities. This provides confirmation that what the developers produce will solve an end user’s problem. As another example, I also need to have conducted consultations with our UX team to ensure developers understand the customer-focused intent of a design they can code towards.
Several things have to align for the team to produce good work they can be proud of, but none if it matters if I don’t communicate it to the team.
Don’t Overlook the Importance of Pride
Don’t overlook the importance of promoting healthy levels of pride in your Agile teams. It is an important factor to ensuring your teams are engaged in and passionate about their work and how it helps end users. The sprint review is a great way to see whether that is true.
To learn more about building a culture that empowers developers to feel pride and passion in their work, read our eBook on ditching Waterfall for DevOps.
Mark Schettenhelm is Product Manager for Compuware’s ISPW product. Matt Kramer is Scrum Master for ISPW.