Retrospective meetings are a great occasion for generating insights and ideas to improve workflow efficiency, that can be tried and tested straight away. And whereas the lion’s share of all the improvements brought up at retros make sense to use for a particular project, time and team only, from time to time retro discussions lead to solutions that can be adopted on a wider scale and become best practices eventually.
In this blog post, we’ve collected conclusions and improvements that we came up with at retros once and then successfully transitioned them to other teams and projects. We hope they come in handy for you as well.
#1
Problem: Neglecting Scrum ceremonies
Solution: Fixed timing for meetings
Everyone knows how important Scrum ceremonies are. But when routine and task overload swallow us, we tend to cave in to time or clients’ pressure. At first, team members innocently agree to postpone the meeting till tomorrow morning, then – postpone it for the day after, then – they decide it can wait till Monday, then – realize the meeting is no longer actual, so better skip it at all…
We’ve been in that situation, and when we finally managed to gather for a retro, we realized how counterproductive such behaviour is. Instead of fixing issues that don’t let the team to accomplish tasks in time, we let them happen again and again.
To avoid this we’ve agreed on a fixed timing (convenient for everyone) for Scrum meetings that must be respected no matter what. Even if a Scrum Master is sick, a Product Owner is at the customer’s meeting and a lead developer is on vacation – still the rest of a team can get together.
In case of even a slight deviation from the agreement, we get back to this discussion and renew our vow of fidelity to Scrum ceremonies. This appeared to be a good practice that we implement for every project now.
#2
Problem: An issue is hard to find in the app
Solution: A ticket naming convention
Such a small thing as a rule for naming tickets can be a substantial time-saver. This idea came to us at one of the retros when programmers complained about having a bad time while searching for a ticket issue in the jungle of the app.
To find the issue faster, we introduced a ticket naming system which looks like this: “ticket number + location path (application module -> subpage/tab/pop-up name ) + issue description”.
EXAMPLE: NSX-182 Admin Panel – Users Management – Create User pop-up – avatar uploading error
Other teams picked up the idea which later became a common practice within the company.
#3
Problem: Ticket-related information communicated after planning is getting lost
Solution: Keeping information in one place
In the ideal world, tasks are described once and for all at the planning meeting. In reality – if the task is rather difficult or wasn’t defined properly in the beginning, the discussion around it might continue long after the planning meeting, letting further questions, clarifications and explanations grow around the ticket like moss on a tree. If you don’t keep track on it, things get messed and important data gets lost somewhere in the chat, private conversations etc.
So the next small but nevertheless important improvement we got thanks to retro discussions is a rule on how to keep all that info related to a particular task in one place. We’ve agreed to add additional clarifications as comments to a task. This way we have all relevant info in one place just next to the task description. Just like on the picture below (sorry for blurred parts, we couldn’t disclose all the details of our secret project 😀 ).
#4
Problem: Unclear/difficult tasks require a long discussion during planning, making it unproductive
Solution: Allocated time for task refinement before planning
The problem described above also got us perplexed on how to make sure all details about a newly introduced task are clarified during the planning meeting and how to do it efficiently.
We tackled this by setting up “a backlog refinement” phase for the team to review tasks and prepare questions for the planning meeting when needed. Such “backlog refinement” takes place once per Sprint and is facilitated by a scrum master, who ensures efficiency of this additional phase: checks out if it’s really needed, picks only “difficult” tickets, involves only team members concerned and so on. Such approach also gives a Product Owner time to find correct answers, instead of making them up during planning.
#5
Problem: Getting lost in a backlog during task overload
Solution: Use the space wisely to unload a backlog
While trying to adapt Scrum to our needs rather than following the methodology blindly, we keep experimenting with a backlog when there is a way to use it more effectively.
So, for example, when a backlog is overloaded and additional important tasks pop up that need to be discussed/estimated at the next planning meeting, we create a special board for them (we call it “Priority tasks”) not to confuse them with the others.
You can do that by using whatever you find convenient in your situation and in regards to the tools that you use. It can be a column, board, bucket, or even a field in a ticket – anything that separates and visually distinguishes tasks with different priorities. A certain level of flexibility when it comes to arranging a backlog appeared to be very handy.
#6
Problem: No timely feedback on changes that require further amendments often
Solution: Share regular feedback on daily
A classy situation that causes a lot of frustration is when programmers are working on software elements that need testing and further amendments often, but there is no timely feedback from the client’s/product owner’s side, and things get stuck.
To avoid such dependencies we add an additional point to daily devoted to feedback exchange. This way we achieve a constant feedback flow needed for accomplishing this kind of tasks with no nerves and distractions within the team.
#7
Problem: Lack of team morale, demotivation
Solution: Feedback
Providing team members with feedback regarding their work is a necessary part of retrospective meetings that magically affects team’s morale and motivation. By feedback we mean not only praising a team for big achievements or admitting big failures. Even a small thing that might seem obvious and not worth mentioning, in fact, is WORTH MENTIONING. For example, informing a team if deadlines were met or not. It’s easy to spot (if deadlines we set up and communicated properly earlier, of course) and has a big impact.
Besides, we try to look beyond the project environment and praise your team members that do a good job despite some technical burdens/exams/sick leaves etc. Understanding and compassion are key to boosting your team’s morale.
…On this positive note, we finish our flood of thoughts for now. If you have other tips for improving agile workflow, feel free to share. We’ll keep you posted on our further findings too.
