Tuesday, May 20, 2014

Disaster avoidance: Step one, check for false beliefs...

In early 2012 I was scrum-master on the largest project my office had ever attempted and it was to be a disaster of epic proportions. I tried to prevent the disaster but couldn't. Now, a year and half later, I think I have figured out why. The bad news is that almost all organizations and teams face some variation of this tale. The good new is this story just might help you prevent your own disaster.


Here's my story.

For 2 months before the official project kick-off I worked with a business analyst to convert the existing requirements into user stories. Simultaneously another team was working on "the big pitch" that would eventually win us the work.

Our team made the pitch to the client and their CEO was impressed.  He responded with something to the effect of, "I'll take it if you can have it to me before February of 2013." The pitch happened in January 2012. By the time the project team could be spun up, we would be 10 months away from the February 2013 deadline. My company agreed that we could deliver the project and shook the CEO's hand.

Normally, you want to involve your technical people before making such a firm commitment. You want to create an estimate or at the very least to do an assessment to make sure you're "in the ball park" before you commit to a delivery date and locked feature set.

But our problems were deeper, more fundamental. When we sold the idea to the client we also sold the idea to our entire management team. Our management came away from the pitch with an ideology. The ideology was that to get the project we had to deliver, therefor we would find a way to do the work. It didn't matter that the functionality couldn't be built within the time available because we wouldn't have the work if it wasn't possible. And in those moments of glad-handing, high-fiving, and backslapping "false-information" became a "false-belief."

At the time, I didn't know the difference between "false-information" and a "false-belief" but new research is showing that the difference is of paramount importance.

After the pitch I did a very rough estimate and came up with 17 months, my boss had done an estimate that said 18 months and a senior contractor had come up with 19 months. Three independent estimates all put the delivery at around 18 months.

The deadline we had promised was half that. From the first sprint, I began demanding that we cut the scope in half but the ideology reared it's ugly head and the full on disaster began.

It was a blood bath. Within a year from launch, 95% of the 200+ people that worked on the project would leave the company. In the first two months of the project the program manager was replaced, then the technical project manager. Then the project manager quit. Another month passed and the entire project management group "left." Our lead UX designer followed them out the door along with 2 of the 5 UI developers. An offshore team of 70+ people worked for 4 months and created a separate code-base that had to be thrown away in it's entirety. There were over 13 separate redesigns of a core UI component. When I say this was a disaster, I mean it. The person that took over for me as scrum-master quit the day after the product was released.

Why hadn't the managers listened to me? I had ample evidence showing that the minimum time needed to produce the promised features was 18 months. I had a list of some 300+ user stories. Any fool could see that to deliver 300 user stories in 300 days (10 months) we would need to average a story a day (including weekends and holidays). We were finishing between 2 and 5 user stories every two weeks. Far less than the needed velocity. [This pace was also confirmation of the 18 month estimate.]

What had I done wrong? Why wouldn't they listen? Why couldn't they see for themselves?

On more than one occasion I had said to the business analyst, "I just don't see it. There is nothing that should give them any reason to believe the company can pull this off in the promised amount of time!"

Whether management realized it or not, when they had done the pitch they hadn't just sold the client, they had sold themselves. They had come to believe that this was a Career Defining Moment (CDM). They had given their word and they had let this promise define them. The truth is that they couldn't deliver on the promise but I doubt anyone on the pitch team knew that. I believe that in their hearts they believed they could deliver the project as promised. And they were wrong.

I'm not using 20/20 hindsight here either. I fought hard to help clear their heads, to show them the data and why the deadlines and expectations were unrealistic. I was not the architect on this project, but I was a respected senior voice. The team believed that I knew what I was talking about when it came to the technical and software project issues. I stacked the estimates and user stories up right in management's face until they couldn't ignore them. The leadership team just pushed them aside and said, "we have to do it, we will do it." And they were wrong.

But again, why shouldn't management think this? All agencies try to do the impossible on a daily basis. Ad campaigns are amazing. Most of them are done on incredibly short timescales under heavy pressure. So the account executives and the management teams are used to rallying the troops and launching the product at the last available moment. In fact, it's a part of the culture.

But this time the work was different. This wasn't an ad campaign, it was a major web site. The scale of the work was massive compared to the normal 5 person, 3 month projects that the company usually took on. This project would eventually be hundreds of man years and tens of millions of dollars. You just can't rally the troops and "git 'er done." You have to plan, architect, design, automate, and integrate. There simply was not enough time in the schedule to do the project as it was promised.

Because our management had made a promise and was not familiar with projects of this scale, they had the unfortunate combination of belief in the organizational commitment and false-information. Together, with their reputations on the line, these formed a collective "false-belief."

False-beliefs have such a strong influence on decision making that people will often discard facts they know to be true if they are in disagreement with the false-belief, particularly when that false-belief is tied to your sense-of-self. On the other hand, research shows that when people have false-information not tied to a belief they will easily discard false-information when given the facts.

Researchers are finding that when the facts and evidence are in strong disagreement with our sense-of-self, we throw away or marginalize the facts and evidence. This influence is so strong that when we discard the facts it often has the effect of making our beliefs even stronger even though those beliefs are in conflict with the facts. Researchers are finding that this happens even when the believer knows the facts to be true.

The New Yorker did this review of the research: why-do-people-persist-in-believing-things-that-just-arent-true [see also: 2006 HBR Evidence Based Management]

The researchers looked at what it took to change a false-belief and concluded that the continued influence effect seems to defy most attempts to eliminate it.

That's why real change often requires a paradigm shift.  You have to avoid the false-beliefs from being implanted in the first place. As Bucky Fuller put it,
You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. 
Fuller knew the fight is too hard.

Once a person holds a false-belief it is damned near impossible to get rid of it.

I believe my biggest mistake as scrum-master was in not identifying this ideological view and working with the management team to change or reshape their beliefs. Without changing their belief, no amount of project data, no mountain of facts, nothing as obvious as "300 user stories and 300 days left" was going to change anything.

How ideological was management? All I can do is make some observations. First, they held to their beliefs right up until launch, seeming almost dismayed that we weren't going to make the deadline with the promised features even as the date approached. Of the promised functionality, probably half was delivered (less actually). Their beliefs were so strong that they went at least 50% over budget and paid for it with the company's money. For a contracting agency, I'd say that represents about as strong a collective false-belief as can exist.

As MARIA KONNIKOVA writes in the New Yorker, "false-information" can be corrected but "false-beliefs" are hard to change. She points out that researchers have found that, "if someone held a contrary attitude, the correction not only didn't work — it made the subject more distrustful of the source." So with each attempt to push the project forward with facts and data, I was unwittingly making the management team distrustful of me. And management distrust does map well with my experience.

Instead, I should not have been trying to give them all the facts and data.  I should have been trying to reshape their belief toward something more realistic.  Then, maybe, the project could have gone differently.

Research is showing that one way to do this is to ask the person with the false-belief to walk you through exactly why their belief is true. This has the effect of running them up against the falsehood without you jamming facts in their face.

It's worth noting that even had I recognized this situation for what it was I may not have been able to change it. I began to notice that the people I was dealing with were actively blocking access to our top executive so that they might shape the information he was being given. His isolation would have prevented me from any attempts to correct the false-belief.  This would have left me no choice but to try and "push the noodle" from the bottom which we all know is rarely effective. The people isolating the executive weren't just the stewards of their own false-belief, they had become the stewards of his as well.

This story has everything to do with the management team's false-beliefs created during the months that led up to the pitch and then locked in stone during the pitch. When the CEO declared that "I'll take it if I can have it by February of 2013" he probably thought he was slyly instilling a stretch goal.

Instead, he was pouring the foundation for a "false-belief" that would haunt his project until the very end.

No comments:

Post a Comment