Attention Deficit - An Organizational Disconnect

Deconstruction

Wildly productive software developers decompose confusing, and sometimes complex, feature narratives, or stories, into discrete programming tasks with verifiable endpoints.

Deconstruction of complexity, and its superficial step-child confusion, is analogous to the Divide & Conquer Algorithm.

Story tasking is rote work for developers comfortable following Agile principles. Tasking becomes a matter of iteratively (recursively in the case of the Divide & Conquer Algorithm) decomposing a new feature into logical groupings of tasks.

Tasks are deemed small enough when completion can be checked off by verifying simple assertions (e.g., Submitting an ID and Password Gives Access? True or False). Completed tasks, once re-aggregated, fulfill the feature requirements.

Undivided Attention

Divide and conquer feels like an intuitively advantageous problem-solving strategy. An overlooked advantage of divide and conquer is that it provides developers with the luxury of attending to one thing at a time.

Full Attention - attending to one thing at a time without distraction

The more atomic the problem space is, the less overwhelming it is to solve. The more focused our attention is, the quicker we can dispatch with a task.

Further, many craft-minded developers start a task with a test harness that frames the problem space so it can be poked and prodded with the binary confidence of true/false statements.

Remarkable things happen when we allow people to devote full attention to atomic tasks. Stuff gets done.

Attention is the most powerful tool of the human spirit.
~ Linda Stone

So, where's the disconnect?

Attention Deficit

Most organizations undergoing an Agile adoption, or those who have adopted Agile, enable developers to be productive by encouraging (and applauding) full attention to atomic tasks. Yet people on the business side of the software equation are rarely afforded the same luxury.

Organizations foolishly allow (and encourage) business owners, subject matter experts, project sponsors and stakeholders to engage in cross-cutting, superficial skimming.

Skimming is a form of Human Multitasking that subversively derails so-called Agile Software Projects. The developers are agile enough, but the business side is often asked to span products and projects which dilutes attention, thus decreasing effectiveness.

This discontinuity is a common, if not prevalent, red flag in the organizations I have worked with over the years as a contracted developer. I am on the verge of declaring

Agile software development never scales to large organizations.

But, never say never. I don't earn my keep coaching Agility in hostile, change-averse organizations, I just work in them. This assessment stems from unbiased observation - Agile might scale in large organizations, but I haven't seen it scale in the large organizations I have worked with.

Continuous Partial Attention

If Agile doesn't scale, what are the root causes? One root cause is lack of ownership (but that's a future post). Another root cause is the Continuous Partial Attention of stakeholders. Linda Stone created the meme Continuous Partial Attention, or CPA, to differentiate between simple and complex human multitasking.

To illustrate, I have observed a facet of the CPA phenomena where my daughter, could listen to Atmosphere on her iPod, watch Gossip Girl on television, and send text messages to friends while simultaneously solving her high school physics problems. No harm done - she turned in her physics homework on time. But it's a tiny leap to imagine scenarios where CPA becomes massively counter-productive.

"It usually involves skimming the surface of the incoming data, picking out the relevant details, and moving on to the next stream. You're paying attention, but only partially. That lets you cast a wider net, but it also runs the risk of keeping you from really studying the fish."

~Steven Berlin Johnson

How does Continuous Partial Attention impact our ability to execute software projects?

In my experience, the impact is resoundingly negative. There is shocking amount of organizational churn that occurs to frame and extract requirements in most software application problem spaces. The potentially positive impact of organizational experts is often watered down by systematic interruptions along multiple fronts.

Organizational experts must too often cast wide nets. Such wide net multitasking often begets a superficial, counter-productive depth of understanding of the problem space (i.e., you don't know the fish).

Superficial churn, as Steven Berlin Johnson's quote implies, precludes one from "really studying the fish".