Trust but Verify – Measuring Value with Agile
In my last article, I talked about how trust is the secret ingredient to high-performing Agile teams.
You check your blood pressure, tire pressure, and your stock prices. But when was the last time you audited your Agile?
Even experienced agilists can fall into bad habits and it’s important to catch them early.
During your next retrospective, ask your team to answer each of the following questions with a five-star rating scale. Five stars means you have a super awesome process, and one star essentially means you have no process or it’s really poor. Of course, most scores will be in between, but they will help your team focus on improving the weakest points.
The way I sometimes explain this question is if someone were selling our standups on a website, would the team buy them?
A low score on this question suggests that your standups aren’t as valuable to the team as they should be. Other warning signs are participants not paying attention, looking at their phones or laptops, or simply sitting down—remember, people should literally be
Teams that score high on this question tend to use standups the way they should: to drive the project forward. When they talk about what they worked on yesterday, they include a story number and a description of their story. They state whether they’ve completed it, or how close they are to getting it done, so teammates who may have a dependency on the story, or need to test it, or do a code review of it, will be aware. Everyone concentrates on what teammates need to know, and how it affects them.
A low score on this question probably means that people aren’t aligned on (or aren’t adhering to) the team’s agreed definition of “ready.” Each person on the team is responsible for calling out where stories lack clarity. Poorly constructed stories result in churn and wasted time.
Developers, quality engineers, and product owners must agree on definition, business value, requirements and internal dependencies.
Otherwise, you’ll find bugs, pushbacks and failure to sign off on a completed story.
If your goal is to deliver business value, your effort is measured in story points, and you have no idea how many points you’ve delivered, you might be coding and to some extent you might be delivering, but you’re not doing Agile right and you’re definitely not working as effectively as you could be.
Each team member should rate how well they were able to do good work and get things done throughout the sprint. Low ratings on this question could mean several things. The team may be struggling with a distracting work environment.
Or they might have too many meetings. Meetings, like any process, should be kept to the minimum necessary to facilitate work. As the saying goes, only work gets work done. If it’s taking too long to get clarity on stories, or interaction with other team members is slowing people down, that can manifest itself as a general sense of delay.
Sometimes teams that score low on this question are struggling with basic principles of Agile. This can happen when several members of the team are junior, new to Agile or even anti-Agile (it happens!). But even experienced teams can forget basic Agile principles. It can be shocking to realize your team has no idea how many story points they’re delivering, or what their velocity is.
If your goal is to deliver business value, and your effort is measured in story points, and you have no idea how many points you’ve delivered, then you might be coding, and to some extent you might be delivering, but you’re not doing Agile right, and you’re definitely not working as effectively as you could be.
There’s an understandable tendency to use retrospectives for back-slapping and high-fives. Everyone loves praise. But the goal of a retrospective isn’t personal validation. It’s to pinpoint what went right and wrong in the process so you can make future sprints better.
Intuitively, you might expect teams to rate the enjoyable “donut” version of the retrospective higher than the rigorous “bran muffin” version, but in fact the opposite is true. On some level, people know they’re skating by, even if they don’t understand exactly what a retrospective is for. Low ratings on this question probably mean that you need to make retrospectives more businesslike, and save the applause for an after-work celebration.
When scoring questions, approach it the way you would planning poker. Discuss any discrepancies you might find. If someone is giving daily standup a 1, what’s their rationale? If others think it’s a 5, why do they find it so valuable?
Be sure each member of the team provides his or her own evaluation. Sometimes the lead or scrum master thinks things are going great, but the cards reveal the truth.
These questions may be simple, but they can uncover significant health issues before your team goes far off the rails. If you take the time to do regular audits, you’ll dramatically improve the focus of retrospectives, improve the balance of the team and deliver more business value, which is ultimately what it’s all about.