How To Screw Up a Project – Period
July 21, 2008
I just published this piece through the Cutter Agile Project Management Advisory, entitled “When Agile Doesn’t Work”. I decided to share it here as well. I tried to emphasize here are two critical pieces: Domain Knowledge and Dialog. Screw these up, and it doesn’t matter what approach you use; trouble awaits. But the counterfactual holds as well – do these well and you can succeed, regardless of the latest software development “religion.” Enjoy 🙂
Last month, I had the privilege of being one of four keynote speakers at the Better Software Conference in Las Vegas. I’m not a gambler, so I didn’t partake at the card tables or roulette wheels, but I do watch software project managers gamble all the time, so it seemed to be a fitting place for a technology conference.
During my speech, where I talked about statistics on agile projects, offshoring, and other types of software scenarios, an interesting question emerged from the audience. The person asked, “What happens when agile projects fail?”
There are many reasons why any project could fail, but what came to my mind was a slide in my deck that was more cartoon than boring PowerPoint bullets. It showed an image of the human brain with the words “Domain Knowledge” underneath it. Next to it was a cartoon image of talking heads, and above it was the word “Dialog.”
That one slide actually came into being when, about four hours before my talk, I realized that my presentation file was mysteriously missing from my laptop! After nearly passing out from the realization that in a very short time I’d have to speak before about 600 really smart people, I thought to myself, “What are the one or two ideas that I want to communicate to my audience?”
The phase “development as conversation” popped into my head, often also discussed by Kent Beck, Jim Highsmith (both fellow Cutter Senior Consultants), Robert Martin, and others. I thought about the agile case studies in my missing slide deck. Two of the companies were considered productivity and quality “poster children.” The others had mixed success. I then blended my one or two key ideas into a previous story deck and created a new incarnation of my keynote. Voila! Refactoring in action!
Cut to the chase on the answer for the audience member’s question: “Sure,” I replied. “In my opinion, a distinct difference between the five companies in my case study presentation — each of them implementing agile — and their degree of success or failure can be traced to how well or poorly they handled two critical attributes: domain knowledge and dialog.”
With regard to these attributes, let’s talk for a moment about one of the projects that “failed.” In this story, the company brought in a new “green” team in an attempt to bring a new medical IT application to market. These new developers were learning about this product and its features for the very first time. Moreover, key players who were once with the company — who were familiar with the requirements — had recently quit and were unavailable to help. Much of the brain of this company was hollowed out, as in a lobotomy.
Score on Domain Knowledge: LOW
Next came the subject of Dialog. This project was a new Scrum initiative, and various parts of the team were not co-located. The processes necessary to move critical knowledge from people’s minds and into the minds of other players were not in place yet. They also skipped a co-located release planning meeting (Iteration 0) because it was considered too difficult to coordinate getting the people in one room, but mostly because “there was no time.” Thus, face-to-face relationships weren’t established — quite different compared to a cohesive group where members know and trust each other, where people watch each other’s backs, and at times, you experience a special synergy that sometimes manifests in things like one person finishing another person’s sentences during a conversation.
Score on Dialog and Communication: LOW
I’ve always said that software development as knowledge work is about taking ideas from smart people and creating, inside a dumb machine, a model of the human mind that takes information and seems to think and act like a person or a collective. That’s what software is: the brains inside a dumb box. Creating that inside a piece of hardware is equivalent to downloading the human brain, and to do that requires expert thinking and smart folks moving that information around — often under a deadline.
This medical IT application project ultimately was cancelled. It never got off the ground because of — listen carefully to the coup de grace — the looming deadline. That was the critical third “failure factor.” As my friends Tom DeMarco, Tim Lister, and their co-authors said in Chapter 28 of Adrenaline Junkies and Template Zombies (a fantastic book), “Time removes cards from your hand.” This team never had a chance from the beginning. The deadline was set first, and it was fait accompli that low domain knowledge and ineffective dialogue would manifest in slower code progress, lower productivity and velocity. They missed early (aggressive) milestones in quick succession from the onset, and management quickly lost faith.
Score on Project: CANCELLED
Interestingly, projects like this never make it into our historical database. When the plug gets pulled, there’s no data left behind. Nothing gets delivered, and productivity is zero. But what is left is the lore that circulated among the team members and consultants like me who took part in and witnessed the story as it unfolded. And in this one, and quite a few others, was the lesson, “When domain knowledge is low, and when ideas on solving complex problems can’t move around through effective dialog and conversation, and when time dials up the pressure failure is virtually guaranteed.”
Isn’t this the case, regardless of whether or not a team implements agile methods? I welcome your comments on this Advisor and encourage you to send your insights to email@example.com.