The 'Crazy Things' Series: Part 2 - Methods War
In the article ‘Some of the Craziest Things in Working with Methods and Frameworks’ (https://www.dhirubhai.net/pulse/some-craziest-things-working-methods-frameworks-ivar-jacobson/) I?wrote:?
The term?Methods War?has?been used “forever”, and it comes from the idea that a community supporting a particular method is competing, sometimes fiercely, with the other communities supporting other methods.
Every method has a founder,?and around him or her is a community of people supporting the method with training, coaching and maybe tooling. It works almost like a pyramid scheme – the early adopters should make the most of it. Since it is very hard to understand why one method is better than the others, the language used to sell relies on preaching and since the communities are separate,?not collaborating for the best of the industry, they remind us of sects. If reasonably successful, the founder is a great marketing and sales guy and uses such techniques to win members and clients to his?or?her sect.
Very successful founders become?gurus. I became one, so I believe I know how it works!
Some people have suggested that this is normal competition between product companies. To a large extent this is true. Success relies on not just having a good product, but more on having great marketing and great support. That is what RUP had and that is what SAFe has today.
However, there is a difference in competition between “normal products” and “method products”. Methods are mind changing, they appeal to your intellect, teaching them reminds us of preaching, explaining them usually includes a lot of hand waving, they may provide a pyramid scheme, etc. They remind us of religious sects, and the wars between such sects, of religious wars.
In some special cases you see the same phenomena among other products, for instance 20 years ago between fan clubs of Apple’s or Microsoft’s operating systems and a few years ago between Tesla or non-electric car manufacturers. I believe this is some reasons people see it as the methods war.
It is a war that is emphasized by how methodologists, people creating their own branded methods, must work to create complete methods:
1.?????Their methods are presented without having a common standard ground. The methodologists must develop their own way of describing their method – structure, vocabulary, notations, etc., yes everything is homegrown. They share almost nothing more than the alphabet.?
2.?????Since no methodologist is an expert on everything, she or he must incorporate (“borrow” or “steal”) other methodologist’s practices into her or his own method. That means rewriting other’s work. No methodologist with self-respect would do that without “improving” the practice, but these “improvements” are not always improving the practice. Usually, the original creator of the practice feels the practice is misunderstood and damaged. I have many times heard a creator of a practice say “he really has not understood the practice” about someone (in my case always a ‘he’) who has “borrowed” her/his practice.
3.?????The methodologist who “borrows” a practice from the creator of that practice doesn’t have any really good means to reward the creator. The reason for that is that he or she has rewritten the practice without support of the creator. Thus, normally the only reward is a pat on the shoulder such as a mentioning of the creator in a parenthesis or a footnote. It didn’t need to be like that. If the original practice was reused, possibly with some modifications, there would naturally be a role for the creator. A partnership would be fair, and everyone would profit because it should result in a larger market.
This is one of the crazy things Essence addresses. Essence is the common ground, adopted as a standard after hundreds of experts have navel-gazed its specification. It treats practices as first-class citizens, and methods as compositions of a set of practices selected from an eco-system of practices. It gives creators of practices a natural role in the business of software engineering.
So,?there you have it, an introduction to method wars?and how we must fight together to work against them. If you are interested in?discussing method wars and the ‘crazy things’ further, please join our LinkedIn community -?The Craziest Things in Working with Methods and Frameworks | Groups | LinkedIn.
If you want to avoid method wars, Essence provides a common ground and gives you the freedom to work in the way that suits you best. Supported by TeamSpace, you can make your workflow open, flexible and method-agnostic. Get started with Essence and Teamspace here.
--Ivar
PS: Over the years we have seen many articles on methods war, for instance between Scrum?and SAFe, ‘Method Wars: Scrum vs SAFe’?https://dzone.com/articles/method-wars-scrum-vs-safe.?
There are other articles such as ‘Software Development Methodology Wars’??https://medium.com/@CATechnologies/software-development-methodology-wars-6a27875e940f.?
Passionate about agile, DevOps, learning & knowledge sharing, serious games | Owner at SimuLearn
3 年Talking about the borrow-thing: that is 1 thing that really annoyed my the last few years. You have a common practice with known vocabulary. All of a sudden some big scaling framework thinks this is a good idea, copies it, changes a few letters/words, et voilà: they have extended their framework. But where is the reference to the author of the original practice? I hardly ever see this happen. And then, if you know these concepts or practices from before they were copied into the big book of wisdom and you want to introduce them into your own organization, because you think your organization benefits from them, the useless battle begins: "we will stick to the terminology of our scaling framework, because we don't want to confuse our users...". Can you imagine how much of an energy drain this is? I know several examples of these kinds of principles and practices.