Archive
The Reverse Butterfly Effect
Lipstick On A Pig?
Since the anecdotal evidence that I’ve seen over the years is overwhelming, I have absolutely no doubt that when Scrum is applied in the right context (e.g. small projects in unregulated industries), it works well for both managers and developers. However, when Scrum is either not applicable, or, more likely, starts out well and then degenerates over time into a textbook case of micromanagement, it reminds me of the lipstick-on-a-pig metaphor. When that perverse inversion occurs, the management team walks around touting “we’re agile“, and the development team simply….. walks around.
From Daily Standup To Daily Inquisition
Tis’ what it is. We live in the REAL world.
Perfect And Real
In the perfect Scrum world, software is developed over time in fixed-size (ΔT) time boxes where all the work planned for the sprint is completed within the timebox. Typically ΔT is chosen to be 2 or 4 weeks.
If all the tasks allocated to a sprint during the planning meeting are accurately estimated (which never happens), and all the tasks are independent (which never happens), and any developer can perform any task at the same efficiency as any other developer (which never happens), then bingo – we have a perfect Scrum world.
However, in the real world (Scrum or non-Scrum), some (most?) tasks are interdependent, some tasks are underestimated, and some tasks are overestimated:
Thus, specifying a fixed ΔT timebox size for every single sprint throughout the effort may not be a wise decision. Or is it?
What Happened Before The First Product Backlog?
Some people like to ask: “What happened before the big bang?“. Being a geeko-nerd, I like to ask: “What happened before the first product backlog?”.
Regarding agile framework definitions, IMO, Scrum has the most well-documented and coherent definition of the bunch. However, since it remains silent on the issue, I still wonder: “WTF happens before the first product backlog?”.
For innately complex systems requiring a large amount of coordinated effort, here’s what I think should happen:
- A small group of senior domain analysts and system architects should spend a fair amount of un-pressured time to develop and document the high level, technical blueprints (structures + behaviors) for what needs to be built.
- The authoring group should disseminate and educate the rest of the development team on the technical vision.
- The team should populate and iterate on the first version of the product backlog.
- The team should decide on, and put in place, the development toolset and infrastructure that will be used to develop and test the system throughout the effort.
- The team, including the technical authors, should start incrementally and iteratively building the system – revisiting/updating the plans/product backlog frequently when new knowledge is discovered as the project moves forward.
What do YOU think should happen before the first product backlog?
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.
The Real And The FAKE
Deal Of The Year
Hot off the presses, I just received a Groupon offer to take a $99 online Scrum Master certification course. Holy crap! Instead of paying $2000 and taking 3 consecutive days off from work, I can learn how to become a micro-managing process enforcer from the comfort of my own home; munching on chips while lounging around in my skivvies.
How can I refuse such a great deal? Just look at all those smart, well-dressed, professional, micro-managers in the advertisement staring at a burndown chart. It’s an especially nice touch that the marketing team put a pair of eyeglasses in Katherine Heigl’s hand.
From the course description:
CSMs understand Scrum values, practices, and applications and provide a level of knowledge and expertise above and beyond that of typical project managers.
If you’re a “typical project manager“, your days are numbered. The sky is falling and all that uncool PMI and EVM training you suffered through is sooooo yesterday.
Satirical Substitution
Here’s how a Theory-X indoctrinated manager interprets the definition of the Daily Scrum as written in the official Scrum Guide:
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 