It seems that several coaches/gurus/consultants/experts use the term “the team” frequently in discussing their work. AS IF there was one, and only one, team: “let the team decide“, “meet the team’s needs“, etc. In complex orgs, there is NOT solely one team. There are many diverse teams and team types. Thus, as expected, their needs can, and do, clash.
To simplify the ensuing, one-way, BD00-to-you discussion, assume the existence of only three different team types:
Just like an individual must sometimes relinquish/suppress a personal need(s) for the greater good of the team, a particular team type must sometimes eschew one or more of its needs for the greater good of a different team type. In darker times, sometimes ALL teams must sacrifice some of their needs for the greater good of the “whole“. After all, if the “whole” goes bust, then all the teams being sustained by it go bust too. In a robust org, the converse is not true: if one team fails, the org will live on.
Is it possible to simultaneously satisfy every single need of each individual, each team, each team type, and the meta-physical “whole“? Since some idealistic people seem to think so, I suppose so – but I’m highly skeptical. The universe has always been, and always will be, gloriously messy. Because of the unavoidable human diversity residing within and across team types, a delicate give-and-take balancing act is necessary to keep the whole intact. Sometimes I gotta give to you and sometimes I gotta take from you. Sometimes you gotta give to me and sometimes you gotta take from me.
Thanks to twitter friend @SerialMom, I recently learned of the existence of Brandolini’s law:
Damn, I wish I thought of that!
Sometimes, in the case of interacting with peers and colleagues, it may indeed be worth expending 100 units of your energy to flush 10 units of bullshit down the terlit. However, with management, don’t even think about refuting 1 unit of managerial-generated BS with 2 units of your intellectual energy – unless you want to get bitch-slapped down. Attempting to refute 100 units of management BS with 1000 units of your personal energy is downright suicidal.
At its core, process agility is all about continuous learning, fast feedback loops, and fluid changeability. Unlike pre-agile methods (and even some currently purported agile methods), which assume that people are forward-marching automatons who “better not make mistakes” and must defend the fort against all external forces of change, process agility accommodates the mental limitations and fallibility of REAL human beings.
Having said that, how agile do you think a process which includes a sign-off list like this is:
Imagine that whatever has been “approved” by a ceremonial sheet like this is post-facto found to be laced with errors, inconsistencies, and ambiguities due to natural human fallibility. How likely do you think that finders-of-mistakes will publicly point them out, demand a production line stoppage to fix the turds, and suggest that the director-manager-lead approval gauntlet be traversed again? Conversely, how likely do you think that finders-of-mistakes will say “f*ck-it!“, keep their mouths shut, and keep goose-stepping forward with the herd.
Fear not, dear reader. BD00 has a simple and clean solution to the director-manager-lead approval gauntlet problem. Collapse the list of approvers down to one – the only one that matters:
Please submit your plans for BD00 approval in the comments section. As his executive assistant, I can assure you that his stamp/no-stamp decision will be made pronto. However, don’t call us. We’ll call you.
On a 90 degree day a couple of weeks ago, I hired a crew to come out to my house and seal my driveway. In lieu of cash, I gave the team this bucket o’ joy as a tip….
Induction is the process of synthesizing a generalization from a set of particulars; a mental step up in abstraction from many-to-one.
Deduction is the process of decomposing one generalization into a set of particulars; a mental step down in abstraction from one to many.
A good personal software design process requires iterative execution of both types of sub-processes; with liberal doses of random reflection thrown into the timeline just to muck things up enough so that you can never fully retrace your steps. It’s pure alchemy!
When all is said and done, more is said then done. – Unknown
Savvy politicians and bureaucrats seem to always say the right thing, but they rarely back up their proclamations with effective action. In “Military’s focus on big systems is now killing us”, DARPA Director Arati Prabhaker states the patently obvious:
The Pentagon must break this monolithic, high-cost, slow-moving, inflexible approach that we have.
Well, duh! I’ve been hearing this rally cry from incoming and outgoing appointees for decades.
Yet another insightful DARPA director states:
The services have largely failed to take advantage of an emerging “software-defined world.” The result has been skyrocketing weapons costs.
Say what? “Sofware-Defined World“? I must have missed the debut of this newly minted jargon. The “Internet Of Things” and its pithy acronym, IoT, must be so yesterday. The “Software-Defined World“, SDW, must be so today. W00t!!
If you read the article carefully, you’ll see that the interviewees have no clue on how to solve the grandiose cost/schedule/quality problems posed by the currently entrenched, docu-centric, waterfall (SRR, PDR, CDR, Fab, Test, Deploy) acquisition process and, especially, the hordes of civil servants whose livelihoods depend on the acquisition system remaining “as is“. But BD00 does know how to solve it: Certified Scrum Master and Certified Product Owner training for all!
“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” – Leslie Lamport
I’ve always loved that quote. But that’s only one reason why I was overjoyed when I stumbled upon this article written by Turing award winner Leslie Lamport: “Why We Should Build Software Like We Build Houses”. The other reason is that what he wrote is old school, but still relevant in many contexts:
Most programmers regard anything that doesn’t generate code to be a waste of time. Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code. Before we start to write any piece of code, we should understand what that code is supposed to do. Understanding requires thinking, and thinking is hard. – Leslie Lamport
I recently modified some code I hadn’t written to add one tiny feature to a program. Doing that required understanding an interface. It took me over a day with a debugger to find out what I needed to know about the interface — something that would have taken five minutes with a spec. To avoid introducing bugs, I had to understand the consequences of every change I made. The absence of specs made that extremely difficult. Not wanting to find and read thousands of lines of code that might be affected, I spent days figuring out how to change as little of the existing code as possible. In the end, it took me over a week to add or modify 180 lines of code. And this was for a very minor change to the program. – Leslie Lamport
New age software gurus and hard-core agilistas have always condescendingly trashed the “building a house” and “building a bridge” metaphors for software development. The reasoning is that houses and bridges are made of hard-to-reconfigure atoms, whilst software is forged from simple-to-reconfigure bits. Well, yeah, that’s true, but… size matters.
In small systems, if you discover you made a big mistake three quarters of the way through the project, you can rewrite the whole shebang in short order without having to bend metal or cut wood. But as software systems get larger, at some point the “rewrite-from-scratch” strategy breaks down – and often spectacularly. Without house-like blueprints or bridge-like schema to consult, finding and reasoning about and fixing mistakes can be close to impossible – regardless of which state-of-the-art process you’re using.