We Dare Not Change

I recently encountered strong senior leadership resistance to changing and improving a poorly written set of Program Features. The product of an expensive workshop facilitated by a top management consulting firm over a year ago, using physical Post-It notes on a whiteboard. Each Post-it note was then digitally transcribed as Program Features into a software development tool.

The Program Features were considered to be immutable and written in stone. Never to be tampered with!

All of a sudden, the following sayings started popping up in my head.

“If you don’t have time to do it right, when will you have time to do it over?” — John Wooden

“Pay a little now or a lot later” — 1990s Fram oil filter commercial

“Don’t put off till tomorrow what you can do today.” — Benjamin Franklin

As a group, it was as if everyone was resigned to simply accepting the top-down Program Features as the gospel.

However, in smaller settings and one-on-ones there were rumblings and growing concerns with the Program Features that included:

• Lack of clarity 
• Too big
• Too ambiguous 
• Too specific 
• Overlapping redundancies
• Gaps in functionality
• Too much focus on the “how” of the implementation 
• Not enough focus on the “why” and the “what” of the problem 

They refused to address the source of the problems – the original Program Features. Instead, they tried to reconcile their concerns by writing better lower level product features within their own sphere of control. There are two key problems with this bottoms-up approach:

1. The Program Features were written in a way that required multiple products’ contributions. 
2. Without clarifying the Program Features you may under-deliver or over-deliver on the original expectations that were verbally discussed and assumed but never captured on the original Post-It notes.

The two key reasons I heard for the immutable resistance to changing the top-down Program Features were:

• Reason 1: “It’s what we committed to the business”
• Reason 2: “It’s what our program funding was based on”

Let’s unpack these two reasons.

“It’s what we committed to the business”

• If you ask ‘X’ number of people including the business, how they would define “what” and you get ‘X’ different answers, you’ve got a problem.
• Over the course of time, “what” the business wants will change. Do you and the business really want to stubbornly lock yourselves to a set of commitments instead of adapting to the changing landscape of your business over time?
• The 3 C’s of Agile story writing are Card, Conversation and Confirmation. Of these 3 Cs, ongoing and continuous “Conversation” with the Business is key when it comes to clarifying and refining the “what” of a story. It’s not a one-time and done affair. How can it be when all you had was a 3”x5” index Card or Post-It note to capture all the original thoughts? It’s a daily conversation between business people and developers that continues well after the original requirements gathering workshop.

“It’s what our program funding was based on”

• If you spend all the funding you were originally given and the business doesn’t get what they thought they were going to get, you’ve got a problem.
• Taking the opportunity to clarify “what” will be delivered for each Program Feature doesn’t mean you have to change the program funding envelope.
• Take advantage of the Program Features’ fuzziness to mold and refine your program scope to fit the available funding.

And, If the above considerations weren’t sufficient cause to change, a couple of events piled on to further widen the cracks in their immutability armour.

1. They weren’t sure nor aligned on what they were  collectively trying to build and as a result  had a harder time credibly demonstrating progress to executives.
2. The noise of ambiguity and confusion spread and increased across the organization to deafening levels.

They were ready to change.

One team member summed up the situation perfectly:

We should be digging a ditch, but we are spending a lot of time talking about shovels. And I’m so dim that I’m asking “What’s a shovel?”.