Since the end of Netdosis I've been thinking about what to do now for a living. I've known for a while that I couldn't just go back to Agile coaching - but I didn't know why my feelings against it were so strong. So I sat down, did a lot of reading and a little bit of thinking, and presented my after-the-fact rationalization in the form of a talk given twice, once in English and once in German (video of the talk). Here's the digest, combined with the insights I got from all the feedback.
I make my case by bringing forward three claims:
Let's consider the points in more detail:
During the last decade there have been many attempts within Software Engineering to copy medicine's approach of proving that a drug or a therapy works to the benefit of patients. Clinical trials are supposed to be the backbones of Evidence-Based Medicine; in order to be reliable those trials must follow strict rules, some of which are: randomness, triple-blindness, adequacy of study groups and the usage of real endpoints.
The equivalent of clinical trials in empirical software research are called controlled experiments. There were experiments on pair programming, test-driven development and a few other techniques. You might want to read Making Software) for typical examples or The Leprechauns of Software Engineering for bad, invented and badly interpreted ones.
The problem with programming experiments is that they sometimes randomize participants, but they usually - if not always - fail to gather adequate study groups and fail to use real endpoints:
Whereas those two problems could theoretically be overcome by pouring enough money (think: Millions of Euros) into a study to sponsor a few dozen teams of professional software developers who evolve the same kind of system for - say - five years, there is one flaw in programming experiments which IMHO cannot be got rid of: the lack of blindness. Can you imagine yourself developing software TDD-style without knowing you're using TDD? When you don't have (triple-)blindness, any result of your experiment might come from the technique under research or it might come from some unknown contextual circumstances, aka placebo effect. You will never know!
This fundamental difference to (some type of) medical therapies leads me to the conclusion that controlled experiments will NEVER be able to prove that one development practice works better than another one mostly independent from its context. But please... Do not confuse this lack of proof with proof for the opposite.
Conclusion No.1: Since we have no basis for claiming that Agile will work any better than what our coaching clients are doing now it is unhelpful and misleading to say (to a client or in public) that "Agile is better than X" - for any X. We can only judge the efficacy of our interventions on a case by case basis - this is a whole different approach to scientific action.
If our current methods of Agile coaching worked as advertised, by now there'd be thousands of organizations with a severalfold increase in productivity and a self-sustaining, self-optimizing Agile process. Instead, organizations spend millions on coaching and training just to obtain a few percent improvement regardless what you measure. And many times, the negative effects on a company will not even be considered.
One of the main sources of adverse effects is the agile utopia; as Agilists we promise a lot: higher productivity, happier employees, satisfied customers etc. In next to no cases we can keep all those promises, and we'll thereby create a bunch of disillusioned and disappointed people. Those will either stay (and henceforth be demotivated) or leave; neither is usually in the best interest of the organization at hand.
What's more, our utopia is other people's dystopia. Going back to open-plan offices, working with competitive colleagues on a minute by minute basis and having to report their "progress" every single morning, might look like a nightmare to many. Those will either stay (and try to sabotage the change) or leave; neither is usually in the best interest of the organization at hand.
There are many more ways to do harm by forcing the Agile way:
One last thing about the unwanted side-effects of treating our clients with the Agile medicine: There are many valid reasons for people to not change (right now or in the way we want them to). "People over Process" should teach us to respect that.
Conclusion No.2: Before and while we're applying Agile drugs and surgeries, weighing risks vs benefits is one of our most important duties.
We Agile pundits are so convinced of our theories why Agile practices are superior that we tend to develop a huge blind spot in our vision and just don't see how people succeed with different approaches - or we dismiss their success as pure luck, or as un-sustainable or as a rare edge case. To get you started here's a few "un-agile" practices I've seen work reasonably well:
Moreover, parts of our Agile "theory" are just made-up. E.g. scrutinize the "evidence" for the "perfect" team size of 7+/-2. Afterwards, try to validate the alleged flattened cost-of-change curve with empirical data.
Conclusion No.3: There is no lack of pundits in the field of software development. Most of them are one-sided and bring their improvised theory and ready-made solutions to the table. That way they tend to promote their preferred solution without having understood the problem in the first place. Agile consultants are no different.
Bashing the state of the art is easy. Doing things better is a lot trickier. This is what I'm going to try:
Professionals - like consultants, coaches, trainers or investment counselors whose main activity is to give advice - all operate under a common pattern: They benefit from the upside of their job, i.e. they get money for advising. Sometimes they even get more money when their client seems to benefit more. Their client, however, has to bear all the risk. When the client looses money, the consultant will - in the worst case - not get their pay. Have you ever seen a CEO of a stock corporation who will cover essential parts of "his/her" company's loss?
This asymmetry in risk is especially tragic because it is mirrored by an asymmetry of information: The consultants are experts in their field - and therefore have more knowledge about the risks than their clients do. We can spot this asymmetry in all kinds of dysfunctional and immoral behavior - the financial crisis being the most prominent example.
An effective solution to this problem is to put people's skin in the game. Here's an example from the Code of Hammurabi: "If a builder builds a house and the house collapses and causes the death of the owner of the house, that builder shall be put to death." This approach works in two ways:
The idea is ancient but it recently got fresh support from Nassim N. Taleb, e.g. in Antifragile and The Skin In The Game Heuristic. Taleb claims that it's the moral thing to put your skin in the game even if your customer does not require it. The question remains...
Be the first customer of your product. Founding a software-based start-up is one means to do that, investing serious money in your client's is another.
Never teach or advise something that you either haven't done yourself before or wouldn't do if you were in your students' shoes. For full-time trainers or teachers this can be hard.
Become an employee. Most employees have more skin in the game than the outside consultant. Being employed without invested can only be a first step, though.
Attach your compensation to your client's long-term satisfaction. E.g. add a massive refunding clause to your contracts - and explain it to your customer.
Personally, I am at the very beginning of putting my skin into the game: I've removed a few technical topics from my portfolio in which I'm only well-read - but not invested. I've made the experience that the mere suggestion of adding a refunding clause into the contract changes the communication style. People, especially managers, do not expect others to willingly take a share of their risk.
Agile is still (one) part of my professional life but calling myself Agile is not. Putting more skin into my professional life is dear to my heart: Don't follow my advice, look at what I do.