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".
