There is a well-established process for domesticating young elephants that demonstrates the process of learned helplessness everywhere including organizations and agile teams. When elephants are young they are secured with strong chains. They pull against the chains but eventually learn that they cannot break them. So over time, they eventually stop pulling against the chain and then they can be tied up with a much lighter chain or a weak rope.
There is another similar story about research done on monkeys and how they learn from each other about appropriate behaviors. In these studies, they demonstrated how groups of monkeys learned from each other the behaviors that would be rewarded or punished. They showed that even if a particular monkey did not see first hand the punishment or negative behavior, those monkeys taught new monkeys how to properly behave. The monkeys demonstrated how groups enforce behaviors and fight off anything that threatens the status quo.
The monkey story is often cited in organizational change management circles to show how learned helplessness is transmitted in organizations and how we learn to fight to maintain the status quo. Like the elephants, we learn to stop struggling and to simply accept our situation as the unchangeable reality. We learn to accept our fate and in the case of the monkeys, we violently react against anyone introducing change.
Both of these stories illustrate the idea of learned helplessness. Learned helplessness is most noticeable when trying to introduce a change or prompt someone to take action.
What is Learned Helplessness?
The Dictionary.com definition of Learned Helplessness is pretty depressing.
“the act of giving up trying as a result of consistent failure to be rewarded in life, thought to be a cause of depression
Not All Agile Team Members Suffer from Learned Helplessness
I often run into learned helplessness with new Agile teams. It seems worst when organizations are big and people have worked there a long time. When I describe something different that could become the new reality, I frequently have team members shrug their shoulders as if to say, “that is just not possible here”. Sometimes they will look at me in a lovingly yet condescending way as if to say, “silly boy, you must be new here”.
In other cases, they take the time to explain to me how they are different, and while my ideas may have worked for the XYZ company, it won’t work for them because they are unique.
I had a recent example of a new developer at one of my clients. She was aghast at the tool that developers in this company used, especially when compared to what she was used to in other organizations. The other developers on her new agile team had resigned themselves to small displays and inadequate tools. But she argued vociferously about the need for proper-sized computer monitors, modern IDEs, and collaboration tools like large TV screens. But she not only complained and argued about it, she put together a case for why it needed to change.
And then one day something amazing happened. I strolled by the team area to discover that all the developers had large computer monitors (42”)! Yes, she had fought against the status quo and won!
Carol Dweck and the Growth Mindset
I love and highly recommend Carol Dweck’s Mindset book. Carol does an excellent job of describing two ways of viewing ourselves in the world; what she refers to as Mindset. Those who have a fixed mindset view things as fixed and unchangeable. This includes our intelligence and our abilities. The fixed mindset says we are born a certain way and we cannot change it.
On the other hand, those with a growth mindset view their abilities as malleable. They believe that all humans can learn, grow, and adapt. The Growth Mindset shifts the focus away from “born with” to “learned” or acquired. There is a focus on putting in the effort.
I don’t recall exactly where I found this but I have the words below framed on my desk as a reminder of the growth mindset.
Key Takeaways for Scrum Masters, Agile Coaches and Leaders:
- Learned Helplessness Exists – Whether it is easy to recognize or not, this exists in organizations. Don’t be surprised by it. There have been enough rewards and punishments for certain behaviors over the years that can’t be seen or recognized. They are just part of the way things are done around here.
- Have some Empathy – We have all learned some form of helplessness. So be patient with people who are struggling to believe that things could be different. At the same time, turn an inquisitive eye inward. Where have I learned to be helpless? Have I decided I was too old to learn the piano, run a marathon or join the coding bootcamp?
- Be Congruent – Many of us introduce Agile in organizations and we talk about empowering people. If the leadership doesn’t follow through, our words will be hollow. For leaders, don’t introduce Agile and talk about empowerment unless you are prepared to empower and trust the people on your agile team. Telling someone they are empowered without actually empowering them is going to backfire every time. Don’t tell people that they have choices if you haven’t really given them choices.
- Unlearning Can Take A While – To make real, impactful change, most of what has been the way things are done around here need to be eliminated. Management needs to send strong and consistent signals that there has been a change. And they need to keep sounding that message for a long time. Agile team members will gently test the boundaries, just like pulling on the rope on their leg to see if it will break. Managers need to encourage this testing and respond consistently.
If you liked this post, you might also find these posts interesting. Cheers!
As an agile team architect who is cornered by the agreed upon project vision and contrary views coming from will of the manager I report to, I greatly appreciate this article. It’s an affirmation of sorts.
beautifully put. I searched “Agile teams learned helplessness” because I was noticing something happening with some of my team, and I found this. We are slowly moving from Waterfall to Agile and I think one aspect that isn’t addressed well enough is behavioral change. With Waterfall it’s easier to be a bus passenger as all the big decisions are premade and managed by a PM. QA testers coming in to Agile may feel that it’s not their role to speak up, push back on decisions, or hold developers accountable to what they committed to. I think the idea of Learned Helplessness from Waterfall is applicable here. Happy I found your post here.