Skip to main content

Does Your Agile Transition Provoke a Grief Response?

Radical Management principle number 4 says that communication must change from top-down directives to adult-to-adult discussions. Why is this so important? And how can you tell if your agile transition is really transitioning "agile-ly"?

Glen Alleman, author of the Herding Cats blog, recommended that I look at Peter de Jäger's webinar on The Art of Communicating Change. Given Alleman's critical perspective on Agile and Stoos,  I wondered, could there be something about Management in general and Change Management in particular that I've missed?

De Jäger starts by explaining that people react to change differently depending on whether change is voluntary or involuntary. Examples of voluntary change include deciding to learn a skill, getting married, or accepting a new job. People change like this all the time. Although it takes time to learn the skill or adjust to being married, most people do it willingly.

An involuntary change is a completely different matter. This change comes from outside: examples include getting laid off, being diagnosed with cancer, having people pulled off your project or the deadline being moved up; somehow they all feel like death. Involuntary changes provoke a grief response. This response can, in turn, provoke severe resistance to the idea or change under discussion.

According to Kübler-Ross, a grieving person goes through 5 steps on the road of acceptance:
  1. Denial
  2. Anger
  3. Negotiation
  4. Depression
  5. Acceptance

de Jäger proposes 7 questions to help organizations get through these 5 stages. What he does not do is challenge the notion that top-down communication is the best/only way to effect change. Top-down communication causes the grief responses, because people are hit with changes without being consulted.

Is your Agile transition provoking grief responses? Look for signs of denial, anger, depression or passive resistance. Are participants trying to negotiate away key pieces of your agile framework? This is a sign that your roll-out is too top-down. You need to get people on board. You need to get more buy-in.

The AIDAA Approach

de Jäger does hint at a better approach during the Q and A session (around 47:20 into the Webinar). The best change agents give people the problem and let them come up with the solution. What does this sound like? It sounds like Scrum. The product owner comes to his team with a problem and the team solves the problem.

The big difference between this approach and a command-and-control approach is, when and how is the change discussed? Top-down means, management communicates a decision and people have to deal with it. Adult-to-adult means, you discuss a problem together to find an optimal solution.

In the last year, I have coached three separate agile transitions. In each case, we followed a pattern of building awareness and interest (and hopefully desire). In each case the transition moved forward without the passive resistance so typical of Agile transitions is large companies. Why?

The decision on whether to move forward was pushed one level down from the person asking me to introduce Scrum. In two cases they said yes, in one case they said no.  In that case, the middle management team proposed a way forward that they believed in, so this too has been a successful transition to a happier, more productive constellation.

Applied to change leadership, I call it the AIDAA approach. AIDA is a term from marketing: Awareness - Interest - Desire - Action. A purchase decision requires a step-by-step build up. Action (purchase) is the final step when buying a product. When implementing a new process, Ability is also required, so I add an extra "A": AIDAA.

By delaying the decision until after everyone understands answers to Why, What-does-it-mean-for-me, and 6 other questions that de Jäger raises, you transform the change from an involuntary change to an voluntary change. So you do not provoke a grief reaction (or just very small one). This completely changes the dynamics of the situation and increases your chances of a successful transition.

Want to talk about this some more? Join Steve Denning and myself at our next free monthly mashup webinar, e.g. Steve and Peter's Monthly Mashup, May 17.


Glen B. Alleman said…

I'm no fan of unsubstantiated claims about agile. We use agile (very scrum like) on several software intensive programs for manned space flight and embedded communications systems.

It's when we start using "hype type" phrases that I get a less supportive. Agile and our high ceremony programs (Federal Acquisition Regulation) is a very nice fit, but the claims for and against need to have field evidence.

So please understand, I am a supporter of agile when the facts about its use and misuse come with the conversation.
Peter said…
Hi Glen,

Thanks for this, and sorry that I misinterpreted your earlier. I hope the text now properly reflects your attitude towards Agile.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…