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

Why Design-Build?

In Architects & Agile Like Zen Monks & Cell Phones, I questioned the relevancy of software architects in agile.

This morning I recalled two additions we’d made to our home. Both efforts were done by a superb craftsman who, in both instances, urged us not to engage an architect.

Both projects were completed on time, within budget, and, to our ongoing satisfaction, the results are functionally and aesthetically pleasing.

The trend toward agility in the software business is mirrored by the construction industry which has been evolving for more than a decade toward a Design-Build (DB) approach. In their version of DB, one contracting firm does the design and the construction; in contrast to Design-Bid-Build, or DBB, where one firm does the design (architecture) and other firms (construction) bid on the design specification to do the work.

A 1999 study by the Project Delivery Institute at Penn State found that DB beats DBB in delivery speed and in delivering at a lower cost. See the graphs above and right.

Is an additional advantage of DB for the construction industry

the ability to change on the fly?

In days of yore before agile, I questioned the wisdom of separating designing and building into buttoned-up packages that marched in succession. I knew that

we learned things as we built

and that

we adjusted accordingly

This summer my son will participate kiln-building course where students will design and build a wood-fired kiln. He’s an architecture student who is also passionate about functional pottery.

This is his first opportunity to build a structure that will provide decades of utility to others. I wondered if it would be his last opportunity to build a structure as opposed to conceptualizing a structure.

A side-benefit of agile is the organizationally-imposed distinction between architect and developer is blurred, if not irrelevant. In well-oiled agile teams, people wear many hats. As such, successful teams behave like start-ups (i.e., from necessity, they’re too small to segment specialties, so everyone does whatever needs to be done).

Design-build is personally satisfying, even if my design contribution is only to confirm what my more conceptually gifted team-mate, was thinking.

Architects & Agile Like Zen Monks & Cell Phones?

I declare a prejudice traceable to my insecurities – I don’t favor organizational titles; in particular, the moniker Software Architect. When I read or hear Software Architect, I snicker.
“Are you too special to roll up your sleeves and get your hands dirty?” I sat in on a talk by David Hussman that was followed by a panel discussion. The talk was centered on one of my interests, evolutionary design (see my musings on evolutionary design and agile ennui).

David’s excellent talk was given in the context of agile and directed toward a large organization transitioning from waterfall to agile. The subsequent panel discussion consisted of 3 proclaimed Architects and 1 proclaimed Developer.

I was taken aback when evolutionary design was followed by a panel Q & A dominated by Architects.

Is Architect an anachronism in agile development like a Zen monk on an iPhone?

I asked the panel “Are Architects still relevant in agile development?” and “If so, what is the role of Architect in agile development?”

What I is learned is

Architects DO have a role in agile development.

The Role of Architects in Agile

Systems Integration – One compelling role is the need for someone to stitch together the over-arching quilt; particularly in organizations with distributed agile projects that have cross-project, cross-functional, and cross-departmental considerations. In that scenario, architects would track and plan – to use an old term – “systems integration”.

Removing Technical Hurdles – It was pointed out that an architect might spike on upcoming technical challenges or potential blocks. I wondered why a team developer wouldn’t do the spike, but it’s a plausible role for an architect particularly if the spike has cross-project or cross-functional considerations.

Seed & Feed Backlog – The answer I liked the most was from an architect who said he believes his role in agile is to work with the business on seeding and feeding the backlog. For example, he might suggest the infrastructure that would need to be built to accommodate upcoming stories. I don’t know how often architects work on backlog seeding, but I like the idea. Cultivating the backlog is one of the best ways to motivate and guide an agile team to commit to that proverbial drive toward the final destination.

Viewed in this light, an Architect is not gazing down on us from such a lofty perch.

Of course I would prefer more of an “elbow-grease” moniker for them like Systems Integrator, but I can live with Architect as long as I’m convinced they’re rolling up their sleeves with the rest of us lunch-bucket developers.