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:
- 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.
- Contracts imply a lack of trust.
- If you’re actually talking to your customer on an ongoing basis, then contracts generally become superfluous.
- Requirements specs and design specs are software contracts.
- 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.
