The Agile Angle

The Nexus of Agile Practices, Lean Principles, and Common Sense

Posts by author David Babicz

Agile Team Reward Systems

January 30th, 2020

“You Get What You Measure.
And what you measure indicates what you value.”

As I post this, the Super Bowl is this coming weekend. I’m a long-time football player (a long time ago), and football season is still my favorite time of the year. I often think back to my last two years playing in high school, and how really true it is that “you get what you measure.”

In those two years, we had two very different head coaches. My junior year, the head coach gave out helmet stickers for everything. If you scored a touchdown, you got a sticker. If you scored the extra point, you got a sticker. If you made the “hardest hit” of the week, you got a sticker. If the long snapper and holder didn’t fumble any snaps during the game, they each got a sticker (but wait, wasn’t that their job?). It went on and on and on. And as the season wore on, some helmets became just covered with stickers, while others were pretty bare.

My senior year, the new head coach (an assistant the previous year) changed all that. Nobody got any stickers unless we won the game. When we won, every player on the team got one sticker, period. The only other stickers were given out by the head coach: two or three each week, to seniors that exhibited effort above and beyond the call and served as examples for others to follow. It came the night before the game, along with a handwritten note from the coach about how great you were doing and how inspiring you were to others. It was very special to get one…I still have mine in a scrapbook.

The interesting point was that these two very different rewards systems, with essentially the same team, yielded two very different sets of behavior. In the individual reward model, the game-within-the-game became how many stickers you had. It spawned individual focus, jealousy, backbiting, and hero behavior. All of these were counter to teamwork, pulling on the same end of the rope, etc. “I’m about to get tackled, but why should I pitch to my teammate? If I do, he might score and I want the glory myself.”

With the team reward system, it became about the team winning, not about individual accolades. If we work together, and accomplish the goal, we succeed. WE succeed. Together. Or, we fail, together.

In Agile, we want to foster this same team-based cohesiveness. We want the team pulling together, looking for what they can do to reach a common goal. There should be no such thing within an Agile team as “I succeeded in my iteration, but you failed in yours.” But especially here in the United States, we have built compensation models based on individual performance: reviews, raises, bonuses are all based on individual achievement. Cultural analysis also reveals this: in Geert Hofstede’s Five-Dimension analysis of national cultures, the United States rates extremely high (91%) in orientation towards individual achievement. Certain European cultures show an affinity for group achievement, and Agile coaches working in Europe report it being much easier to foster a team-oriented mindset.

When your Agile team members are under individual reward models, variations of those same issues I saw on our football team will show up. Hero team members can put the project at risk trying to crank out work they can claim as their own, without communicating and coordinating, working on tasks that aren’t visible. Struggling team members can hide their challenges, fearing being called out and losing out in their performance review rather than asking for help. Backbiting and jealousy among team members can cause them to avoid helping another team member to “save themselves” (watch the scene in Titanic when the ship first sinks). Team members will not have the spirit of chipping in to do whatever is needed to succeed, but instead you may see the “it’s not my job” behavior. (If you’re looking for behavior patterns we want in Agile team members, I wrote about that in my blog “Are Your Teams ‘Wired for Agile?'”).

Changing your rewards system to a team performance-based system will be an organizational challenge, and not one that can be handled at the team level. As an Agile champion in your organization, you should need to engage management and Human Resources to look at structuring a model that will foster the kind of team behavior we want. Here are just a couple suggestions to consider:

  • Iteration Success Rates: Team members all receive the same bonus based on successful iteration completion rates. You might set a standard that if a team successfully completes X% of their iterations in a given timeframe, each team member gets a bonus.
  • Non-monetary compensation: When money is the only motivator, you will keep cohesion and loyalty only as long as the pay rate stays “high enough.” But people are motivated by more than just money: consider offering paid training or conference attendance to advance desired skill sets, or free time, or team outings to increase camaraderie.
  • Team-based reviews: Reporting managers are likely not on the ground on a daily basis with their reports, when those reports are on an Agile team (in fact, it’s a dysfunction if they are). As such, they aren’t the best positioned to provide feedback from the trenches. But fellow team members are. Gathering feedback on every team member from every other team member can give managers a good, holistic view of how each person is contributing to team success. The large sample size can also help smooth out backbiting that can occur between team members that don’t get along and may snipe each other in reviews.
  • Team-awarded “MVP” Awards: Much as my senior football coach did, award exemplary performance awards to team members that go above and beyond the call. But instead of the manager deciding who gets these, have that decision solely in the hands of the team. Being voted an award by your peers will often mean a lot more than by a committee or manager.

These are but a few steps you can take to foster team cohesion and a teamwork mindset. I’d like to hear what others come to your mind.

Just remember to stay away from tons of helmet stickers.

As always, I welcome your comments.

The Psychology of the Sign Off

November 14th, 2013

 

“Make sure you get the Sign Off.”

That’s a common mantra in any business. The sign off is pursued and valued like it’s some kind of ancient idol. (The opening scene from Raiders of the Lost Ark comes to mind.) We take it for granted that it’s a necessary part of the processes we use to produce product. But what does the sign off really mean? When you get that signature on the document (or give yours), what is the sign off saying and what expectations are being set?

Webster’s online dictionary defines “sign off” as follows:
“to approve or acknowledge something by or as if by a signature <sign off on a memo>”

Hey, that sounds pretty innocuous. I showed you something, or did something for you, and you’re just signing a piece of paper that says you saw it, or I did it. But the benign nature of that thought belies the social complexities and implications of what that sign off really means.

On one level, it’s an issue of trust. Why do you need my signature? Isn’t it enough that I told you verbally that its fine? If we worked in a world of implicit trust, that might be OK. But if you’re the one looking for that signature from a manager or client, what are the chances you would respond “yes, sure, it’s fine?” I say the chances are slim and none. If you could take it on verbal approval, then chances are:

1. The decision or deliverable in question is very minor,
2. Your organization is extremely small, and/or
3. You really DO work in an organization with a model of implicit trust (this is rare if (2) is not true).

So if we don’t trust each other enough to take everything on verbal approval, the question is why? What are we afraid is going to happen if something goes wrong?

In THAT question lies the core issue. It’s not what happens when everything goes well…when the product is delivered on time, on budget, free of defects. At that point, everyone is happy, and someone throws a party. Maybe the only person unhappy with the lack of formal sign offs in that situation is the person whose job it is to make sure all the boxes were checked for process’ sake.

But when things DO go wrong – major defects make it into production (“QA is the problem”), business owners or customers report that product features are “what they asked for, but not what they needed” (“Requirements are the problem”) or delivery is very late or well over budget  – THAT is when the true nature of the formal sign off shows. That’s when fingers get pointed and people dive for cover…behind the sign off.

I submit that at its core, the formal sign off serves mainly as an abdication of responsibility for a deliverable, or transference of that responsibility to the signatory.

This is why people are so apprehensive to sign off; because the signer puts him/her self on the hook for the deliverable. They’ve accepted responsibility for something they’ve likely had no hand in producing, but for which they have to answer. And when things go wrong, they’ll be left holding the bag. This is an issue of the culture of the process.

Imagine a large river being fed by several small streams.
At the point where each stream feeds into the main river, there’s a lock. Water flows from each stream into the main river, but once it’s contributed a certain amount, the lock closes. When a storm hits at the mouth of the river, and water is pushed back upstream, the locks are closed and the streams are protected, but the main river (and its surrounding banks) is devastated.

This is a metaphor for the classic sign off when things go wrong, and the real tragedy is that in this model, nobody is responsible for the successful delivery of the product (except maybe the last signatory). Everyone else has plausible deniability. If I’m contributing to the product, and something goes wrong because of my work, but you signed off on it, I can make a great case that I’m not responsible because you accepted both my product and the responsibility when you signed off.

Transparency + Communication + Accountability = TRUST

The Agile mindset, by contrast, emphasizes collaboration, transparency, and mutual accountability. We’re all in this river together…the business, development, delivery…everyone. We move away from the silo mentality that fosters people protecting their camp (or stream) at the expense of the product. We ditch the locks and move to putting the product first, abandoning personal agendas, and diving in together.

Is it possible to poison an Agile development effort by sticking to the old psychology of the sign off? Absolutely. I’ve experienced it. You have to make a conscious effort to change that atmosphere. It’s not in our nature and it’s not easy…it takes a willingness by the parties involved to give up the protection of the sign off, and sign up for shared success or failure. Foster this culture shift in your organization, however, and trust and a shared sense of ownership of the product can cement the team together, stronger than the sum of its parts.

-Dave