Archive
A Quarter Of An Hour
Looky here at what someone I know sent me:
This person is working on a project in which management requires time tracking in .25 hour increments. On some days, that poor sap and her teammates spend at least that much time at the end of the day aggregating and entering their time into their formal timesheets.
Humorously, those in charge of running the project have no qualms about promoting their process as “agile“.
I can’t know for sure, but I speculate that the practice of micromanagement cloaked under the veil of “agile” is pervasive throughout the software development industry.
The Unwanted State Transition
Humor me for a moment by assuming that this absurdly simplistic state transition diagram accurately models the behavior of any given large institution:
In your experience, which of the following transitions have you observed occurring most frequently at your institution?
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:
Scraditionally Speaking
Gee, look at all those fancy, multidividual contributor titles. And then there is the development team, a.k.a the title-less induhvidual contributors.
Checklist Of Maladies
Since I can’t remember where I poached this “checklist of maladies” from, I can’t give any attribution to its creator(s). I’m sorry for that, but I wanted to share it anyway:
I do, however, remember that the presenter was talking about agile processes gone awry.
It’s funny how these maladies have been around forever: pre-agile and post-agile. Resilient little cockroaches, no?
Better
Consider a classic, straight-line, hierarchical organization:
Because of the structure of the vertical communication links that tie the org together into a system, the dudes at the top are guaranteed to have a distorted understanding of what the dudes at the bottom are doing – and vice versa. With no direct lines of communication between non-adjacent layers, how could it be otherwise?
Of course, everyone who has ever toiled in the lower layers of such a “classic” hierarchy has railed against what they perceive as the unfairness and inhumanity of participating in such a system.
So then, if the classic, straight-line, vertical hierarchy is so bad for those grinding it out in the lower layers, which is a better system structure:
If you’re expecting BD00 to definitively choose sides, extolling the virtues of “the good one” while denigrating the vices of “the bad one“, fuggedaboudit. There is no universally applicable “good one“. Or is there?
Scaling Up Agile
Lo and behold, the four phases of scaling up agile:
So, what are you waiting for? Whip out your checkbook and hire that LeSS or SAFe expert that’s been ringing your phone of the hook. It’ll turn out just fine.
The Real And The FAKE
Mutual Mistrust
Assume you walked into an organization and discovered a massive, productivity-sapping, mistrust between management (party A) and the workforce (Party B). Would you wonder how such a toxic environment came about in the first place? Well, it really doesn’t matter “who started it first” cuz once the self-reinforcing loop of escalating mistrust kicks into gear, all is lost.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 