Frankly, the idea that originated this blog post is not mine. It has all started with some observation (unfortunately, I can't recall the author, but maybe some of you, readers, will help me with that, for the sake of correct attribution) made in one of the heated Internet discussions on "to Scrum or not to Scrum". I'm not able to quote the exact words, but I'll do my best to preserve the intent and idea behind them:
"Scrum was invented, defined, and marketed by professional consultants. It was built upon the (well-deserved) criticism (of traditional methods), it sounded super-reasonable (and simple-enough), but it was never a community invention, based on feedback-fed experience gained while building a successful (long-term) product."
This statement doesn't apply only to Scrum. Pretty much all the "hyped" general software craftsmanship trends of recent two decades started (and developed) this way. Other similar examples: DDD, microservices, event-sourcing, functional programming.
Hmm, what's wrong with that?
No, I mean no disrespect to people like Schwaber, Evans, or Fowler. Quite the opposite, they are men of exceptional experience, great wisdom, and brilliant smarts - nevertheless, they are consultant models:
- they may have the best of intentions, but ... their ownership is over the project (fixed-term/fixed-result agreement), not a long-term product success
- they need "signature moves" (methods, frameworks) to stand out - "know-how marketing" is a part of their roles
Wildly successful consultants do not necessarily translate into wildly successful customers. In fact, if I had to coin an oversimplified and overgeneralized statement about that, I'd say that:
- Wildly successful (avant-garde) product companies build (their unique value) stuff on their own ("missionary style").
- Consultants are in-demand for those who may have big ambitions but don't know how to solve their problems/achieve their goals, so they need mercenaries to help with that. The problem is that the mercenary will give you advice that is exactly as good as the one (s)he will provide to your competitor.
- The vast majority of the best consultants (the ones who are truly innovative, have great product/service ideas, or are just significantly more effective than others when it comes to execution) ... tend to end up building their own products (so they stop consulting).
Show off to me
We like their ("consultant thought leaders'") ideas (because they are so good in marketing to fellow software crafts(wo)men). We adore how credible they sound. We WANT their stuff to work. But take DDD (that I personally am very fond of) - can you recall a single, striking success "war story" that has popped up to back the theory up? Did any successful product company admit that they've built their achievements upon that paradigm?
The most recent example is "data mesh" - another "invention" brought in and strongly advocated by consultants (I'll skip the names, it's not hard to find out on your own). I don't have anything against those particular folks, but I chose to remain skeptical (and not add up to the hype) until I see a well-documented, real-life case study from people who:
- have implemented that concept in their product/platform
- run it long enough to learn both benefits and the REAL price to be paid (at least mid-term, so not just implementation but also tech/process/org debt and accumulated constraints)
- can summarize actual value gained + lessons learned
P.S. Nope, this article is not meant to be a total criticism of consulting (so I hope it's not perceived that way). I still think consultants are super-useful in narrowly-specialized but also highly standardized (commoditized) domains, e.g., security or implementation/integration of a particular product (think SAP or Salesforce). But I wouldn't use consultants in crafting anything intended to constitute the competitive edge of my business.
P.S.S. By 'consultants' I mean folks/companies with actual, practical expertise in technology and software craftsmanship. Not the PPT powerhouses.
