The Art of Product Management
The phrase “There is an art to this job” usually means there is something opaque about it that can’t be easily defined.
By:
You check your blood pressure, tire pressure, and your stock prices. But when was the last time you performed an agile health check with agile retrospective questions? Even experienced agilists can fall into bad habits and it’s important to catch them early by asking the right agile questions.
During your next agile standup meeting, ask your team to answer each of the following agile retrospective questions with a five-star rating scale. Five stars means you have a super awesome agile process, and one star essentially means you have no agile methodology 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 and developing agile retrospective ideas. Here, we will cover the 4 essential agile retrospective questions for agile standup meetings.
The way I sometimes explain this question is if someone were selling our agile standups on a website, would the team buy them? A low score on this agile question suggests that your agile standup meetings 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 agile retrospective question tend to use agile standup meetings 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 agile user stor. 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 agile question in an agile team health check 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 agile methodology user 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 agile story. If your goal is to deliver business value, your effort is measured in agile 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 in an agile sprint retrospective. Low ratings on this agile retrospective question could mean several things. The team may be struggling with a distracting work environment.
Or they might have too many meetings. Agile standup 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 agile user 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 agile question are struggling with basic principles of Agile and agile principles retrospective. 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 agile story points they’re delivering, or what their velocity is.
If your goal is to deliver business value, and your effort is measured in agile 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 agile retrospectives for back-slapping and high-fives. Everyone loves praise. But the goal of 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 agile 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 agilequestion probably mean that you need to make agile retrospectives more businesslike, and save the applause for an after-work celebration.
When scoring agile retrospective questions, approach it the way you would planning poker. Discuss any discrepancies you might find. If someone is giving an agile 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 agile retrospective questions may be simple, but they can uncover significant agile health issues before your team goes far off the rails, and act as an agile health check template. If you take the time to do regular agile auditing, you’ll dramatically improve your agile development process, the balance of the team and deliver more business value, which is ultimately what it’s all about.
Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.
.svg)
