Archive
Explaining Vs Training
I haven’t ranted against the software con$ultant industry in a while, so I decided that now is as good as ever to do it again. To that end, I submit Twitter exhibit A to the jury:
I guess that “explaining” how to do a stand up meeting to executives in which 3 simple questions are asked/answered only takes 5 minutes, but “training” them how to do it takes an intensive, four day on-site course at $2K per day… plus expenses.
As a general observation, consultants love to make the obvious and mundane look like a complicated and unfathomable hairball that only they can unravel for you, at a “fair” price.
First Confuse Them, And Then Unconfu$e Them
I don’t understand it. I simply don’t understand how some (many?) Scrum coaches and consultants can advocate dumping the words “estimates” and “backlogs” from Scrum.
The word “estimate” appears 9 times in the 16 page Scrum Guide:
- All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
- The work done on them depreciates quickly and must be frequently re-estimated.
- Work may be of varying size, or estimated effort.
- Product Backlog items have the attributes of a description, order, estimate and value.
- Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog
- More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
- The Development Team is responsible for all estimates.
- ..the people who will perform the work make the final estimate.
- As work is performed or completed, the estimated remaining work is updated
As for the word “backlog“, it appears an astonishing 80 times in the 16 page Scrum Guide.
People who make their living teaching Scrum while insinuating that “estimates/backlogs” aren’t woven into the fabric of Scrum are full of sheet. How in the world could one, as a certified Scrum expert, teach Scrum to software development professionals and not mention “estimates/backlogs”?
Even though I think their ideas (so far) lack actionable substance, I have no problem with revolutionaries who want to jettison the words “estimates/backlogs” from the software development universe. I only have a problem with those who attempt to do so by disingenuously associating their alternatives with Scrum to get attention they wouldn’t otherwise get. Ideas should stand on their own merit.
If you follow these faux-scrummers on Twitter, they’ll either implicitly or explicitly trash estimates/backlogs and then have the audacity to deny it when some asshole (like me) calls them out on it. One of them actually cranked it up a notch by tweeting, without blinking an e-eye, that Scrum was defined before Scrum was defined – even though the second paragraph in the Scrum guide is titled “Definition Of Scrum“. Un-freakin-believable.
Sorry, but I lied in the first sentence of this post. I DO understand why some so-called Scrum advocates would call for the removal of concepts integrally baked into the definition of the Scrum framework. It’s because clever, ambiguous behavior is what defines the consulting industry in general. It’s the primary strategy the industry uses very, very effectively to make you part with your money: first they confuse you, then they’ll un-confuse you if you “hire us for $2K /expert/day“.
…and people wonder why I disdain the consulting industry.
The best book I ever read on the deviousness of the consulting industry was written by a reformed consultant: Matthew Stewart. Perhaps you should read it too:
Loneliness Mitigation
As a programmer who devilishly loves to poke the “agilencia” in the eye on Twitter, I sometimes feel like a lone wolf searching for a pack to join.
In order to cure my loneliness, I decided to lure some fellow programmers out of the shadows to see where they stand. Thus, I seeded my timeline with this provocative tweet.
Looky here! I somewhat succeeded in achieving my goal of “loneliness mitigation”:
Don’t get me wrong, I really like and admire some members of the non-programming agilencia. I’m actually sorry that I used the the word “majority” in my seed tweet.
I Dunno
A dear twitter friend recently sent me a link to this case study written by a LeSS management consultant: “Thales Surface Radar”. Since I’ve been an active contributor to the development of multi-million dollar air defense and air traffic control radars for decades, I was excited to finally see a case study directly applicable to my domain of interest.
On my first reading, I found it difficult to separate the wheat from the chaff. Sadly, I experienced the same frustrating feeling on my second read-through – even though I slooowed down and arduously tried to absorb the content. Honestly, I tried, I really tried. I’m just not smart enough to “get it“. No “ah-hah!” moments for BD00.
I think the case study is just another self-promoting, fluffy, smoke-and-mirrors piece written by a stereotypical consultant who wants your money. What do you think?
By How Much?
Thanks to a social media friend, I was directed to an agile transformation case study written by a management consultant and posted on the consultancy’s site along side several other huge success stories. At the end of the long writeup, the following outcomes were asserted:
When I see fancy, professionally-crafted, “qualitative” success lists like these, knowing that they are touted by highly subjective people whose livelihoods require the projection of infallibility, my BS detector starts beeping. For this specific list, these questions come to mind:
- “Feature time-to-market has been reduced“: by how much?
- “Ability to release frequently has been increased“: by how much?
- “Technical debt has been reduced“: by how much?
- “Reactivity to portfolio prioritization is much improved“: by how much?
- “WIP has been reduced”: by how much?
- “Morale is strongly improved within and between teams“: by how much?
- “Trust between sites is improved“: by how much?
- “The dispersion of development over many sites has been reduced“: by how much?
- “Global product and technical leadership is visible“: by how much?
- How much did this 18 month transformation cost the client? How much money did you make?
- How much have client revenues increased and costs decreased as a result of your effort?
Of course, no quantitative percentages were given because no pre-transformation benchmarking was performed. If benchmarking was indeed performed, there would’ve been a chance that the before-and-after metrics may have driven the client to conclude that the whole effort was a huge waste of time and money.
It’s funny how managers who love to hold others accountable for adhering to micro-defined, quantitatively specified, burndown charts, not only get to evaluate themselves, but they get to do so qualitatively, with no supporting data.
In God we trust; all others must bring data. – W. E. Deming
In Consultants we trust; all others must bring data. – BD00
The Ridiculously Obvious
Over the years, I don’t know how many times I’ve heard smug, self-important consultants and coaches spout things like: “If your org doesn’t do what I say and/or you don’t get what you want, you should just leave“. Of course, like much of what they say is, it is literally true – you can indeed leave. However, here’s an interesting counterpoint:
“To say people have choice when they are in no position to make one is disingenuous.” – John Seddon
Consultants and coaches love to spout platitudes and self-evident truths couched in the fancy “new” language of the latest fad. Amazingly, stating the ridiculously obvious is what they get paid the big bux to do. To these high-horse riders, life for others is always much simpler than it really is. As outsiders looking in, they have what Nassim Taleb calls: “no skin in the game“. The only thing they have to concern themselves about is sucking up enough to the executives who run the show so that they can get hired back after their $2k/day gig is done. And saying the right things, no matter how impractical they are to implement, is the way they do it.
Innovation Types
In the beginning of Scott Berkun’s delightful and entertaining “Managing Breakthrough Projects” video, Scott talks about two supposed types of innovation: product and process. He (rightly) poo-pooze away process innovation as not being innovative at all. Remember the business process re-engineering craze of the 90’s, anyone? Sick-sigma? Oh, I forgot that sick-sigma works. So, I’m sorry if I offended all you esteemed, variously colored belt holders out there.
According to self-professed process innovators, the process innovations they conjure up reduce the time and/or cost of making a product or performing a service without, and here’s the rub, sacrificing quality. Actually, most of the process improvement gurus that I’ve been exposed to don’t ever mention the word “quality”. They promise to reduce time to market (via some newfangled glorious tool or methodology) or cost (via, duh, outsourcing). Some of these snake oil salesmen dudes actually profess that they can increase quality while decreasing time and cost.
The difference between a terrorist and a methodologist is that you can negotiate with a terrorist – Unknown
Most process improvement initiatives that I’ve been, uh, lucky(?) to be a part of didn’t improve anything. That’s because the “improvements” weren’t developed by those closest to the work. You know, those interchangeable, fungible people who actually understand what processes and methods need to be done to ensure high quality.All that those highly esteemed, title-holding, mini-Hitlers did was saddle the value makers and service providers down with extra steps and paperwork and impressive looking checklists that took away productive time formerly used to make products and provide services.
Process improvement is a high-minded, overblown way of saying “kill the goose that laid the golden egg before it lays another one“.
Man, These Guys Are Good
In general, I think that management consultants are way overpaid and full of themselves. These bozos with fat heads come waltzing in to a company in trouble and:
- analyze the “situation” from afar without getting their hands dirty,
- dispense all kinds of “proprietary” voodoo advice,
- collect their fee,
- and then bolt – leaving the ineffective corpocrats (who caused the mess in the first place) to clean up their own dung.
Notwithstanding the vitriolic diatribe in the previous paragraph, I think the following consulting dudes are the real deal: Vital Smarts. They’re people-oriented instead of mechanistically process-oriented. Collectively, they’ve talked with tens of thousands of workers; from the dweebs in the cellar to the exalted royalty in the corner of the building. They’ve also analyzed a ton of academic research to derive some down to earth, pragmatic, and potentially actionable direction for everyone – not just the patriarchs who direct the horror show. I’ve read all of their terrific bestselling books:
I’ve actually tried to employ their teachings in an attempt to be more effective in the workplace, but Ive failed miserably. Of course, it’s not their fault. It’s me and my “Unshakeable Cognitive Burden” of negativity toward all man-made command and control hierarchies.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 