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.
That’s why I recommend auditing your agile process every six months. It might sound daunting, but everything you need boils down to four questions you can fit on a standard 3×5 notecard.
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 superawesome 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.
Question 1: Rate our standups
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 standing up in a stand-up). (I’ve written more about standup failure and other signs of faux agile ”Don’t fall for faux agile.”)
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.
Question 2: Rate our stories
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.
Question 3: Rate our ability to get things done
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 it’s delivering, or what its velocity is.
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.
Question 4: Rate our retrospectives
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.
How to score
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 the 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 independently. 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.
This article is published as part of the IDG Contributor Network. Want to Join?
