Now imagine adding a silly clown, with a silly clown-sized oar, into the mix. Imagine that the silly clown has no accountability to the crew, but has been ordered by a chief clown to stick his oar in.
The silly clown is ill-equipped since his oar is clown-sized. It’s immediately evident he derives no pleasure from helping you or your crew-mates propel the craft. He only wishes to demonstrate his paddlry.
The boat slows, then sharply veers off course.
In the Agile software realm, the clown with the clown-sized oar, is one flavor or another of architect (see The Chicken & The Pig). He fancies himself as a title rather than an agent noun. You can be certain he’s not on your team. If he was, he’d be called a developer…a developer who’s accountable to produce working software, rather than artifacts.
For every wildly productive Agile project, I wonder if there are about five or so that have gone off the rails into dysfunction junction. It bears repeating that the Agile Manifesto has four easy-to-understand guiding principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Easy to understand, but challenging to implement.
It’s a personal quirk, but one of my red flags is when people pronounce Agile with a long “i”. There are other red flags, some funnier than others.
Sometimes red flags make me long for the white flag of surrender, then I remember practice and discipline.
I’m not a musician. Yet it’s clear there’s a distinction between loving the promise of sweet music and coaxing a coherent tune from a Stradivarius. The hard work can’t be skipped. The practice can’t be ignored.
I’m not an Agile software coach. CIOs who have the foresight to hire a coach to kick off an Agile adoption should be commended. Hiring a coach for Agile 101 sessions is like learning to play scales. Necessary, but not Mozart.
Without continued practice in Agile discipline, well-intentioned people revert to putting in more overtime while getting less done. Stand ups revert to sit-ins.
CIOs who conceive of an Agile adoption as a few cheerfully upbeat coaching engagements are mildly delusional. A realistic Agile adoption probably means a minimum 6-month slog by an embedded coach (or coaches).
If the principles are easy-to-comprehend, why is it so difficult to make it work? One impediment is people don’t have ownership. Most organizations pay a bunch of salaried folks to ponder what they’d rather be doing. They don’t give a rip about agile-smagile.
I’m glad I’m not talented enough to be a coach, because
What do you do with well-meaning folks who couldn’t lift a feather in zero gravity?
Red Flags & Cadence
Your execution of agility might be poised to implode if your organization
- prefers spreadsheets or software tools over low-fidelity PostIts and a Story board;
- can’t seem to re-purpose the static and limited title of architect into something helpful;
- separates the people using the software from the people developing the software;
- seems ladened with command & control management who are cynical about change;
- doesn’t comprehend the poignant parable of The Chicken & The Pig;
- is reactive & accusatory, rather than thoughtful & nuturing.
If you recognize these, I urge you to hire a long-term Agile coach (or coaches). Ideally this person is half rock-star developer and half rock-star psychologist. With any luck, this person is also willing to slog it out in the trenches for months into years.
I suspect iterative cadence comes from something akin to an athlete’s muscular memory. If that’s the case, then think about, and retrospectively examine, how your behavior, your team’s behavior, and the organization’s behavior, reflects the four guiding principles in the Agile Manifesto.
Give it time and practice. Focus on the four guiding principles. Minimize distractions. Row, row, row your boat…every day, every week, every month.