For those of you who caught People and Process: Chapter 1, you’ll know I’m exploring various events, behaviors, and/or actions that commonly lead to direct conflicts between people and process. As promised for Chapter 2, I’ll tackle “Big Brother”—cheeky shorthand for Agile practices and/or processes that make team members feel monitored, rather than nurtured.
Big Brother
AKA Metrics, A Cautionary Tale
While an increasing number of people are willingly populating both their homes and persons with little robots that know what we like, who we interact with, where we sleep at night…pretty much no one wants to feel monitored. At least, not when it’s not in their control.
Just like process itself, metrics are neither good nor bad. They’re just a tool, one of many to help individuals, teams, and organizations optimize performance and output. As with most tools, metrics can be wielded with precision and focus, or they can be applied broadly and bluntly, to mixed effect.
On that note: If your process is laden with KPIs geared towards quantifying team or individual performance, proceed with caution, because your team can probably feel it.
Agile, Meaningful Data
As digital product development teams have adopted Agile workflow methodologies, they’ve also embraced quantitatively-driven prioritization; i.e., using fresh, relevant data to make smart decisions about what projects to do next and how to build them. One unfortunate side effect, however, is the extent to which agile-specific metrics get used in isolation in an attempt to understand and correct issues, of both teams and individual members.
Take “velocity,” for example. Velocity is shorthand for the amount of work a team can tackle during a single Sprint. It is the backbone of true Scrum; without understanding a team’s capacity, it is challenging to plan a successful iteration. Because of its importance in the Scrum model, Velocity gets spotlighted a lot.
Higher-than-normal velocities may be occasions to celebrate—perhaps the team discovered unexpected efficiencies when working on a feature, perhaps something wound up being a lot less complex than anticipated. Conversely, lower-than-normal velocities could be cause for concern/discussion. Was the scope of a feature misunderstood and/or misestimated? Was someone going rogue and working outside the Sprint commitment? Was there a blocker that could have been more quickly resolved?
On the flip side, higher-than-normal velocities may be cause for concern. One or more individuals on the team might be stretching themselves too thin in a valiant (but, in the long run, probably misguided) effort to get ahead. The team might be overestimating tasks, whether purposefully or subconsciously out of fear of missing a Sprint commitment. Or, frankly, maybe your metrics just aren’t being consistently or optimally tracked. I’ve seen work that was actually done in the last iteration, then not be marked as done until the current iteration, purely because someone forgot to do their due diligence.
On a similar note, lower-than-normal velocities often have very normal, very human explanations, which no amount of monitoring or tracking could have predicted or mitigated. People get sick; family emergencies happen; vacations are hopefully being taken from time to time.
(Brief aside: teams tracking velocity should be striving for a consistent velocity. Frequent swings in one direction or the other are almost always a sign of process, team, or management immaturity).
The points is: being able to gauge how a team is doing is wise, but relying too heavily on only a program, spreadsheet, or suite of metrics to tell you that is dangerous. Those types of numbers only ever tell part of the story, and usually not a whole lot more than “things look great!” or “things…uh, do not look great.”And, at a high enough level, they make it much too easy to lose sight of the fact that a team isn’t a group of resources and functions plotting points on the burndown; it’s a group of people and talents working to build or accomplish something together.
And herein lies the true tragedy of an excessively monitored team: The people seeking to gain greater understanding through all this data overhead…are usually getting just the opposite.
Nurtured vs Monitored
So, how does one avoid making employees or teammates feel monitored, but while staying informed? There are a few bits of advice I can offer.
First of all, remember—metrics are neither good nor bad, it’s all in how you wield them. Personally, I look at them as cues for conversation.
Let’s return to my earlier example of velocity: a higher or lower than normal velocity in a given iteration could have so many causes. It’d be doing your team a great disservice to simply report “velocity was higher than normal - the team got more done!” Or, “velocity was low…we just missed the mark this Sprint.” To me, the fact that velocity is somehow aberrant doesn’t mean a single thing on its own, only that conversations will help understand why.
And that’s how I view any meaningful KPI in the world of Project Management: If something seems off, the Project Manager should be leading conversations to uncover the root cause(s). Because it is entirely possible there’s corrective action that can or should be taken. Reacting blindly doesn’t help anyone, though.
Want to know how a team or individual is doing? Ask them. Want to know how a team or individual is performing? Look at their work product.
Mastering the Scrum
It is also imperative to remember that nowhere in the job description for Scrum Master or Project Manager does it say “Must be able to track coworkers every movement.” NO. Scrum Masters and Project Managers are part of the team as much as any Engineer or Designer, and if anything, are expected to encourage and carefully foster team cohesion. No sane person will take leadership cues from someone whose sole purpose seems to be quietly tracking and providing reports to management about team or individual performance, especially when the team might not even be privy to that data.
Which brings me, at last, to my final point: If you need metrics, decide what is important to you, your team, and/or your organization in terms of KPIs, right up front. Beyond deciding what you want to track and why, the most important thing here is to be as open and transparent about that process as you can.
Ideally, employees and teams will help define how they’ll measure their own successes, then challenge and expand upon those definitions as needed to reach consensus. But a team or individual being measured should at least get to know how and why. Otherwise, you risk not only people feeling vaguely spied upon, but also unfocused. How’s a team supposed to succeed if they don’t know how success is being defined?
At the end of the day, having some way to consistently keep a pulse on your teams and projects is important. There are just a whole lot of ways to do that, and I’d argue communication is by far the most effective.
Metrics can certainly help identify and focus when, where, and what communication needs to happen; but the key isn’t having numbers, it’s having insight and conversations. And those conversations will go a lot more smoothly if your team isn’t surprised by the trove of data you’ve been collecting.
DockYard is a digital product agency offering exceptional user experience, design, full stack engineering, web app development, software, Ember, Elixir, and Phoenix services, consulting, and training.
