Regrouping With the Help of the Data
25 October, 2021
A retrospective is a powerful tool for a manager to leverage. You hold them every two weeks or so; they allow you to look back over each sprint in order to determine how well the team did. You have a chance to identify inefficiencies that may be holding your team back.
If these processes are not yet in place, you need to take the initiative and instate them yourself. There are more than a few ways of doing this, even for a very new manager.
For example in each session, every member of the team may be asked to come up with one thing that they feel is working well, one thing that they do not think is working, and one suggestion. The suggestion will usually be some proposal on how to solve the “bad” that the person brings forth.
The entire group then has a chance to discuss all of the different ways that the “bad” can be addressed. Any processes that are broken will be brought to light immediately. Nobody knows when something is missing like the team themselves.
You can schedule regular checkpoints throughout each sprint to prevent problems from getting too far ahead of the team’s ability to manage them.
My current team’s work is very data-driven; they make every decision according to what we see. We wanted to get an idea of how good we were at accurately predicting what we can do over the course of a sprint, so we did a little bit of homework.
You can begin by figuring out how many days each member of the team has available during the sprint, taking any off-days, travel days, or days that are typically stacked with meetings into account. Once you’ve got the total number of working man-days at your disposal, you can calculate the total number of complexity points that can be taken on in a single sprint.
Forty working days across your entire team may correspond to ten points of work or thirty; it all depends on how the points are defined. If you plan to tackle thirty points in a single sprint but are only able to handle twenty, ten of those thirty points are in dispute. Capturing this data over multiple sprints will allow you to start predicting the accuracy of your team’s grasp on the exercise.
If after four or five sprints you find that thirty is just too much, reducing this number may help you plan your weeks more effectively. The same goes for the opposite scenario. If you plan for thirty and consistently are able to take on forty, your team is ready to take on more.
This is a really great way of doing things; it is data-driven and it prevents people from becoming over-encumbered. You do not want to be this dictatorial person. As a leader, you need to have a nuanced understanding of what it actually takes for the team to achieve what they set out to do.
- Engineers respond well to a data-driven approach to mapping out the road ahead. It is one great way of getting your sprint-planning routine off of the ground if Agile is new to your company. The data is there to prove you right or to prove you wrong. Be open-minded with the data in front of you. Trust it to lead the way.
- Carrying this way of thinking through to each quarter allows you to extrapolate this data in order to ascertain the feasible OKRs that the team can take on. If a PM asks if a feature can be released by the end of the quarter, you can use these tools to tell them exactly how long what they want will take. The velocity of the team, the nature of the work, and many other factors will all play into this final estimate.
- As a former engineer, I feel as though I have enough of a background to make some of those necessary assumptions while planning this work for others. For any manager, measuring things will always be very important. This removes the sense of hierarchy that may result when decisions are being passed down from above without any input from those on the ground.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
Neha Saha, Manager, Software Development Engineering at Workday, illustrates the challenges of obtaining a position in management with no prior experience and the confidence it takes in order to succeed.
Manager, Software Development Engineering at Workday
Anuj Vatsa, Engineering Manager at Carta, describes his journey of becoming an Engineering Manager and shares some tips for easing into this new role.
Engineering Manager at Carta
Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.
Head of Frontend at Doist
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.