A Culture of Blame

Posted by Doc
Oct 30 2009

In developing and delivering training on Agile Software Development, I frequently talk about the group ownership and individual commitment. I also talk quite a bit about the formation of the team, the group responsibility, and the mutual respect.

This is very cool stuff.

When I get to the Agile Manifesto, I dig into what the four main concepts mean to us as we embrace Agile.

Right now, what’s on my mind is the third value: customer collaboration over contract negotiation.

Here are some of the key points that I find in this statement:

  1. Contracts are only put in place so that we can enforce them when we believe that the other party has not met their obligations under the contract.
  2. Contracts imply a lack of trust.
  3. If you’re actually talking to your customer on an ongoing basis, then contracts generally become superfluous.
  4. Requirements specs and design specs are software contracts.
  5. See point #3.

As I’ve been doing coaching and training, I’ve had the opportunity to see a variety of different organizations and situations. What has become clear to me is this:

Some organizations that embrace Agile have a culture of openness, safety, respect, and friendliness, where the people who work there are happy to go to work each day. Those employees have a feeling of pleasure and pride in what they do and the people they get to do it with.

Then there are organizations that are built upon a Culture of Blame.  Contracts are about blame.  Specifications are – at least to an extent – about blame. Project plans, which on the surface are about predictability and budgeting and resource allocation, are also about blame. What I’ve seen happen in these organizations, more than once, is that Agile adoptions fail in the worst case, and struggle in the best case.

The problem is that their “leadership” (quotes intentional) are mired in Waterfall practices. The irony of this is that – while management is operating under the fallacious assumption that these practices work – these practices have been demonstrated repeatedly and measurably to fail.

“The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term “waterfall” in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).” (from Wikipedia)

What seems to go hand in glove with this Waterfall mindset is the contract. These managers need to have specs and project plans so that they can figure out who is at fault when the project is late, over budget, or of low quality. Sadly, those of us who have embraced Agile – and many who still live in the Waterfall world – would tell you that at least one of those three – lateness, over budget, or low quality – is pretty well guaranteed.

Someone asked me recently whether it was possible to succeed in adopting Agile without there being a cultural change.

My answer is a resounding “no!” Without the move to a culture of trust and respect, without the true support – not just lip service or permission – of representatives of “leadership” at all levels*, Agile adoption is very unlikely to succeed.

A Culture of Blame is not always obvious – although frequently it is obvious. But there will generally be smells that a reasonably discerning individual can detect that make it clear that the Culture of Blame is present.

* I refer to this as Vertical Commitment or Vertical Buy-In. As a coach and facilitator, I believe that without ensuring that management shares the same language about Agile principles and practices, and without ensuring that they are committed to the success of Agile adoption, the culture clash is unendurable.

10 Responses

  1. Twitter Comment

    RT @athought: Blogged: A Culture of Blame [link to post]

    Posted using Chat Catcher

  2. Twitter Comment

    Nice one Doc. RT @athought: Blogged: A Culture of Blame [link to post]

    Posted using Chat Catcher

  3. […] This post was mentioned on Twitter by Steven (Doc) List, Robert Stackhouse and planettw, Dawn Cannan. Dawn Cannan said: RT @athought: Blogged: A Culture of Blame http://www.stevenlist.com/blog/2009/10/30/cultureofblame/ […]

  4. Social comments and analytics for this post…

    This post was mentioned on Twitter by athought: Blogged: A Culture of Blame http://www.stevenlist.com/blog/2009/10/30/cultureofblame/

  5. Twitter Comment

    reading A Culture of Blame on The Doctor Is In [link to post]

    Posted using Chat Catcher

  6. Jeff Gordon says:

    Interesting.. the second agile-contracting connected blog post in 24 hours. Was there a conference on this somewhere?

    But I digress.

    Contracts aren’t about blame. They’re about responsibility. You’re right, we can’t contract for trust… and folks who don’t trust each other aren’t going to have a good experience (even with a contract).

    But all too often, even people who trust each other have a different recollection of “the deal” long after the deal was agreed upon. So you go back to the contract, the SOW and accompanying documents to see what was agreed.

    So don’t blame the contract for the culture. Contracts wouldn’t be necessary if people:

    1. Had 100% perfect memories.
    2. Had 100% perfect behavior.

    But they don’t, so contracts are a necessary tool.

    • Doc says:

      Jeff, those are valid points. And that’s where the Agile mindset and approach change the pattern. If we don’t worry about remembering or referring back, but rather talk about those “things” when we’re ready to work on them, in the current business circumstances, then what we do will be what is needed/necessary/appropriate now, not three months ago or six months ago or two years ago when we thought we’d know what we’d need now.

      This is not just about software development, although that’s my context. The example I frequently use in training is that of building a house. I went through the experience. As we moved forward, I discovered things I could not possibly have thought of at the beginning. Each time I asked for a change, the builder charged me $250 just to write a change order, then whatever the cost of the change was. This was because we had a contract. While there’s no question that plans were necessary, it was clear that we needed to be flexible and responsive to change. The contract frequently got in the way, rather than making things clearer.

      On Agile software teams, contracts generally get in the way. We have stories, we talk to the customer on an ongoing basis, and we respond to change.

      Getting back to your point about different recollections and going back to see what was agreed… yes, I suppose I can’t argue that there are circumstances where that seems necessary. I wonder what would happen in a situation where (a) there was trust and (b) we work together to achieve our goals. Not “my memory was right and yours was wrong” but “what do we think we need to do about this today given what we have learned and the current circumstances?”

      I prefer simple contracts: I will provide service – software development, training, coaching, consulting – for a particular fee for a particular time. That doesn’t require a whole lot of perfect behavior or perfect memory.

      No, I don’t think all contracts are bad, and yes I think they are sometimes necessary. I do think that a reliance on contracts as tools of enforcement contributes to a Culture of Blame.

      [and no, there was not a conference, that I know of or attended – perhaps this is just important enough that it’s on people’s minds? 🙂 ]

      • bonniea says:

        “Getting back to your point about different recollections and going back to see what was agreed… yes, I suppose I can’t argue that there are circumstances where that seems necessary.”

        I know this is an old topic now, but it’s awesome research material. Thanks Doc!

        I’d think the remedy to that concern would be working on small enough pieces, with each other in the room at the same time so as to remove memory from the equation, or at least reduce the cost down to nil.

  7. […] A Culture of Blame (Steven ‘Doc’ List) […]

  8. […] 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 […]

Trackback URL for this entry

%d bloggers like this: