7 Workflow Improvements That We Came Up With At Retros

7 Workflow Improvements That We Came Up With At Retros
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.

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.

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.

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 :D ).

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.

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.

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.

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.

Related articles
What works well and what you should be aware of while working with TensorFlow. READ MORE
Learning methods go through tremendous changes. Right after the e-learning and video tutorials boom, another technology emerged that promises to revolutionize the way we share information. Find out why there is such hype around augmented reality and how it can transform your business in terms of training and knowledge retention. READ MORE
For tech professionals, staying up-to-date is more than a natural curiosity, it’s a must. How to be wired up without spending too much time on it, and what blogs to follow - further in the blog post. READ MORE
Smooth collaboration and effective project management are crucial for software development. No wonder there are so many approaches and tools designed especially for software project management. And whereas there is no single cure-all tool, you might find our experience in using the following tools helpful! READ MORE
Inspired with the idea to improve the reliability of computer object detection and eliminate the necessity to handle it manually, we initiated a proof-of-concept project on automating microbiological analysis with the help of deep learning for one of our clients. After few rounds of the meticulous testing, we are happy to share the outcomes. READ MORE
The role of a CTO involves constant challenges. And a product release doesn't mean a retirement for a CTO, but a new mode of working and new issues to be prepared for. Check out these top 5 challenges that every CEO of a growing company might face and our tips for handling them. READ MORE
When there are so many examples of tremendous success done by pioneers of certain technologies, the fear of missing out becomes quite reasonable. Don’t miss out two biggest trends of 2018 (from our perspective) and learn how your business can respond to them by reading this blog post. READ MORE
A university-industry partnership is a win-win deal that gives a competitive advantage for both parties. Read more about our experience of collaborating with a university and how we benefited from it - in this blog post. READ MORE
The transition to Scrum is an exciting learning experience for everyone involved. However, it might be overshadowed with human skepticism and doubts. Read more to learn what challenged to expect during the Scrum adoption and how to avoid them. READ MORE
Changing the way how people used to work might be quite a pain. And doing it by introducing Scrum is not an exception. If you’re considering to adopt Scrum or started the transition process already, this blog post is for you. READ MORE
When development becomes painful and time-consuming the debate over “what to do now?” starts. Fueled by developers’ claims “the code is a mess”, “we can’t work with the legacy code”, “let’s rewrite it” from one side, and the business trying to solve the issue less dramatically - from the other, the discussion seems to be never-ending. This blog post will guide you through potential pitfalls while deciding whether to improve the existing code (by refactoring, running unit tests etc.) or rewrite it from scratch. READ MORE
Bringing together people to work on the same project from different locations is becoming a common practice. But distance and lack of physical connection take its toll and may bring impediments to the workflow. After 7 years of experience in setting up distributed teams using Scrum, we cut our teeth on the possible pitfalls and collected several rules to make things work... READ MORE