Cadence is Crucial

There's a delightful book called If You Give a Moose a Muffin. My forthcoming missive on iterative software development is tentatively entitled

If You Give a Clown a Metric

Cadence is the most important aspect of iterative software development. I am weary of misconceptions about velocity. I'm weary of re-treaded PMs turning velocity into a blunt instrument.

The Law of The Swift

Cadence is the vastly under-reported life-force behind iterative development.

So, two days into your second sprint, if your panic-strickened PM adds two new developers, then prods & pokes you about squeezing in another story or two, I advise you to diplomatically offer the reminder that

Half a Swift DOES NOT deliver twice the gas mileage.

This regressive misconception is formally known as Brook's Law. Brook's law says,"adding manpower to a late software project makes it later".

Brooks more famously quipped

Nine women can't make a baby in one month
~Fred Brooks

In the absence of distractive churn, seasoned developers need at least several iterations to establish a cadence. Forget the silly chart.

In honor of the 10th anniversary of the Agile Manifesto, developers who have, year after year, dragged dysfunctional balls & chains to the delivery finish line should not have to view another burn-down chart.

Adding a new developer mid-iteration is disruptive. Adding two new developers mid-iteration is, not surprisingly, also disruptive. Please don't knock us off the beat. Let us play a few bars into the tune before you pull the fire alarm.

All we ask as developers is that succinct stories with a bulleted list of testable assertions roll into our purview like so many chocolate kisses on a conveyor belt. Then, please step away from the conveyor belt so we can syncopate while gorging on chocolate kisses.

It's a Marriage, Not a Stew

I'll use a horse racing analogy to illustrate a common Agile software #fail scenario:

• The developers are thoroughbred horses, with rapid metabolisms, who are impatiently cantering.
• The owners & the trainers over-value the necessity of their contribution. They stumble out of the gates while arguing about the fat and fiber content of the feed.

Some owners & trainers would be better off keeping draft horses. Those needing to stay in the race might consider some of the causes of this churn:

1. Owners & trainers haven't a clue how to prioritize races.
2. Owners & trainers involve champion horses in a swirl of the inconsequential.
3. Owners & trainers segregate their horses into costly horse barns.

Prioritize Races

Much has been written about prioritizing stories for iterations that doesn't bear repeating. Suffice it to say, if you're a business owner who's unable to queue up what needs to be built, please spare us the absurd sauntering by finding another line of work.

Developers sniff out incompetence in a single ill-prepared meeting. They sense when you are in over your head - often before you do.

If you can't establish credibility out of the gate as someone who has a systems view, and who understands how to set priorities, you're toast.

Shelter From the Swirl

Why do managers embark into Agile without bothering to comprehend the principles?

The mechanics of Agile become a weapon when the principles of Agile are disregarded.

When managers are in over their heads, they rope potentially productive developers in invariably unproductive meetings. In those meetings, managers unintentionally expose their shallow understanding of the problem space (what) and their lack of vision (why) about the product. This is near fatal.

IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.
~Jeff Ello

Once developers sense you're a shallow paper horse, all bets are off.

Don't conduct story mapping, iteration planning, daily stand-ups, or retrospectives until you understand their purpose, their necessity, and how they apply to your situation.

Segregation of Expertise

Don't do it. Segregate software expertise at your peril.

Everyone is, or has the potential to be, a soup-to-nuts developer. Good developers are much more than programmers. A good developer can be craftsman-like. I have worked with developers who care as much about test-driven development as user experience.

There is scant justification for separating people into expertise bins. There is scant justification for fire-walling user experience considerations, or data design considerations, from the development team.

If you're a technical person, but not on the development team, you're an outsider with an opinion.

Fahgettaboudit. Forget your data architects. Forget your user interface bozos. Forget your user experience schlubs. Your application deserves the attention of all of those considerations, but not in the form of extra-team "experts" with no skin in the iteration.

Everyone is a developer with varying degrees of exposure to the aforementioned skills.

Do find and nurture well-rounded developers. Better to find and nurture well-rounded developers, multi-faceted people, than to stable a bunch of experts with no skin in your iterations.

This is a marriage, not a stew
~Alan Cooper