A Plan B Approach to Planning

When Ergun Çoruh, blogger-in-chief at Negative Matter, advised always have Plan B, it resonated. He said

...the reason why plans do not work is because they don't work like Feynman's sum of histories. A plan is just a single historical path. Any divergence from that path creates a new future path, and more possibilities for further divergent paths. Like in quantum mechanics perhaps we should treat macroscopic events occurring in space-time as "sum of histories" and learn not to be hard on ourselves. What is happening "now" is just an outcome of a probabilistic experiment, not a certain thing. There is no certainty really, just as there is no platonic triangles with invisible zero-width lines. Plans always fail, the degree of failure varies.  ~Ergun Çoruh, 14 October, 2009

Software development has long agonized over plan A, and given short-shrift to plan B. I will heed and amend Ergun's wisdom by resolving to

Not fret so much about Plan A.  And, assume I'll need a Plan B.

David Koontz, blogger-in-chief of David's Agile Complexification Inverter, made this amusingly ironic comment on my Map & Terrain post

I had a sailboat that had the tentative second name of Plan B - had the lettering all done on a decal, but then decided we liked the original name and never changed it.

Sailing is an instance where one has much riding on Plan A, while Plan B could save a life. Tacking on David's course, Software QA engineer Chuck said

Sailing could probably lend many a metaphor to agile, since there's a heck of a lot of "adapting to conditions" that goes on. You might for example have planned on light winds, and put up particular sails, but then the winds change and you have to change to a storm jib (e.g., reduce sail).

And as someone that's stood out on a yard-arm, some 100' above the ocean, in a gale, working alongside a bunch of other hands to reduce sail, I can tell you it's a hell of a lot easier to do if you notice the need for change early, than if you find yourself reacting after you've been surprised because you failed to notice conditions where changing.

I could tell fish stories, but my sailing prowess sums up to tacking shallow Gilfillan Lake in a tiny cockpit-ed, single-handed Sunfish.

Chuck got me thinking about mindfulness. Mindfulness, an essential part of Gestalt therapy, is continuous, razor-sharp awareness of the moment. Mindfulness is a level of clarity of mind that allows thoughts and judgments to smoothly flow without dragging our keels on our fears, notions, and delusions. It is challenging to train one's mind to stay continuously in a state where interpretations, speculations, and projections don't hinder. For some, mndfulness it is a life-long practice.

The practice of mindfulness leads me to a fledgling approach or philosophy, if you will.

Edging Toward A Plan B Philosophy

I suspect it is possible to practice an explicit acceptance of the unexpected. Rather than trying to make better guesses and more accurate predictions, perhaps we seek an approach (or favor approaches) that have a reasonable chance of influencing desired outcomes no matter what chance hurls our way. American author Tom Robbins observed,

A truly stable system expects the unexpected, is prepared to be disrupted, waits to be transformed.  ~Tom Robbins

If it is possible to adopt a mental posture that expects the unexpected, and if it's possible to practice that mental posture, then we might find, as golf legend Arnold Palmer intimated,

...the more I practice, the luckier I get ~Arnold Palmer

Map and Terrain - The Limits of Planning

Belgian surrealist René Magritte created a series of paintings known as The Treachery of Images. One painting depicts an image of a pipe with the declaration Ceci n'est pas une pipe (It is not a pipe) painted below.

Magritte's image reminds us that any abstracted symbolic representation is by definition, a limited view. Magritte commented

 If I had written on my picture 'This is a pipe,' I'd have been lying!

Alfred Korzybski, developer of the theory of general semantics, remarked

The map is not the territory.

There's a difference between a model of something and the actual thing. Author Jerry Weinberg tweeted an applicable heuristic that inspired this post

If the terrain and the map do not agree, follow the terrain ~Swedish army manual 
@JerryWeinberg

Similarly with software, we can plan 'till the cows come home. But, once the action starts, stuff happens! Are you going to follow the plan or react to unforeseen circumstances? Often the map and the terrain don't agree.

Given Patrick Reilly's recognition that the optimal model of a system is THE system, and his admission that that ill-formed premises can be modeled and validated, why do we spend so much time planning, designing, and modeling?

I admit I have a soft spot for software prototyping.With prototyping, discrete activities of planning, designing, and modeling are compressed into cycles of develop and review. It's been my limited experience that the closer the review is to the user, the better the software.

During the cycles of develop and review, stuff happens. Inevitable stuff. Stuff like important discoveries. Valuable discoveries occur that we likely wouldn't have or couldn't have known before hand.

Discovery consists of seeing what everybody has seen and thinking what nobody has thought. ~Albert Szent-Gyorgi

Planning isn't always amendable to discovery. Planning usually occurs before action occurs. And before action, there might not be anything to critically observe.

Highfalutin plans can often be condensed into a concise phrase similar to the military concept of Commander's Intent (cf. my post Team Decisions and Commander's Intent). Troops in the field must often act without a script because stuff happens.

Most of us are adept empiricists. We understand things best when we experience them...

Instant message:

Bob says:
  i have a THANKING cloak that bounces THANKS back to the emitter
Steve R says:
 what does a "you're welcome" do?
Bob says:
  just threw an unhandled exception
Bob says:
 that was an edge case I couldn't have planned for.

Google Wave and Collaborative Projects

My tea kettle is whistling with more than lukewarm ideas on how we might use Google Wave for collaborative software projects.

To separate the steam from the high-pitched whistle of market evangelism...

Google Wave is a communication platform.

How might we use a real-time communication platform to make the push-pull of our collaborative software projects easier?

The Google Wave model promises to be a comfortable fit for seeding and feeding post-agile software projects. We might use Google Waves for

• Generating user stories
• Planning iterations
• Estimating tasks (e.g., real-time planning poker)
• Managing task boards and
• Spawning dashboard artifacts like burn-down charts

I like its threaded conversations of wavelets, blips, and drag-and-drop multimedia. Some Google Wave features that should make collaborative software projects easier are

• Bots and Gadgets Developers can embed gadgets and build robots that automate tasks within a Wave. A robot might read the content of a wave and then perform an action.
• Drag-and-Drop Sharing - Unlike clunky email attachments, you just drag-and-drop screen prints, wire-frames, buttons, stock photos, etc. on a Wave.
• Wiki-like, Hopefully Better - Anything within a Wave is editable by others. One may correct, append, or add commentary. One can only hope this is where project artifacts live rather than die (as with many project Wikis).
  
• Real-Time - See what your teammate is typing, character-by-character, unless it's planning poker - in which case you'll have to close your eyes.
  
• Playback - Playback any part of a Wave to see what the SME actually said about how something works.
  

The immediacy of instant messaging, combined with the richness of an anabolic Wiki, might prove to be a worthy collaboration tool. I like the concept of having team-member participation in threaded conversations (a traditional bulletin board), but also having features like playback and custom-robots that interrogate Wave content to perform actions.

The possibilities heat my water to boiling point. Robots are like having another person participate in a Google Wave conversation, except that they’re automated and they operate on the content of a wave. All extensible by common day-laborers like me.

The actions spawned by a bot might range from notifications like build failed or single sign-on test succeeded to spawning wavelets of unit test methods that are peppered with scenarios plucked from business-side requirements, discussions, and feature assertions.

Imagine a bot that parsed a business thread for Behavior Driven Development keywords like

As persona [X}
I want [Y]
so that [Z]

AND, parsed a business thread for scenario keywords like

Given initial context,
When an event occurs,
then ensure some outcomes.

then spit out a unit test methods?

Challenges to Adoption

Widespread adoption of a technology-driven phenomena like Google Wave will likely have to first hurdle cognitive and social models in search of digestible user metaphors (see Adina Levin's excellent post Google Wave: still in the lab, potentially mindbending for adoption).

Many of the operational metaphors that make things easy for users to understand simply don't exist for Wave yet. The Wave model mashes the familiar (email threads, wiki documents, and streaming communication) together. Instant messaging in your favorite messaging client is an easy model to follow. It is a simple post, response, & repeat. Will a multimedia, multi-participant Wave be so straight-forward? How will users find content efficiently? How will users invited into to a Wave conversation get up to speed with the other participants? Wave touts a replay feature, but is that the most efficient thread content primer?

More...

• Shannon Greywalker's Google Wave changes everything you know about agile collaboration and technical documentation.
• Ben Parr's Google Wave: A Complete Guide.
  
• Abel Avram's Google Wave’s Architecture.
• Google's Google Wave API.
• Spread Google Wave's Sandbox Developers Preview and Understanding Google Wave Development Part 1.
• Google Wave Interest Group on LinkedIn.