It seems, the theorists on waterfall got it all wrong. Waterfall software development is not Analyze, Design, Implement, Test, Release, it’s rather Analyze, Design, Implement, Look for whom to blame. Andy Glover – The Cartoon Tester was kind enough to draw this into a neat little cartoon for me:

Of course, not waterfall is by all means the problem in the above scenario. It’s rather the incongruent coping style that makes the situation really bad. Let’s explore why blaming is a problem in software development in general.

Virginia Satir described how congruent communication happens. In each conversation there is your own position, there is the position of your communication partner, and there is the context around the conversation that you are having. If you leave out one (or more) of these three aspects – the self, the other, or the context – you get incongruent communication. For example, if I don’t consider my own position in the software development project, then I’m likely to placate whatever my manager says I should be doing. Thereby I may even start to sacrifice my private life, or my marriage – not a very good way to cope with software development in the long term.

Now, blaming happens when I stop to consider the other position in the conversation. For example, I may get a big bonus if I get the project declared as done by end of the week. If I forget about personal problems of my co-workers, I may be asking them to work heavy overtime, so that I get my bonus. Yet another blaming way of coping with a situation is to rush the design document in order to declare the project phase “Design” as complete. In this case I forgot to consider the programmers, the testers, and the end users, who have to live with the outcomes of this poor decision.

Now let’s relate this to the situation in the waterfall development theory above. If a project is heavily overdue and pressure on management and the project team is heavy, then it’s possible to forget about the other views on the project. Programmers blame testers for being too late, testers blame programmers for being late, both blame designers for delivering incomplete designs, and the requirements analysts did maybe a poor job by not foreseeing the new requirements from the customer two years ago.

But does this solve any problem?

No, it doesn’t. Instead of blaming it’s worth to spend some time and take the empathic position. What did your co-worker do? Why did she do it? Why didn’t she do X? Or Y? What would have been the outcome? What has changed between when she did what she did and now? What would I have been doing in that position?

Often these considerations open up ways to see that Norm Kerth’s Prime Directive applies:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

At the point where you understand the empathic position, you can start to look for better ways to develop software. And this is why inspect and adapt has a central role in successful software development. In Agile software development it’s one of the core principles.

For more on blaming, the AYE Conference provides a great source. Gerald M. Weinberg wrote an article back in 1996 on Beyond Blaming. During the last year he re-visited blaming with co-author Don Gray, providing an article on The Blame Game. Both are very useful to read, for programmers, testers and managers. For more on the topic, Quality Software Management Volume 3 – Congruent Action goes into way more detail on the topic.