Fear is listed first in a list of top 10 mistakes made by new agile teams, compiled by Rally Software (recently acquired by CA). However, there are many kinds of fears, and not all of them can be addressed simply by suggesting that management adopt a philosophy of trust and transparency. There are fears involved with change, with choice, with failure, and with reputation.
In Agile and Lean Software Development, a LinkedIn group, a heated discussion labeled "Too scared for feedback?" debates the fears an agile team faces when pressured by the CEO for an "alpha release" before the team feels the code is ready. Agile wisdom would dictate that management trust the team with this decision, but at what cost? Doesn't agile wisdom also suggest transparency and frequent feedback from customers?
The first mistake: Not getting feedback at sprint reviews
There are a few things to note about this scenario before jumping in with an opinion. The description of the issue starts with, "A certain team has been working on a piece of software in sprints for about a year and demoed ("I show, you look," no interaction) in every review meeting."
I'd agree with the many who weighed in saying that the lack of feedback or interaction at the sprint reviews is a problem. The good news is that the reviews and demos have been happening. The question then becomes: Why has there been no feedback or interaction from the stakeholders? Were they disinterested? Was there not enough time? Were they not invited to give feedback? Were the right people in the room?
The title of the discussion post, "Too scared for feedback?" presumably refers to the feedback that'll ultimately be received from the alpha testers when code is released to them with known "quirks." However, is a more general fear of feedback hindering the team from gathering early feedback after each demo?
Giving and accepting feedback after each sprint and then taking action on that feedback are critical activities that agile success is dependent upon. It's often said that in order to squelch fear, management must show trust. However, that doesn't mean management should keep quiet about their opinions. In this case, it's not clear why no feedback was given at the reviews. However, whether good, bad, or neutral, frequent feedback needs to be gathered from the stakeholders.
How to build skills around giving and receiving feedback
One of the best techniques I've seen to build skills around the art of giving feedback came from Toastmasters International, an organization that teaches and allows participants to gain practice with public speaking skills. After each speech, a public "evaluation speech" is given. There's a very specific pattern to an evaluation speech, which includes recommendations for improvement sandwiched between points of praise.
Though following a prescribed pattern may seem a bit unoriginal and lacking in authenticity, the requirement for specific areas that could be improved is expected and thus isn't feared or taken as unsolicited criticism. Couching any perceived criticisms with positive comments also helps keep the recipient from feeling deflated or discouraged. Instead, the recommendations are viewed as helpful ideas about how something good can be even better.
I've followed this basic pattern?aiming for at least two positives for every constructively critical point?whenever giving evaluations throughout my career. However, I remind others, especially during retrospectives or times when we're aiming to improve, that the constructive feedback is critical.
Receiving critical feedback without angst is a harder skill to teach than delivering it. If someone lacks diplomacy or is overly critical, it can be easy to become defensive. However, if constructive feedback is specifically being requested, then it's much easier to accept and to realize that the objective isn't to criticize but to improve. It's important to discuss the feedback to ensure there's a common understanding and agreement, not only on the specifics of the feedback but also on any actions that should be taken for improvements.
In order to build these skills and to get that important feedback, every review should include gathering feedback from the stakeholders as part of the process. If the stakeholders are all quiet, the team needs to take an active role in seeking out opinions, perhaps requiring that each person have a turn to give their feedback before the meeting ends.
Delivering code early
Providing a demo and being transparent to internal stakeholders is one thing, but delivering software to customers with known problems is an entirely different thing. Though agile practices promote early delivery, they also promote quality and working software. If you deliver low-quality code, you risk hurting your reputation. On the other hand, you also risk your reputation by delivering too little, too late. The key, of course, is to deliver high-quality code fast. Gathering quality metrics along the way will help a team know if they're on track.
In the scenario we've been discussing, the CEO is pushing for an alpha release to a "select few alpha testers," but the team knows of "quirks" and wants to defer the launch until those quirks have been resolved for fear of "a possible negative backlash." The "quirks" have been well documented, but they aren't bugs. They're either unusable components that have third-party dependencies or they're unfinished functions. The CEO understands this and is willing to take responsibility but feels it's important to show something to the investors in order to get further funding.
The common advice from the readers was to set expectations with the alpha testers; in other words, to be transparent. Though most advised the team to move forward into alpha to gather the feedback, others felt it might be a mistake to deliver code that's known to be nonfunctional.
As in most cases, there isn't a one-size-fits-all answer to questions like these. It's important to understand the various risks associated with delivering with the quirks versus delivering once they're fixed. One suggestion was to prioritize each issue and come up with a plan to fix it with the stakeholders. Being transparent as well as empowering everyone to contribute to a solution when there are issues will help reduce fear.
Ask "why" to get to the root cause
A common technique for discovering root cause is to use the "5 Whys" approach, in which the question "why?" is asked iteratively to drill down into specific reasons for a problem. In this scenario, one question that was asked repeatedly in the discussion was, "Why is the team afraid of feedback?" Though they may be afraid of the negative impression left by delivering before the code is complete, are they aware of the risks involved if they lose funding?
Any team is going to experience issues, and that's why gathering feedback frequently is so important. Having those issues exposed early allows the team to ask "why" and come up with ideas about how they can address those issues.
Though it's easy to play armchair quarterback and offer advice about what this team "should have done" or "should do" going forward, it's the team and stakeholders who ultimately need to figure out their next steps.
The point here isn't to find the right answer for this team but to be aware of strategies for your own teams about how to best gather feedback, address fears, remain transparent, and continually improve.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
