In recounting his obsession with quality, I recall an interview where Steve Jobs was telling a reporter about painting a fence with his father when he was a young boy. There was a small section in a corner of the yard, behind a shed and fronted by bushes, that was difficult to lay a brush on. Steve asked his dad: “Do I really have to paint that section? Nobody will know that it’s not painted.” His father simply said: “Yes, but you will know.”
It is pretty much a de-facto standard in the C++ (and Java) world that enum type names start with a capital letter and that enumeration values are all capitalized, with underscores placed between multi-word names:
Now, assume you stumble across some sloppy work like this in code that must be formally shared between two different companies:
Irked by the obvious sloppiness, and remembering the Steve Jobs story, you submit the following change request to the formal configuration control board in charge of ensuring consistency, integrity, and quality of all the inter-company interfaces:
What would you do if your request was met with utter silence – no acknowledgement whatsoever? Pursue it further, or call it quits? Is silence on a small issue like this an indicator of a stinky cultural smell in the air, or is the ROI to effect the change simply not worth it? If the ROI to make the change is indeed negative, could that be an indicator of something awry with the change management process itself?
How hard, and how often, do you poke the beast until you choose to call it quits and move on? Seriously, you surely do poke the beast at least once in a while… err, don’t you?
You may not believe this, but overall, I like “agile” management and coding practices- where they fit. The most glaring shortcoming that I, and perhaps only I, perceive in the “agile” body of knowledge concerns the dearth of guidance for handling both the social and technical dependencies present in every software development endeavor. The larger the project (or whatever you #noprojects community members want to call it), the more tangled the inter-dependencies. There are, simultaneously: social couplings, technical couplings, and the nastiest type of coupling of all: socio-technical couplings.
The best analogy I can think of to express my thoughts on the agile dependencies black hole is the linear vs multiplicative complexity conundrum as expressed so elegantly by Bertrand Meyer in his book, “Agile!“. But instead of the family friendly linguini and lasagna images Mr. Meyer employs in his book, I, of course, choose to use imagery more in line with the blasphemous theme of this blog:
The complexity of the system is at least equal to the product of the problem and solution complexities. At worst, there are exponents associated with one or both multiplicands.
Quick, quick! What role is missing from the classic Scrum 1.0 team configuration of developers, product owner, and scrum master?
Ooh, ooh, I know what’s missing….
Me thinks version 2.0 of the Scrum guide should include, and formally recognize, the glorious role of Agile Coach, no?
Since the Scrum Master has waaaaaaay to much to do already (running the daily 15 minute meeting and removing all those bazillions of impediments that the whiny developers willingly disclose every day), she can’t possibly fulfill the crucial role of agile coach. In addition to formal recognition, the Scrum Alliance should create a program where aspiring coaches can dole out some $$$$ to get certified.
To promote their infallible expertise, fathead consultants love to present apples-to-oranges comparisons as though they were apples-to-apples comparisons. One such prominent consultant (hint: a famous Forbes columnist) recently gushed over the success of music provider Spotify.com; contrasting its success to the team that built the buggy, slow, initial, version of the healthcare.gov web site.
As is almost always the case, these clever dudes leave out the oft-hidden, process-independent, contextual, forces that relentlessly work against success:
To imply that the Healthcare.gov team would have been successful if they simply employed agile practices (like Spotify.com) is to either be naive, disingenuous, or both.
Have you noticed that the press isn’t clamoring over the inadequacy of the healthcare.gov site anymore? Obviously, the development team must have righted the ship by morphing into a high performing juggernaut under the tutelage of a cadre of agile process consultant(s) – regardless of whether they did or they didn’t.
I’ve been waiting patiently (freakin’ impatiently?) for 10+ years for some word, any word, to dethrone “agile” as the most frequently seen word on book, video, and article titles in the software industry. Thanks to the highly esteemed Gartner consulting firm, perhaps we have a viable candidate:
“Bimodal IT refers to having two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Mode 1 is traditional, emphasizing scalability, efficiency, safety and accuracy. Mode 2 is non-sequential, emphasizing agility and speed.” – Gartner IT Glossary
Personally, I like the word “Tradagile” better than “Bimodal“. It’s lighter, less stuffy.
I’m goin’ Bimodal! W00t!
If you feel you have something to offer the world, the best way to expose and share your ideas/experiences/opinions/knowledge/wisdom is to release it from lock down in your mind and do the work necessary to get it into physical form. Write it down, or draw it up, or record it. Then propagate it out into the wild blue yonder through the greatest global communication system yet known to mankind: the internet.
You are not personally scalable, but because of the power of the internet, the artifacts you create are. Fuggedabout whether anybody will pay attention to what you create, manifest, and share. Birth it and give it the possibility to grow and prosper. Perhaps no one’s eyeballs or ears other than yours will ever come face to face with your creations, but your children will be patiently waiting for any and all adopters that happen to come along.
The agilista community is fond of trashing the “traditional” artifact-exchange method of communication and extolling the virtues of the effectiveness of close proximity, face-to-face, verbal exchange. Alistair Cockburn even has some study-backed curves that bolster the claim. BD00 fully agrees with the “effectiveness” argument, but just like the source code is not the whole truth, face-to-face communication is not the whole story. As noted in the previous paragraph, a personal conversation is not scalable.
Face to face, verbal communication may be more effective than artifact exchange, but it’s ephemeral, not archive-able, and not nearly as scalable. And no half-assed scribblings on napkins, envelopes, toilet paper, nor index cards solve those shortcomings on anything but trivial technical problems.
Well… that’s not exactly the original picture. I took the liberty to paste Bulldozer00’s puss over the machine operator’s face. It simply felt like the right thing to do.
That picture is much more apropos than you think. When I golf, I seem to always hit my balls into debunker!