kHUB All Member Forum

 View Only

The Secret of Agile Motivation

By Robert Webber posted 10-25-2022 21:38

  
Idea Generation in 21st Century


Read time:
5 minutes

The Secret of Agile Motivation

Everyone is looking for silver bullets. There’s a lot written about the secrets of motivation. If the secrets are out, why do so many organizations have unmotivated employees who come to work and do the minimum to get by?

Here’s the promised secret of Agile motivation in four words:

LET THEM DO AGILE!

I’ll prove to you with a few organizational behavior principles that Agile development, as originally conceived, has the potential to establish highly motivated teams. However, this potential has been squandered in most organizations.

My wife, Susan, has a PhD in psychology with a specialization in organizational behavior. I had to take Psychology 100 as an arts elective in engineering. Some of it was interesting, but I felt I didn’t learn much that I could apply as an engineer. I liked science and engineering where I could understand principles and apply formulas, such as being able to predict the periods of the planets. Susan changed my life and career by introducing me to an analytical model of motivation based on a few simple organizational behavior principles.

My book, “Unlocking Agile’s Missed Potential,” addresses Agile team motivation with organizational behavior principles. You can put in all the practices you want, but Agile won’t be successful unless you can motivate the team. You accepted self-directed teams when you moved to Agile development. You’ve abandoned detailed task tracking by project managers to “push developers along” to get results. Without instilling Agile team motivation, it’s likely that performance will decrease.

The following chart is based on my experience as an engineering leader and what I learned about organizational behavior.

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.

Author: Bob Webber, VP Product Flow Optimization at Construx Software


Related Content


#product-management
#agile
#motivation
#employee-engagement
#software-development
​​​
#ProductInnovationProcess​​​​​​​​​​
0 comments
41 views

Permalink