What is the Difference When People Change?

Introduction

Since 1989 Mary and I have been performing the role of change agent. This involves teaching or coaching new skills, such as estimation, risk management, defect identification, agile, CMMI practices, or fixing organizational problems so that work can be done quicker with fewer problems.

There is one common difference between the teams and organizations that adopt a change and the ones that don’t. The ones that change realize that the change is for them, not for the person requesting the change. If the change is seen as only benefiting someone else’s life, then it is either ignored, or, at best, adopted superficially.

For example, teams usually reject peer reviews (a.k.a inspections) because they take one or two hours of time. What makes the situation worse is that someone else is recommending inspections to the team, implying that the team needs to clean up its work. What could be worse — extra work performed for someone else to keep them happy!

A desired change for the team would be one that does at least one of three things:

• Addresses current risks or challenges
• Helps the team achieve its goals
• Helps the team maintain a previous gain

Mapping the change to a need takes effort, and this is usually the step that is skipped. This step is essential, whether one change is being deployed or numerous changes are being adopted from frameworks such as Agile, CMMI* or PMBOK*.

In the case of peer reviews, the typical challenges addressed are:

• The team works late hours to fix bugs
• The team’s reputation for quality is not good
• The pace of work is slow because the amount of technical debt is high
• Requirements are ignored because they contain more errors than information
• The code base cannot be touched because it is toxic or fragile

Changes stick when they address the needs of the team and the team expends effort to make the practice work for them. This is why some organizations using Agile, CMMI or PMBOK (for example) love them and perform extremely well and why other organizations put up with the very same practices grudgingly.

How can you use this concept?

• Before recommending a new practice or a collection of practices, stop and ask what the goals and problems are
• Identify or explain the tie between the problems and the recommendation
• Demonstrate, pilot, and try the change in earnest
• Retire practices that don’t maintain a gain, fix a problem, mitigate a risk, or help a goal

If you would like help on a change, please contact us.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link.

* CMMI: Capability Maturity Model Integration
* PMBOK: Project Management Body of Knowledge