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