Tip 1: Build a ticket lifecycle to promote feedback culture in development team
This tip may not apply to small startups, but you want to formalise how development feedback is given. The most obvious reason is the return on the investment into less experienced specialists. The more structure you bring to feedback, the better odds of learning reinforcement you get.
There are multiple ways to formalise communication in software development team, and some might suit you better than others. We found that enforcing a ticket lifecycle helped improve feedback in development teams that work with us. Once different people have stages that they should move an issue along, they will communicate with whoever it takes to do that.
Below is a portion of the Scrum board for our website. Note the columns: devs can quickly see the tasks that were rejected by either Change Owner or the QA team. Everyone on the team can also see when a feature is ready to be merged into production.
For us, the best thing is that we donāt limit devs and testers in how they collaborate. They can review a pesky bug on a screen sharing session, look for everyoneās input on a dev/QA chat, or just leave a comment in our ALM. Most of the time, it just feels natural to communicate in the ALM if you will have to change the ticket status there.
āOptimism is an occupational hazard of programming; feedback is the treatmentā.
Tip 2: Give more than just performance reviews
In the previous paragraph, feedback was used to describe day-to-day agile development team communication. Feedback in software development, however, does not end with you asking devs to retest certain requirements.Ā
Performance reviews are a major improvement driver in software development. The nature of the work dictates that even CTO might have seen the code of a particular dev, so survey responses from colleagues are substantive like nowhere else. Letting specialists know how they have done, formulating realistic improvement items, and discovering long-term career goals is how you make colleagues grow.
Meeting halfway, retrospectives are a great type of feedback session too. Usually done after every sprint or milestone, they help your team raise concerns, offer workflow improvements, and implement them at a pretty rapid schedule. After observing how well retrospectives go for our devs, our creative team adopted them as well.
In our recent video, we delved deeper into this recommendation and explored it extensively.
Tip 3: Request feedback on more than your line of work
As a developer, itās not uncommon to feel that everything either helps you to get your code done or blocks you. Your skills and helpful colleagues bring you closer to the finish line; externals that you need to complete your work and/or review it get in the way. Even with little malice, it can become a them vs us mentality really fast.Ā
It goes without saying that you should not only provide feedback to a less experienced employee, but also request it. Small annoyances, growing frustrations, and unvoiced issues will all guide you to a better environment. The scope, however, does not end with the development team.
Non-technical stakeholders can have various misunderstandings with devs. The product team may struggle to communicate their vision for a feature clearly to avoid changes in implementation. Copywriters may try to request devās time for an interview but keep getting denied by the managers. Cross-development interactions are a major feedback point, too.Ā
With over 20+ years in collating, aligning departments has been a major part of our work. This is why we prepared a testing strategy template that specifically covers the involvement of non-QA specialists in the process. Find it below, you will never want to lose it.
Get a testing strategy template to give your team the ultimate QA reference
Tip 4: Keep feedback actionable
While there are mental health and consequently performance benefits to getting things off your chest, your colleague may not share the enthusiasm. You need to voice positives and negatives, but the criticism should come with a track for improvement. Sometimes, it is indeed better to let employees look into a solution first. The key consideration here is not to leave people with tough problems that they acknowledge, canāt solve, and seemingly canāt request help for.Ā
Naturally, this tip does not apply as strictly to positive feedback. We are wired to love hearing positive things about ourselves, and you donāt need to be as action-driven about it. Even then, your colleagues would still appreciate further ideas to make you praise them again. This is another example of uplifting feedback in a development team creating an effective work environment.Ā
Tip 5: Donāt make things personal
Making mistakes in providing feedback is common for any industry but also beyond work. When we criticise something about someone, awkward wording can easily make it a hurtful statement about the person. Itās nice to be called cool because your feature implementation was cool, but what about the opposite?
The rule of thumb is to avoid you-statements, much like family counselling asks to avoid them when talking with family. Donāt say, āYou cost us 2 extra QA hours this sprint with that code mistake. Instead, detach the fact from the person, āThe coding mistake from your last sprintās workload cost us a couple of QA hoursā. Small change, big difference in perception. You will have a hard time getting through with future feedback, as it is human nature to get defensive after hearing the less suitable wording.
You could actually borrow another page from counselling books and go to i-statements. Talk about how you wouldāve tackled a problem, not how short-sighted your colleagues were to not spot the same route. āResetting AWS is the first thing that I would have doneā sounds much better than āYou should have reset AWS before any other troubleshooting stepsā.Ā
Tip 6: Stay consistent or stand aside
Especially as a young developer, few things hurt as much as inconsistent feedback. You come to the workspace ready for learning, you complete a task, and then you get criticism that is so wildly different from what you heard last week. How does one follow advice if it seemingly changes every day?
Luckily, if development documentation is up to date, you will be able to reference it in your feedback. It also helps that your employees can point you to documentation as well to hold you accountable. If you ended up requesting something different, itās probably time to revisit documentation rather than dwell on how this one feature will be implemented.
Consistency also applies to how you provide feedback. Do not delay it unless there is something truly urgent to do instead. Do not make it a half-hearted affair if youāre in a time crunch but can give more time later. When feedback gets scarce, employees become discouraged to seek it and may even start thinking that it is their fault.
Conclusion
Fostering a good feedback culture starts with putting in conscious effort. Once you commit to it, staying consistent and working on delivery will get you well over 80% of the way. Great feedback encourages colleagues to improve their performance, work together, and actually be happy at the end of the sprint.
If you are looking for a collaborative software development tool, aqua cloud has you covered. It is an AI-powered solution to implement requirements, test them, and run advanced analytics. Custom workflows and the discussions functionality make development open, convenient, and transparent.
Try the best issue tracker for feedback and collaborative work
