Archive

Posts Tagged ‘consultants’

Explaining Vs Training

November 8, 2016 Leave a comment

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:

standuptraining

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.

excellent

Categories: management Tags:

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:

  1. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
  2. The work done on them depreciates quickly and must be frequently re-estimated.
  3.  Work may be of varying size, or estimated effort.
  4.  Product Backlog items have the attributes of a description, order, estimate and value.
  5. Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog
  6.  More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
  7. The Development Team is responsible for all estimates.
  8. ..the people who will perform the work make the final estimate.
  9. 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”?

certified scrum

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.

TOC

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:

TMM

Loneliness Mitigation

September 13, 2015 Leave a comment

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.

seed

Looky here! I somewhat succeeded in achieving my goal of “loneliness mitigation”:

programmers

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.

Categories: technical Tags: ,

I Dunno

August 10, 2015 Leave a comment

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.

Dunno

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?

Less Msgs

Contractors

SizeCultureDiffs

Categories: management Tags: ,

By How Much?

June 27, 2015 6 comments

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:

Xform Outcomes

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.

huge success

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

March 15, 2014 8 comments

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.

The Obvious

Innovation Types

August 3, 2010 Leave a comment

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“.

%d bloggers like this: