Unlocking Agile’s Missed Potential, Robert Webber, Wiley-IEEE Press, 2022
The vertical axis is organizational performance. The horizontal axis represents the degree to which the main source of motivation in your organization is negative or positive reinforcement.
I always tried to be a positive leader. However, I would sometimes see a tough project manager take over a poorly performing project and turn it around. The project manager held individuals accountable. Individuals did what they had to do to avoid being singled out at the “project status” meeting. Should I be the tough leader or a positive leader? I created the chart to explain the options. The answer is that you should be good at one or the other, but positive leadership can maximize performance.
The chart shows that the highest performance is attained when individuals receive frequent and timely positive reinforcement for their work. On the other hand, performance can be increased with negative reinforcement, which is the threat of punishment. For example, an engineer will complete an assigned task to avoid being called out at a project status meeting. The middle of the curve is what I call “being nice.” In this case, there are no effective consequences for completing work in the organization. Unfortunately, most software organizations are in the middle or slightly on the negative reinforcement side.
If both positive and negative reinforcement get results, why use one over the other? With negative reinforcement, individuals do the minimum to avoid the negative consequences. You will also hear excuses and see finger-pointing. With positive reinforcement, you get higher performance from “employee engagement.” Individuals will overcome obstacles and put in extra effort to achieve their goals.
We’re not talking about certificates, Starbucks cards or the occasional “good job” to get you to the peak of the curve. Positive reinforcement must be built into work so the individual experiences it frequently - on a daily or weekly basis. Setting and meeting frequent goals creates positive reinforcement.
Can you think of a software development framework where teams set frequent goals they can achieve? It’s Agile development as originally conceived. Teams select the work for their sprints and collaborate to achieve a common goal. However, that’s not what I see in practice. Teams are pushed into sprint commitments to meet fixed schedule and scope commitments established by waterfall release planning. Not meeting their sprint goals? Better load them up even more to get closer to your schedule commitments.
This is exactly what you don’t want to do. Teams must meet their sprint goals to experience the level of positive reinforcement needed to get you to the right-hand side of the performance curve. In fact, if they are missing sprint goals, you need to encourage the team to reduce their sprint goals. This is counter-intuitive but supported by organizational behavior principles explained in my book.
So, for all you leaders out there looking for the secret of Agile team motivation, all you need to do is not screw-up your Agile implementation. In my book, I assert that the root cause of most failed Agile implementations is the retention of waterfall release planning with fixed schedule and content, which can be addressed with Agile Investment Planning described in my book. “Investments” are time-boxed, but teams have the flexibility to vary content as long as the financial objectives of the Investment are met. They set sprint goals that they achieve regularly.
If your teams are not meeting their sprint goals at least 90% of the time, you are either in the middle or to the left on the performance curve. You haven’t created the team motivation essential for moving to self-directed teams.