30 January 2011

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

6 comments:

  1. Why does Agile working lead to Continuous Partial Attention ? I don't get that. Can you ecplain a bit more on that ?
    I would expect Agile to bring something like CCI ( Continuous Complete Insight).

    ReplyDelete
  2. Geert,
    The disconnect I'm trying to describe is that the business (stakeholders, product owner(s), subject matter experts) are not given the same luxury of working atomized tasks to completion. The business is much too fractioned into different concerns in the organizations – at least in the ones I've worked with over the past 5-10 years. I've observed situations where the larger organization doesn't have a clue about the principles of Agile. As such, many of the people outside the development team, who could/should be helping flesh out features, stories, requirements, are forced to cast a wide net (often over several teams and several products). Because of this wide-net multitasking or CPP, the business people have a superficial understanding of the product to be built. This creates a painful and counter-productive amount of churn. The larger the organization and the more the application cuts across organizational concerns, the worse this phenomenon gets. The best agile experience I had was for a startup because everyone gave full attention to the product. The further an organization get from behaving like a startup (focused attention), the more difficult is it to be productive. That said, the worst agile projects are still more productive than waterfall.
    Thanks,
    Bob.

    ReplyDelete
  3. Thanks whittet. Are you a whittet of the Shane variety?

    ReplyDelete
  4. I skimmed this piece and picked out some of the relevant details, but I had to move on to something else before I fully grasped the implications.

    ReplyDelete
  5. Ah, I understand !

    Agile is used as a value system for software development. A good Agile team is a very powerful instrument, if wisely used. To get the most of it, organizations will need to use a similar value system. MoreAgile is to organizations what Agile is to software development. (http://blog.xebia.com/2010/12/23/moreagile-manifesto/)

    What I see in the large companies I work with, is that they actively search for ways to create more of the startup spirit in their organizations. Selfmanaging teams, shift from managing to leading and focus on business value instead of cost are relevant topics and found high on the agenda's.

    Product OWNERSHIP is indeed one of the biggest challenges. Agile Portfoliomanagement will be the next big thing !

    The point is, done right, Agile can be very powerful, even in large organizations.

    ReplyDelete