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

Finding Cadence in Dysfunction Junction

Imagine we are rowing crew-mates. We're sculling a river at an refreshing rate. Our cadence is palpable.

Now imagine adding a silly clown, with a silly clown-sized oar, into the mix. Imagine that the silly clown has no accountability to the crew, but has been ordered by a chief clown to stick his oar in.

The silly clown is ill-equipped since his oar is clown-sized. It's immediately evident he derives no pleasure from helping you or your crew-mates propel the craft. He only wishes to demonstrate his paddlry.

The boat slows, then sharply veers off course.

In the Agile software realm, the clown with the clown-sized oar, is one flavor or another of architect (see The Chicken & The Pig). He fancies himself as a title rather than an agent noun. You can be certain he's not on your team. If he was, he'd be called a developer...a developer who's accountable to produce working software, rather than artifacts.

For every wildly productive Agile project, I wonder if there are about five or so that have gone off the rails into dysfunction junction. It bears repeating that the Agile Manifesto has four easy-to-understand guiding principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Easy to understand, but challenging to implement.

It's a personal quirk, but one of my red flags is when people pronounce Agile with a long "i". There are other red flags, some funnier than others.

Sometimes red flags make me long for the white flag of surrender, then I remember practice and discipline.

I'm not a musician. Yet it's clear there's a distinction between loving the promise of sweet music and coaxing a coherent tune from a Stradivarius. The hard work can't be skipped. The practice can't be ignored.

I'm not an Agile software coach. CIOs who have the foresight to hire a coach to kick off an Agile adoption should be commended. Hiring a coach for Agile 101 sessions is like learning to play scales. Necessary, but not Mozart.

Without continued practice in Agile discipline, well-intentioned people revert to putting in more overtime while getting less done. Stand ups revert to sit-ins.

CIOs who conceive of an Agile adoption as a few cheerfully upbeat coaching engagements are mildly delusional. A realistic Agile adoption probably means a minimum 6-month slog by an embedded coach (or coaches).

If the principles are easy-to-comprehend, why is it so difficult to make it work? One impediment is people don't have ownership. Most organizations pay a bunch of salaried folks to ponder what they'd rather be doing. They don't give a rip about agile-smagile.

I'm glad I'm not talented enough to be a coach, because

What do you do with well-meaning folks who couldn't lift a feather in zero gravity?

Red Flags & Cadence

Your execution of agility might be poised to implode if your organization

• prefers spreadsheets or software tools over low-fidelity PostIts and a Story board;
• can't seem to re-purpose the static and limited title of architect into something helpful;
• separates the people using the software from the people developing the software;
• seems ladened with command & control management who are cynical about change;
• doesn't comprehend the poignant parable of The Chicken & The Pig;
• is reactive & accusatory, rather than thoughtful & nuturing.

If you recognize these, I urge you to hire a long-term Agile coach (or coaches). Ideally this person is half rock-star developer and half rock-star psychologist. With any luck, this person is also willing to slog it out in the trenches for months into years.

Cadence

I suspect iterative cadence comes from something akin to an athlete's muscular memory. If that's the case, then think about, and retrospectively examine, how your behavior, your team's behavior, and the organization's behavior, reflects the four guiding principles in the Agile Manifesto.

Give it time and practice. Focus on the four guiding principles. Minimize distractions. Row, row, row your boat...every day, every week, every month.

Agile in Toxic Organizations

Perusing the Agile 2011 proposals, I wondered if anyone in the Agile space addresses coaching Agile in the toxic organization. I'm not a coach, but I feel the coach's pain.

I have seen the Bright, the Lite, and the Dark Side of Agile. Please explain to me how one can be helpful bringing the dark into the light.

Do some organizations have too much of a baked-in reactionary culture to reap the bounty of agility? Are the pathetic schlubs walking the halls with their heads down merely avoiding the shrapnel of IEDs (Iterative Explosive Distractions)?

Do these soul-sucking organizations have enough banked karma to deserve the best intentions of passionate Agile coaches and the elbow grease of super-talented Agile developers?

Overheard on a speaker-phone during Project Chartering introductions:

"I'm Rose. I don't know why I'm here."

A subject matter expert with a meant-to-impress title, Rose made her deadpan introduction to her soon-to-be teammates.

Queue the crickets chirping.

Also remoting in, the speaker-phone voice of the CIO explains Rose's presence in the chartering session and what Rose's hoped-for participation would be on the team. Yikes. Gotta love that business buy-in.

Toxic organization is a loaded term. One characteristic of a toxic organization is that

The people most comfortable with command and control often mistake agility for the more familiar reactionary.

Just bark at me if you think I might ease your slither from the dark into the light. Otherwise, I'll join my heads-down comrades in C-Sharpistan.

Hello World! in 2011

Knowing I needed less than 40 ASCII characters to pronounce Hello World in FORTRAN, I set about to determine what it would take to do the same in Silverlight using Prism and the Model View ViewModel or MVVM pattern.

Back in the summer of '82, huddled in front of a venerable VAX terminal, I tapped out my first computer program.

Hello World! gave me a chill -- particularly remarkable since this happened in a sweltering computer lab at the University of Minnesota. Our pampered VAX was housed in a chilly meat locker of a room - a room much more accommodating than the undergraduate computer lab with its solitary oscillating fan.

Three glorious lines of FORTRAN. And yes, less than 40 characters of code.

PROGRAM HELLO

PRINT *, 'Hello World!'

END

Hello Silverlight, Buh-Bye Simplicity

Fast forward to 2011. This New Year weekend, I have been struggling with adapting a navigation framework for Microsoft Silverlight using MVVM. The stated intent of MVVM, and similar patterns like MVC, is separation of concerns; namely,

separating the presentation layer from the logic layer 

to make code easier to test and to have a pattern that's easy to build upon and to maintain.

Most of my agile colleagues, and mentors like Chris Bartling, are passionate about test driven development. I use TDD, and I think I understand where TDD shines. But I admit I am slightly more motivated by something as mundane as separation of purpose (i.e., old-school layers), because I like an approach to programming that makes stuff easy to create, re-produce cookie-cutter style, and, down the road, will make it a cinch to maintain or extend. Clean. Easy. Life's good.

Forget the complaints against complexity; instead, complain about confusion.
~ Don Norman

I cling to clean simplicity like so many Buckyballs. I despise sloppy confusion. I despise deciphering widely varied code formatting. I loath wringing drops of value from the software anti-patterns I encounter as a contract programmer. And I frequently go ape-shit unraveling spaghetti code.

If I put the hyphen in anal-retentive when it comes to consistent formatting of code, why do I need a machete to cut a path to my desk?

Yet I have struggled with adapting a canned MVVM navigation framework for Silverlight. Ostensibly, all that's needed is simple navigation. We need to register and load views on demand from a navigation framework. Sounds straight-forward. It ain't.

I started with the Prism Navigation Framework developed by Slobodan "Roboblob" Pavkov. Without Roboblob, I'm not sure where I would have started. Microsoft tends to release software tools that are half-baked and then backfill the shoddy effort with spotty documentation - Don't get me started on Entity Framework!

After 3 days of incisor gnashing, I have been able to adapt Slobodan's laudable work to something that just might suit our needs. I don't belittle Slobodan's framework as it must have taken a yeoman's effort.

Perhaps by necessity the solution to what should be a straight-forward problem, seems painful. By painful I mean fragile, almost inscrutable, difficult to debug, and downright confusing for slightly above-average programmers like me - particularly considering we only need to provide hyper-links that load different views on demand.

Why does something that ain't rocket science have to seem so much like...rocket science?

Hello World 2011 in Silverlight

Writing Hello World in Silverlight, I needed 2 projects:

• a Silverlight project for the application that includes both the View and the ViewModel, and
• a web project to render the Silverlight. This project has an HTML file with a tag that references the Silverlight object created above.

It seems that Hello World in 2011 via Silverlight requires,

• a 74 line HTML file that has the tag containing the Silverlight object;
• a 55 line XAML file that contains navigation and a container for the View; and
• some 23 lines of XAML in the View to say Hello World!
  

Yikes!

Perhaps I've exaggerated the effort since Microsoft makes Hello World so easy that even an aging bonobo with cataracts could code it with 3 clicks and a cut 'n paste. What happens when I need more than Hello World?

I am beginning to wonder about confusing & seemingly gratuitous complexity; albeit confusing complexity added in the good name of testability, flexibility, and modularity. My questions are two-fold:

What is the cost of confusing complexity (necessitated by an ostensibly clean pattern)?

and

How much are we blinded by the laudable lights of testability, flexibility, and modularity?