No doubt -
From a developer's perspective, smooth, well-matched team processes are crucial for successful product development, making teamwork easier and helping focus on more critical issues.
But what if some processes could work better and should be revised?
Well - you can take matters into your own hands and suggest solutions!
In this case study, I will guide you through changes I proposed and implemented with my team to make our work (and life) easier.
From presenting the ideas to the team to the final execution, this piece gives you tried and tested tips to improve processes in your product development team.
Keep reading for more!
Introduction
When I joined Tidio, I noticed that my teammates struggled with a few process-related issues. We had been a relatively new team, so many things were still under construction.
The team regularly delivered business value, and teammates collaborated to achieve the best results. However, the processes were still a little chaotic. We had a structured refinement meeting, but it was far from perfect, and the predictability of task delivery in sprints was quite mysterious.
We all felt the need for improvements to make our work more efficient.
As a huge fan of well-designed processes, I decided to take care of it, dig deeper to understand the problems' backgrounds, and finally propose solutions we could apply.
Luckily, at Tidio, constant changes and improvements are more than welcome, and I had all my team on board. Shortly after the team's discussion, I put my plan into practice, starting with the evolution of the refinement meeting.
Improvement #1: Refinement Meetings
Refinement is a collaborative process that involves the entire development team and the product manager/product owner. A practical refinement should have:
- agenda
- timebox
- action points
- key takeaways
What did we struggle with the most regarding our refinement meetings?
- The Product Manager was the only owner of the agenda
- We didn't have one source of truth for the agenda, action points, etc.
- There was no one in charge of the course of the meeting in advance
- Sometimes we only discussed topics without moving things forward
The first step to make a refinement process more effective was involving each team member in developing the refinement agenda. Why?
Cooperation in creating the agenda between a product manager and engineers gives everyone space to report the most critical issues for them. Moreover, it reduces the silo effect by increasing engagement and ownership among the team members.
How to implement the improvement?
Follow the most straightforward path - start by explaining your idea step by step!
In my case, I met with our Product Manager, Piotr Cygan, and described how a refinement meeting could look based on the above-bulleted list and how it is essential to create a refinement agenda with the engineers. Then, we discussed it with the rest of the team at the retro meeting, and voilà - we all agreed to do refinement meetings this way.
As simple as that!
In the beginning, sometimes I had to remind my teammates to add points to the agenda, but after one month, it was no longer needed - we all picked up the habit. Currently, we have the list of refinements meetings sorted by date from the latest to oldest, which you can see below. Before meetings, we create a new page with the agenda, which we all contribute.
TIP: When you want to sort out your files, documents, presentations, pages, etc., start the name with the date in the format: [YYYY-MM-DD]. This particular format is easy to sort by string (sorting by the string is equal to sorting by the date you declare).
Improvement #2: The Sprint Sheriff Role
The next improvement I proposed to my team addressed the classic problem of taking responsibility and consisted in introducing the Sprint Sheriff’s role to the team meetings. My previous company designed and used this method, and I saw how positively it impacted our teamwork.
Let me show you how the Sprint Sheriff role works.
The Sprint Sheriff is responsible for facilitating sprint meetings and caring about the refinement agenda, action points, and notes related to the meetings.
The team chooses the Sheriff at the beginning of each sprint - each time someone new steps into the Sheriff's shoes. The changing role has a positive impact on ownership because, after being a facilitator, everyone understands how critical engagement is in meetings.
How to implement the improvement?
I introduced the idea during the meeting and then prepared the short definition and responsibilities in Notion. Next, I proposed that I be the first Sprint Sheriff in the next sprint to show what it is all about in practice. Leading by example works excellently and is a great way to increase the chance of process adoption.
TIP: The important thing is not to try too many changes simultaneously because coworkers could feel overwhelmed, and the chances of adopting a new process would decrease.
Improvement #3: Documentation
Before taking care of the next topic (capacity), I prepared documentation with all important agreements about meetings and the Sprint Sheriff's role to make sure we were all on the same page.
Moreover, I created planning documentation with a few points every Sheriff could use to make the meeting consistent. Over time, we actively modify the documentation, adding and simplifying points. We treat it like living documentation, which is ok because it evolves with our needs.
It could sound like a corporate bureaucracy that potentially extends the meeting time, but nothing could be more wrong! In our case, the documentation makes the meeting consistent, and the work is planned faster and more efficiently. Furthermore, we can ensure we have all the crucial points in planning!
TIP: Remember, processes are not carved in stone, so making improvements is always a warm welcome. After all, documentation shouldn’t be the goal per se.
Improvement #4: Capacity
The process capacity calculation is well-known in the IT industry, so it wasn’t hard to explain. Capacity is related to task estimations, and a lot of people have different opinions about it. Some see value in it, and others don't. I understand both sides, and I don’t want to encourage you to make an estimation or not, but if you do, why not try to make it more helpful?
My team implemented a task estimation process before, so we started to work on "capacity calculation." I aimed to increase the predictability of the number of tasks we can deliver in a sprint. High predictability helps in planning long-term goals and makes life much easier for people responsible for the business, like a product manager.
We used experiment canvas1 as a tool to set up the experiment in a professional way.
The experiment canvas, created by Ash Maurya, is a simple way to check your assumptions into measurable experiments. Moreover, it is a great option to have an experiment record. I assumed planning sprints based on capacity calculation would help increase our predictability, and you can see below how I filled the canvas out.
We started with metrics.
We tried calculating the capacity and story points delivered for the first three sprints, and our predictability was 66%. After the experiment, it increased to 90%, which is an excellent result! The experiment showed that it is valuable for us to do this and relatively cheap (a few minutes every sprint).
Our goal is not to achieve 100% predictability. We aim for 70% to 90% because we want to balance predictability and an ambitious goal, but the most important thing for us is to deliver the sprint goal. Moreover, 100% predictability sounds like creative accounting, and this is not our purpose.
TIP: Estimation and capacity calculation can work dramatically differently for different organizations. A combination of empirical approach and measurement is the essence of a healthy organization!
Are you still with me?
Great! Let's jump into the last improvements - a product team's roadmap for a quarter.
Improvement #5: Roadmap
First, I focused on collecting some data - I observed how my team planned the quarter and how it was going with execution. Then, I prepared a simple roadmap for the next quarter based on the list of tasks designed by the Product Manager. The roadmap visualizes how our planning collides with reality and what we should resign from to deliver our main results.
- Blue cards represent sprints (in our team, one sprint is 2 weeks)
- Yellow cards represent OITs (Quarterly goals)
- Green cards represent optional quarterly goals
Looks too simple for you?
Good!
We want to have something handy so that we can come back often. Practice shows that complex roadmaps are usually... too complicated and doesn't address the team's needs.
So how does our flow look now?
Before each quarter, we create the roadmap with all planned tasks. During the quarter, we analyze it and modify it if necessary (f.e, if business requirements change).
Roadmap makes us know where we are. Furthermore, it shows in a simple way that we must give up a task when we want to add something new that wasn't planned. Just add a new sticky note that represents a task, and we immediately see that something in the plan needs to be moved because our capacity is limited by timeframe.
TIP: Visualization is crucial! Instead of a complicated discussion floating somewhere in space, use Miro, Google docs, notes, or whatever helps picture your thoughts! This approach gives a greater understanding for everyone and allows close topics more efficiently.
Conclusion
The team's work has changed a lot over time. We've learned from our experiences, drawn conclusions, and constantly improved. Thanks to all the changes, our predictability is stable; we delivered a sprint goal with high effectiveness and learned how to organize and plan our work efficiently. Moreover, knowledge in the organization spreads, and more teams are adapting the processes implemented in my team.
Huge kudos to all my colleagues for their engagement, hard work, and dedication to making our processes more effective and our lives easier!
Want to talk about this topic? Reach out to me via LinkedIn!
1 https://www.designabetterbusiness.tools/tools/experiment-canvas
