More Effective Teams
Once, when I conducted a retrospective with one of the teams I led, I asked the members to write, on a post-it note, what had not worked well that week. One of the post-its completed by the team contained the following sentence: “The vibe was not good”.
That worried me at first. Were we having a relationship problem between people? Was the mood among the team members heavy? I asked some additional questions to the author of the post-it and was surprised when the person said that there was nothing wrong, only that the vibe was not good and that had been the cause of not having done well that week.
I remember that it bothered me a little and made me stop to think about why we were doing it. Why were we investing 1 hour a week of all the team members to ask questions about what was good and what was bad in the last week?
If we go back a little bit in the history of software development we will remember that, in 2001, a group of developers published the Agile Manifesto. And, along with it, 12 excellent principles. One of them says the following: “At regular intervals, the team reflects on how to become more effective, so they adjust and optimize their behavior accordingly.”
It is because of this principle that many teams hold retrospective or review meetings, or whatever they call it. But how is it possible to know, after each retrospective and after the team has corrected several dysfunctions whether the team is becoming more effective? Should the number of post-its that appear at each retrospective decrease? Believe me, I already tried this but they never end. So how do you know if the team is “improving”? How do you know if the team is becoming more effective?
Effectiveness
Effectiveness is the ability to achieve success and produce the desired results. Every development team exists to achieve some result or strategic objective, which normally unfold in goals. And when it comes to achieving goals, teams typically achieve any of these three obvious situations:
- the team reaches all goals
- the team reaches some and others don’t
- the team does not reach the goals
Usually, in cases 2 and 3, when the goals are not reached, the retrospectives are heavy and there is a concern about the team’s performance. “Why were some goals missed? Were they beyond the team’s capacity? Do we have a performance problem or do we underestimate the difficulty of the job?” — those are important questions to ask.
However, I go further and say that in all three cases you should be aware and measure the team’s performance. If the team achieves all goals, perhaps you have a team at hand that is showing itself capable of going further and reaching even more challenging goals, or perhaps you have goals that are too low.
Probably, the retrospective is the most important ceremony to make this type of diagnosis about the team’s performance. However, if the team focuses on subjective things, talking about the climate or the “vibe”, it will be very difficult to make an assertive diagnosis and generate measurable performance actions.
You have probably heard this phrase: you cannot manage what you cannot measure. What, in fact, does the team need to improve to achieve the goals? To be effective? Do you need to “improve the mood”? Okay, it is possible that in fact, this is the root cause of the problem, but how should you diagnose this?
Don’t get me wrong, there will be times when situations will emerge that demonstrate that there is a bad relationship between the members, or a climate of psychological insecurity or animosity, for example. And it is very important that there is space and incentive for the team to discuss it and solve the problem. However, my point here is that your starting point for assessing the team’s performance, most of the time, needs to happen from indicators and metrics, and not from subjective opinions.
In other words, you need indicators that show you WHERE the team is in trouble so that you can understand WHY this is happening and WHAT must be done.
Indicators
It is quite common for development teams to track metrics such as Throughput, Cycle Time, Time to Review, etc. These are excellent metrics, but they need additional interpretation so that you can clearly communicate what the effect of staying in the current state is and what result you get when you reach the stipulated goal. Therefore, a good strategy is to encapsulate these metrics within indicators that better communicate what behavior or quality you want to stand out in the team.
Look, you will probably have to educate people insistently until everyone understands the effect of decreasing Cycle Time, for example. However, if instead, you track and communicate indicators such as Efficiency, Predictability, Speed, Quality, Agility, and Assertiveness, you will probably be taking some additional steps towards clarity of communication.
I do not intend here to explain in detail how all these indicators could be measured. But for the sake of illustration, I will explain two of them: Efficiency and Predictability.
Efficiency
When measuring Efficiency we try to ensure that we are using the resources in the best possible way. If I guarantee that a team is efficient, I can increase the flow of tasks by hiring more people, for example, without fear that I am generating waste of effort.
We measure efficiency through Cycle Time. What is Cycle Time? It is simply the time that elapses between the start of a development task by a team member until the moment when it is delivered in production.
In order to be able to define whether a team is efficient or not, a good practice is to follow the 95th percentiles of this metric, or lower percentiles if you want to start with something more flexible and adjust as the team processes become more precise. However, never use averages!
After observing this metric for some time, at RD Station, we noticed that the most efficient teams kept the p95 of this indicator below 10 days. So we fixed this as the health level of this indicator. Not as a goal, but as a thermometer.
And as we are constantly looking for more efficiency in the teams, whenever a task exceeds 10 days, we use the retrospective to analyze, make a postmortem of the task and understand what happened. We eventually find opportunities to improve our flow.
Therefore, the Efficiency indicator tells us that a team is efficient when x% of the tasks performed are completed in up to y days. Define x according to the expected performance level, and y according to the context and granularity of the tasks.
Predictability
Predictability gives us a strategic advantage. Knowing beforehand when an implementation is going to be ready allows us to prepare a launch, synchronize dependencies between teams, realign expectations, etc.
And how is that done? Asking the team when it will be ready and measuring how many times they get it right? I do not recommend it!
To be predictable, you need to decrease variability. If the team delivers 10 tasks in one week, 2 in the next, and 15 in the following one, you will never have predictability. When measuring the throughput of tasks delivered each week, you should expect a small variation, for example, up to 30%. Observing this metric, we noticed that teams with this variation, or less, had excellent predictability.
So this is another indicator that we track and observe from time to time. If variability is above the healthy point, we analyze and try to understand what is causing this variation. We realized, for example, in our context, that teams with up to 3 engineers tend to have high variability. If one of the three is absent or remains very busy for a whole day, this can affect the review cycles or can extend the time of his/her task, in a highly impactful way for the team. With 4 engineers (or more) the unavailability of one of them impacts much less on the team’s variability. So, here at RD Station, unless we are validating some concept or doing the first explorations in an initiative, if we want to have predictability, we try to compose the team with 4 engineers or more.
How do I have predictability just because the team has low variability?
Low variability allows you to look to the past and replicate for the future. If I have a batch of 50 tasks, I can tell approximately how long it will take the team to deliver, looking at their history. Predictability techniques like Monte Carlo can allow you to be even more accurate.
Therefore, the Predictability indicator tells us that a team is predictable when the throughput variation between one week and the next is less than x%. Set x according to your context, after collecting and observing the effect on different teams.
Conclusion
Understand what makes your team more effective.
Encapsulate metrics in concepts that clearly communicate your intention.
Measure.
Track.
Use retrospectives to analyze, dissect metrics and understand what caused the discrepancy. Test and adapt the process. If you do this — a rational analysis — instead of just an emotional or subjective analysis, you will be actually applying this principle of the Agile Manifesto: “At regular intervals, the team reflects on how to be more effective, so they adjust and optimize their behavior accordingly. “
And it will be making your team walk in the direction of how to become more effective each day.
Thanks to Caco for defining and evolving these indicators at RD Station.
