Archive for November, 2009

Just a brilliant talk

Musings | Posted by Doc
Nov 19 2009

Thanks to Sumeet Moghe, I just watched this.  Of course, any TED Talk is worth watching.  I particularly like this one.

The Anchor

Agile & Lean | Posted by Doc
Nov 14 2009

In Agile software development, we talk about learning from the past in order to improve the future. As I spend time with clients, whether doing coaching or training, I find them burdened by the past.

The Anchor.

“That’s the way we’ve always done things.”

Resistance to change for the sake of resistance.

Those of us who have had opportunity to work on and with Agile teams have seen what a difference that shift in principles, practices, and thought makes.  It makes a difference in the pleasure and pride that team members find in what they do. It makes a difference in the quality of the product they create.  It makes a difference in the overall competence of the team, both as individuals and as an entity.

Waterfall, on the other hand, has led to unhappy team members and failed projects.  Demonstrably.  In one report, the Standish Group found that only 34% of software projects were unqualified successes. While it says that the percentage was up to 34%, I still find that to be a discouraging statistic.  What’s encouraging is this:

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

So here we have an approach, along with a set of practices, that has been shown not to work for years, even decades, and yet managers or organizations hang onto it like it’s a life preserver, when in fact, it’s an anchor.

Drop your anchors. What is so frightening about not buying into the fallacy that you can know everything up front, plan everything up front, budget everything up front…?  Well, it goes on and on.

Of course you need to be able to plan and budget. But I don’t buy into the idea that anyone believes that those numbers are real or accurate. Rather, it’s “the way we do things” and they are resistant to change and the unknown.

Cast off your anchors! Learn from the mistakes we’ve been making for 50 years and find better ways to do things.  Let’s deliver better software with fewer defects that meets the needs of the customers/users, delivers more value, and does so when it says it will.

With Blame Goes Guilt

Agile & Lean, Coping and Communicating | Posted by Doc
Nov 07 2009

I was talking to a colleague last night about my thoughts around A Culture of Blame. He was sharing with me one of the tactics used by management, and it occurred to me that it’s hard to live in a culture of blame without also having blame’s counterpart, guilt.

“We’ve made a commitment to our customer, and we must fulfill that commitment.” This frequently means “I made a commitment to our customer, and YOU must fulfill that commitment (or YOU will suffer).”

Poor managers frequently combine blame and guilt as their two weapons of destruction. Rather than think of positive ways to motivate people, they undermine and discourage, somehow believing that this will produce better results.

Research and anecdotal evidence reveal that reward and positive motivation work far, far better than punishment and negative motivation. And yet, there we are.

One of the many things I love about Agile teams is that we move away from blame and guilt to collaboration, support, respect, and motivation.

%d bloggers like this: