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.

Comments

Glen B. Alleman said…
Peter,

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.

Best,
Peter

Popular posts from this blog

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…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …