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.


Anonymous 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…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…