Ourbit

It’s an Engineering Manager responsibility to guarantee the team health measured in terms of qualities such as performance, commitment, accountability and predictability (among lot of others). However this can’t be forced by the Manager. It’s actually the team effort and its proper channelling the decisive factors for achieving these goals. Because these are goals, aren’t these?

Well, that’s an interesting first discussion. What is the real value of having these qualities accomplished? Can the company sell “predictability” to its customers? Is predictability a new application feature?

Predictability: A team quality or a team goal?

If we stand on the “product guy” shoes, we could say that predictability is a way of achieving the team goals. Even more, from the product perspective, we might think “predictability” is not even a thing (until the team is no longer predictable). But from the team standpoint, predictability is a goal itself. The tricky part for understanding this (among a lot of other confusing issues) is which one is the cause and which one the effect. This far, predictability seems to be the cause, and a new feature in time is the effect. That’s right. Predictability is a cause, hence, it can’t be an effect, can it?. Of course it can! when we analyze “cause and effect” relationships, we always need to remember that it’s all about a chain. A->B->C->…->Z. Now, let’s say that a feature in time is ~~the~~ a possible effect caused by Predictability (among other causes). And the key of this analysis: So, which are the causes for predictability (as an effect/goal)?

This long introduction is not just the effect of me being long-winded. I’m just trying to establish these 2 facts:

Predictability is a team goal (in the middle of a cause-effect chain).
The team needs to feel its own bias for being a predictable one.

Now, it’s an Engineering Manager responsibility to encourage the team to go for it, and to provide the necessary tools for this to be achieved.

Let’s jump to the story

Chapter I: A self-aware team

My team and I were having a really bad time. The roadmap was at some point between aggressive and impossible. We weren’t stopping to over-commit (and of course, under-achieve), the predictability was low and falling fast (lower than 40% several sprints in a row), and even though backups were starting to arrive, the ramp up effort was going to led us to an even worst scenario (at least, temporarily). Little by little, higher level managers started to jump into our daily meetings trying to figure out what was going on. I called up to a non-regular meeting where I was going to throw all my ideas on the table and suddenly, the unthinkable. One of the team-members asked “What’s the deal with predictability? Why suddenly is so important to be predictable? Why are we worrying this bad about commitments that are falling?”. I was astonished. I couldn’t honestly think that these questions were powered by legit doubts and I needed to hold myself back from answering to somebody that, at that moment, I thought was simply trolling me.

And luckily I did it, because that forced me to start a dialogue with this person and the entire team to discover that there was no common understanding of what we were trying to accomplish.

Lesson 1: Make sure that we are all on board. Identify that Predictability is a team goal and hence, it needs to be defined and communicated S.M.A.R.T-ishly. As said, it is impossible for a manager to achieve this goal by himself/herself. It’s a team goal, and it will become a team’s achievement.

Chapter II: Root causes

I was already an experienced manager, and had been a successful one. I knew all sort of tricks and methods to make things happen. Or that’s what I thought. I had been trying to push some ideas to the team that were, in my opinion, going to lead us to improve the way we were working (Predictability included). But for some reason, sprint after sprint I failed to make the team to implement those. “We are not even trying”, I used to think from time to time. Most of these ideas required to implement some sort of time-tracking mechanism, and it’s no news that developers don’t like it at all. Well, that’s actually not true and even a quite a bit unfair enunciate. The real “problem” is that, developers are usually smart people. If your team is not populated with this specie, you are in big troubles. Smart people trend to avoid running meaningless errands and, being honest, unless there is a good reason behind it, time-tracking is exactly that.

During the one-on-one meetings I had with the members of the team (after the “honestly-not-a-troll” incident) I focused a lot in two main topics:

Jointly define the team and individual goals clearly.
Understand the root causes that were stopping the team from achieving those (from every team member perspective).

For the second item there is an important precondition that I hadn’t mention because it was not a problem in our team (but it could be in yours): As a manager you must make sure that you create a safety work environment. Every team member should be able to reach you (and even a skip level if necessary) with his/her thoughts without any kind of fear. For example: No matter how unnatural it was for me having a team member asking “Why is predictability that important?”. I refrained my natural instinct to cut that conversation off. It was meaningful, but even if it wasn’t, it’s always a great chance to build strong and trust relationships. If you can’t accomplish this, you and your team are doomed.

As it turned out, there were plenty of possible root causes for the low predictability. It could vary from team to team, but in this case:

Lack of team behavior: Stories were being tackled by individuals, not the team. Hence, there was no interaction during the daily meetings, almost no maneuver capability for stories that were in path to not being completed, no unified design, and no knowledge sharing.
Unclear product vision: The team was not aware of the big picture, and didn’t receive the functional specs with time enough to understand those. This caused constant highly imprecise estimations.
No convention over story points: Talking with one of the devs, we agreed that a story should have been finished since it was properly estimated in 5 points which seemed to be the doable points per person during a sprint. Nevertheless, the story had not been completed. When I asked other devs about their opinion about how many story points they thought was the average per person, I didn’t receive even a matching pair of answers.
Lack of metrics: Like (almost) everything, estimations can’t be improved if you can’t measure these. And it is very unlikely that you are predictable if your estimations suck. How much time are we able to code per day? How inaccurate are our estimations? How are we doing with this story? among other questions, should be easy to answer if we want to control our capacity (first) and our predictability (then).
Tools and processes stuck in the middle: Tools and processes are great. Properly implemented can proactively avoid bugs, accelerate the development speed, assure smoother deployments, among a long list of perks. But when some tool is misbehaving, it could be a real nightmare and a devs.forEach(frustrate) statement. Nobody likes to work endlessly hours, but we all accept it can happen from time to time. It turns out that additional efforts caused by a “stupid test tool” going out of resources and becoming the biggest engineering bottleneck is not even close to be acceptable by a group of smart people. On top of the demotivating effect, how can anybody claim predictability when unexpected things like this happen all the time?

The previous one is an abbreviated version of the real one, but:

It illustrates the scenario.
It provides you with some common situations I found in other teams, in other companies.
It states a couple of easy to fix, hard to detect situations.

Chapter III: Goals driven actions

It was not a matter of knowing the answers, but asking the questions. As said, I was (and always have been) ready to jump in with my toolbox to fix the problems and make the day, when the team taught me a valuable lesson: let’s first agree on the goals and then discuss about how to get there. Once we agreed we wanted to be predictable (and why we wanted/needed it) coming up with the tools was much easier. But most important:

The team proposed some of these.
The team requested me to come up with those tools they didn’t know.

We all know how important this is, but very often, we need a great team to remind us that We are not the smartest persons in the room” and even if we were, there is no way of being smarter than an entire team. If you think you are, I have some bad news (choose the one you feel more comfortable with):

You need a smarter team.
Your team really needs a smarter manager. I bet that this is the real one, even if you choose the other one.

The goals were a chain (or a tree) of causes and effects. These goals could be grouped as a milestone: remove/mitigate the “root causes” (mentioned on the last chapter).

So, in a nutshell, we agreed on:

Urging the corresponding team to fix the issues with the tools, compromising on temporarily leveraging the additional effort required to operate.
Keeping track of the time spent in dealing with the tools, elaborating reports to help other managers to set the proper priority to this.
Having the entire team working on the same features during the sprint.
Tracking the time spent building the features (continuous, uninterrupted work per day).
Tracking the remaining effort at a task level (we were just burning down the points for a complete story). This topic deserves its own article if you have no idea of what it means. But basically remember that the “Original Estimate” - “Time Spent” is not always equals to “Remaining Effort”. Being able to detect that difference as early as possible is a great and decisive tool at the time of being predictable.
Displaying the partial progress on the daily meetings (fine granular burn-down chart).
Discussing about any meaningful deviation as soon as these appeared.

Of course this is just a summary. I can’t even remember how many details we defined on the fly and if all of these were the original actions we agreed.

Chapter IV: The “too many changes” paralysis

We were going to start a major refactor in the way we were used to working. When coding, we count (or should) with a lot of unit tests before refactoring, and we are pretty sure that we are not breaking anything. But this is different. There is not such a thing like unit testing frameworks for people.

We didn’t freeze once we agreed and made a team decision. But I can’t avoid thinking that before doing this, knowing all the work that was going to be needed to refactor the team, was a major stopper for us to even start the discussions.

I used to spend a lot of time thinking about how to articulate all the actions that were needed. While this is a good thing to do, planning could become a trap. Always make sure that planning is your tool to organize your team efforts, and not an excuse for professionally procrastinate. If you don’t know how to do this, use the old “cause-effect” framework. Think about which are the goals you want to achieve by building a plan.

In this case, planning the way we were going to proceed made no sense. But implementing all the changes at the same time would have led us to a situation where:

We were not going to be clear on which changes produced which results.
We were not going to be able to identify if some change was actually a downgrade.
Changes require a learning process. Too many changes imply learning too many things at the same time.

Never let this kind of issues to stop you. You need to start with something, measure the first results and decide based on the thrown metrics. Again, you are not the smartest person in the room. Discuss with your team about the changes to implement first, collect the data, present it during the retrospective meeting, and discuss again about what’s next.

Conclusion

At the end of the third sprint since the team started this refactor (achieved items):

The team behavior dramatically improved. Any team member was able to jump into help another one.
The team was able to identify which stories were at risk and the reasons for the delays (underestimation, issues with the tools, individual underperform).
The team had data enough to make informed decisions (start partial tests before the story was completed, jump into a different story to avoid risks).

By the end of the fourth sprint:

The team was estimating quicker and more precisely.
The product vision was shared by the entire team.
Deviations in the roadmap were being foreseen and corrective actions were being taken.

“Achieved items”->”Predictability”->”Features in time”. All links on the chain.