Adopting Agile in an Environment of Fear
Agile adoption and transformation is sometimes effective, and sometimes not. Is there a common thread to the failures? Does fear have anything to do with it? Opinions vary on the effects of different fears upon success:
Jim Highsmith talks about fear of change and fear of choice, and that perhaps fear of making a choice is just as much a factor than the common belief that fear of change is what gets in the way:
Agile, flexible, adaptive and dynamic are all words we use to encourage people and organizations to be more responsive to the turbulence in our business and economic environment. We then deride those who we view as resistant to change. But maybe what holds us back is as much “fear of choice” as it is “fear of change.” In “Linchpin,” author Seth Godin says that entrepreneurs and leaders who create tons of value for their companies often perform the same tasks as the rest of us, except for a critical 5 minutes per day. And in that 5 minutes they are somehow able to cut through the thousands of possible choices and select the one that creates value. For others, this cornucopia of choice is paralyzing. It’s the fear of choice that holds them back.
Radu Davidescue writes that agile adoption needs a fear-free environment:
Agile environments needs to be "fear free" places. When people have no fears they can unlock their creativity, bond together easier to work in a team. Trust comes better when there are less fears. People spend more time working rather than dealing with their fears.
Naresh Jain cited fear of failure as one of the prevalent roadblocks for successful agile adoption in India:
While these companies are adopting agile, they have lots of concerns and questions. One recurring theme I’ve seen, is all these companies are really really afraid of failure. IMHO, this fear leads to a very dysfunctional agile adoption. Teams pick what is easy to do and what fits into their existing model, in the name of reducing risk, call it fail-safe ;) . With this approach individuals and companies fail to see the real benefit of Agile.
Michael DePaoli argues that fear is an over-generalization of why things fail, and competent professionals will deal with fears effectively, but the risk/reward structure is what is at the heart of failed adoptions:
Perhaps when looking at the impediments to an agile adoption we need to take a different perspective beyond just fear, because not everyone is patently afraid of change.
If you can, look at how management is compensated in your company. After 25 years in the software industry I’ve been shocked at how often management’s stimuli (bonuses) are tied to meeting schedules and budgets, not to the delivery of value and quality. This frequently results in a response counter to change.
In my opinion, this is based on an over-arching human psychological challenge that reaches beyond just work… The illusion of control! We can’t control even what goes on in our own bodies, let alone how a group of people will interact and what exactly they will produce and when, yet compensation is too often based on this.
So there are several opinions on the impact of fear on agile adoption initiatives. There still remain many unanswered questions about how to deal with fear specifically. Also what about a culture where fear is built-in? What if there was no way - at least in the short term - to address the fears? Could agile initiatives still be successful?
Please share your insights and experiences in this very important, but under-addressed topic.
Embrace fear and control / Explain through experiments and analogy
He notes that in the beginning if something is presented as a threat it often leads to greater initial motivation to address it than when presented as an opportunity or benefit. There is a lot of nuance to this, so I am simplifying.
So, what if instead of castigating fear and illusion of control as pure myths and impediments they were embraced?
To me, it is a great motivator to fear the risk of "not delivering anything of business value" by certain dates. Couple this fear with the enhanced actual control that agile, or more simply iterative and incremental practices which allow for frequent inspection and adaptation, brings it is even more motivating.
So, perhaps framing agile not as an adoption of a new process, but as a way to avoid failing value creation and delivery could be more beneficial than fearing to fail at "adopting agile". At the end of the day, whatever practices we employ should be about delivering what is needed to realize stakeholder value, not just "perfect agile adoption" anyway.
I have recently had success in framing agile with very simple analogies and thought experiments to people. Example: I ask a business stakeholder what it would feel like to have someone set an arbitrary deadline for how long it "should take" to finish reading a 100 page book into a microphone so that it can be broadcast later.
That is, I ask them "what if I said you have 100 minutes to record all of this, would you fear that you might fail to complete it?" Normally they say yes they would fear failing. I ask why, etc. Typical answers about not knowing how difficult it is or whether one page per minute is realistic.
I then ask if they can think of any way they could forecast to me how long it would take, if I assure them that each page is roughly the same number of sentences and words, etc.
They say yes, if they can be allowed to read a handful of pages and then extrapolate by math.
This flows into what I call "Sentence Points" or "Page Points" before gradually introducing Story Points and other ideas from folks like Mike Cohn. In this way I see them intuitively deriving the concept of "Velocity", in this case "Sentence Velocity" or "Page Velocity" and these flow naturally into "Stories" and the conversational nature.
In presenting this to someone who works in an ER he immediately compared it to the fact that you do not know in advance the complexity of each patient case before you inspect and examine the patient! That sounds like an even more complicated and important situation than most agile projects where we can roughly determine
velocity through enough teamwork and collaboration with estimation and empirical observation.
Build a network of agents
In many cases fear is an underlying reason for impediments of an agile team. There’s a wide range of
effects caused by fears: resistance to large organizational change, procrastination of personal
decisions, inability to surface the real issues in a retrospective meeting, to name a few. To
successfully remove such impediments, the fears of all involved individuals must be understood.
The workshop is divided into a short theoretical part and a longer practical part with group work. The
different kinds of fear and their origins are shown as well as the distinction between anxiety and fear.
A specific model of fear is presented and the purpose of fear is explained.
The participants of the workshop discuss in small groups to find strategies how to deal with their own
fear-driven impediments and how to handle such situations.
Examples of fear-driven impediments:
* Fear of punishment: "I must not use TDD, my boss forbid it."
* Fear of responsibility: "I will not set up a new build server. It will be my fault if it won’t work."
* Fear of personal loss: "I will be fired or removed from the team if I say ‘no’."
* Fear of implications: "We can’t change this specific part of the organization because team X
would get unhappy."
* Fear of losing control: "Your self-organizing team is all well and good, but I’m going to give
you a year plan to tell you who will do what and when."
In an agile environment it is important to concern oneself with fear and one’s own fears. If fear is a
reason to fail, it should be dealt with as fast as possible. Understanding fears and fear-driven
impediments can open the readiness to change
* Learn about theoretical aspects of fear and anxiety
* Learn about different kinds of fear, their origins, and their symptoms to recognize them
* Participants will discuss and analyze their own fear-driven impediments and elaborate how
to handle such situations.
Hope to see you in Salt Lake City in a few days!