Many companies do it: variable pay, or bonus payouts based on individual performance. It’s easy if you work in sales: The more you sell, the higher your bonus. It’s trickier with us developers and testers. We’re too far away from the money, we need personalized goals. Could be getting a certification, or reading a book. Could be team work related. The softer the goals become the harder they are to rate. And what good are goals that basically only tell you to do your everyday job?
So what’s the goal of having goals? You need a specific task or project getting done. Or you want to develop a specific skill. Or, you aim for personal fulfillment. Motivation. It might depend on many variables. Do you/your manager need to delegate a bigger task? How much time do you have to fulfill the goals? Is it a bonus plan? Is it variable pay, i.e. considered part of the “normal” salary? Do you have team goals?
I’m not going to cover good or bad goals in general here. Depending on your situation and company culture your goal and performance processes probably differ a lot. My question at hand is: How much sense does it make to have goals in an agile (Scrum) team? What kind of goals would you set? Would you still have individual goals? And most importantly: would it be a bad idea to make the success of the team’s sprints a goal for all team members?
I thought about this a lot and a fellow team lead has a very strong opinion about this. I can’t help but agree with many of his points. What’s the main objective of a sprint team? To deliver. To get their sprints done and signed off. By definition, they work as an independent unit while on a sprint, and all team members are equally responsible. If they fail, the whole team fails.
Of course you could still have individual goals, but the strict “do not interfere with sprints” rule applies and it’s a walk on a razor’s edge when a line manager from outside the team requests specific work from a sprint team member. If you don’t put time aside or rule that goals need to be worked on private time (a big no-no in my book), it’s nearly impossible not to interfere with the sprint team’s work if you’re handing out extra goals. So why not giving them all the same goal: successfully finish your sprints. Pass or fail. (You could still have individual development goals on the side, weighted less, if you’re extra careful (see above).)
I talked to some colleagues and they immediately said “No, bad idea. What if the sprint fails, but due to problems from the outside?” Well, in theory that should never happen. If the team cannot successfully finish their sprint due to influences from outside the team, it’s not their fault. Either their Scrum master failed to help, or the sprint needs to be cancelled, but not “failed”. Is it fear of being given the full responsibility? What’s the consequence of a failed sprint – if there isn’t any but “we’ll just start over”? Or is it that they’re scared one team member might be responsible for the failure of the sprint, and since they all have the same goal they would suffer, too? Don’t they trust their line manager, i.e. reviewer, to see this all and take it into consideration come review day? I believe it’s probably a mixture of all of it, the hurdles for successfully passing a sprint are quite high in our company (and rightfully so).
So my question remains, does anyone have a qualified, logic reason to vote against having a shared team goal for members of Scrum sprint teams that is based on the success of their sprints within the bonus/performance review period? Because I don’t really, and yes, I’ve been working within sprint teams as well.