22 October 2009

Launch Early and Learn

Launch early and iterate is a rule-of-thumb perfected by Google and practiced by wildly successful companies like Facebook. Among agilists, the notion of iterating is a given.
I am adopting a new-found mantra of
Launch early and learn
I credit Marissa Mayer. She is Google's first female engineer, Money's #21 in 40 under 40, and Glamour's Woman of the Year 2009.

Marissa gave a compelling talk to Stanford students on Google heuristics and innovation. I recommend viewing Marissa Mayer at Stanford University for 49 minutes of insight into the thought repository of an unusually smart company. Marissa gives her Top 9 slogans, joking that presenting a Top 9 is marginally more innovative than a Top 10.

I'd been brain-casting how to create a UX-Driven-Development (UDD) platform for software, when Marissa's Stanford talk introduced me to the Google slogan
Launch Early and Iterate
In front of a slide declaring innovation not instant perfection, she shared personal narratives about the early - some would say premature - launches of Google News and Google Video. I have already mused that Google Wave is an immature product (see The Missing Link in Google Wave - UI For Primates).

Five days removed from my Missing Link in Google Wave post, I finally understand the Google modus operandi.

True Confessions - Google News

The Google News team was nearing their targeted first release. Six engineers respectfully disagreed over which feature they had time to include in their debut release. Three engineers vehemently supported Search-by-Date. Three engineers passionately supported Search-by-Location. Deadlocked.

Google made the decision to polish up existing functionality and not add new functionality. They released Google News without Search-by-Date or Search-by-Location! Shortly after the roll-out, they were bombarded with emails
How come I can't Search-by-Date?
Email requests were running about 100 to 1 for Search-by-Date over Search-by-Location. Guess which feature had top priority for the next iteration?

The preview of Google Wave occurred while the ink on the Wave federation spec and the Wave API was not only still wet, but still being pushed around the page.

When I attended the Google Wave hackathon last June, Google engineers had finally stabilized their Wave Server the night before the public arrived to start banging on it. That's early.

Google Mail was in beta for so long for a reason. It is a way of working that keeps development cooperatively linked to the community. This lends itself to critical adaptations and unforeseen customization.

Whether your mantra is launch early and iterate, or launch early and learn,
Mistakes seed improvement
in software product development.

That mistakes seed improvement is particularly true, and conspicuous, if your team is geared to
Turn feedback into function
within an iterative cycle, or two.

Further Reading
  • Agile Release Strategies - A wiki initiated by by Niklas Bjørnerstedt and Johannes Brodwall. The premise of the wiki is that a software product unable to release to production at least once every three months is problematic. That is, the longer the release cycle, the bigger the risk of partial or complete failure. Wiki includes principles and patterns. The wiki helps a Product Owner determine a Minimal Releasable Product.
  • Facebook encourages developers to push code quickly. Code pushes are never delayed and are applied directly to parts of the infrastructure. The strategy is to smoke out issues, and their impact, as soon as possible. (See Extreme Agility at Facebook).
For Italophiles...
Release often and learn
Rilascia spesso e apprendi
Release often and iterate
Rilascia spesso e ripetutamente

20 October 2009

Professional Persona Primer for Twitter

Does your professional persona on Twitter have a firewall around the excruciatingly irrelevant minutiae of your day-to-day existence?

Twitter asks,
What are you doing? 
Ignore this question. There are scant circumstances where a professional community gives are rat's lip about what you're doing. If tempted to answer the question What are you doing?, think teenage boy with too much Axe cologne. It's repulsive.

If you're thoughtful, self-effacing, marginally witty, and have some dumb luck, your professional community might care to know the answer to
What are you thinking?
I chafe at hard-fast rules. But I have considered a few rules-of-thumb for cultivating your professional persona on Twitter. Consider my Twitter heuristics.

Following are 3 reasons to follow you, and 3 reasons to unfollow you.

follow you when you
  1. Tweet smart, provocative ideas (i.e., original or properly attributed ideas)
  2. RT something smart I've tweeted
  3. Follow people with smart tweets
I unfollow you if you practice chirpitude (rhymes with turpitude) like
  1. Whine about your road woes, e.g.,  "No upgrade to business class", while I'm cube-warming in hell.
  2. Inform me of what you're eating, e.g.,  "Picked up Gyro at Kabobi"
  3. Incessantly regurgitate links, mentions, and RTs for people in the same community I follow.
More about chirpitude in Information Discovery and Chirpitude.

Groom Your Persona

Make smart assertions and smart observations based on your boot-on-the-ground experience. Be sure to pass on the smart assertions and observations of others; particularly those outside the tag cloud of your professional community. It's appealing to be provocative as long as you're not the boy who cried wolf.

If you can't help yourself from hurling inconsequential slobber into the ether, create another persona that reflects the pitifully vacuous life most of us lead.

Twitter is a killer micro-blogging forum. Revel in the challenge of Twitter's 140 character limit!  Last summer I challenged the agile community with an exercise to write user stories with a 140 character limit (see User Story Tweets).

Twitter Is Like

Twitter is a like a haiku when you're not committed to a novel. Figure out what your professional persona should be. If you're a letter turner in a skin-tight body suit

  • I want to know about interesting phrases you've encountered. 
  • I don't want to know when you're stuck in traffic.

17 October 2009

The Missing Link in Google Wave - UI For Primates

The transitional fossil between a transformative concept and a useful tool is probably always going to be the answer to:

Would a primate find it useful?

Okay naysayers, New Caledonian crows are an example of a non-primate clever enough to use a stick to poke food, but the scope here is primates; the nearly hairless apes like you and me.

An amusing poll at EasierToUnderstandThanWave.com asks,
Which is easier to understand?
On the left hand side of the EasierToUnderstandThanWave.com poll, is a screen shot of the Google Wave inbox. On the right hand side, is a sequential series of screen shots of stuff that's notoriously difficult to understand like:

Google Wave Inbox
Notoriously Difficult to Understand
Google Wave Inbox

  • The Geopolitical Climate of Southeast Asia
  • Self-Balancing Binary Search Trees
  • Polymodal Chromaticism
  • The Raison d'être for the Movie The Sandlot 2
  • Mating Habits of the Red-Sided Garter Snake

Having an unfinished thesis on a hopelessly academic model for the flow of two immiscible fluids based on complex analysis, I added:
The 2D analytic manifold of a Riemann surface
to the mix of stuff easier to understand than Wave. The picture (above right) is a butt-simple graphical rendition of the surface of a square root, f(z) = Sqrt(z). To everyone's dismay, the f(z) in my unpublished thesis took an entire typeset page. No wonder I drop-kicked a PhD fellowship to procreate; mating was the only thing I figured I could do as well as a snow monkey.

Google Wave is a transformative concept. To be fair, the monkey nuts of Google Wave are built on the shoulders of forward thinkers (Ray Ozzie) and well-established technologies and standards (XMPP). But it remains to be seen if humans will find it useful.

Last July I was excited about Wave, after attending the Hackathon at Googleplex with the inimitable Garry Smith. I wrote about Google Wave and Collaborative Projects.

I was talking to everyone who would listen. Now that WikiWikiWeb founder Ward Cunningham thinks Wave is cool, every curious person in the agile community and beyond is clamoring for Wave invitations.

Where's the Grand Metaphor for Wave?

Primates need metaphors to understand. It is not human hubris to say that humans might need a smaller rock than an orangutan, nonetheless a confused human appears every much as pitiful as a confused orangutan.

Email has a metaphor. Email has snail mail where the internet is a carrier pigeon or IPoAC (IP over Avian Carriers). Instant messaging has the metaphor of Morse Code operators sending and recieving messages. A Wiki has a bulletin board metaphor. Google Wave has nothing. Yet.

Where are the Visual Cues in Wave?

To thrive in complex social interactions, primates form mental maps representing the social hierarchy of thier posse. One of the confusing things about a Wave is the absence of visual hierarchy.

In a Wave, there are no clear relationships between elements in one's inbox. Every blip carries equal weight. One might issue a mind-bogglingly-profound blip that's answered by
That's awesome dude
Both blips carry equal weight to a subsequent participant joining the Wave.

A Wave needs some kind of tag cloud do-hicky, or real-time executive summary. When there's information overload, humans need a lazy way to
Cull the salient from the slobber

Everyone at Googleplex, Younger and Smarter

I remain steadfastly bullish about Google Wave. Everyone at Googleplex is younger and smarter. The billiards-playing Stanford graduates toiling at Google's Mountain View sweat shop, and the fledgling community of adopters and gold-miners, are bound to make Wave useful to the masses. But for now, I'll continue using cotton string and re-purposed cans.
tin can phone

15 October 2009

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

12 October 2009

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

06 October 2009

The Good, The Bad, and The Mail-It-In

Teams benefit from regularly examining the ledger of what Worked Well and what Needs Improvement.

The agile Retrospective is the periodic, iteration-ending team-reflection session met with joy, dread, or indifference.

What's Your Experience?

I'm curious,
  1. Are you comfortable with the heavy lifting called for in true team reflection?
  2. What were the defining characteristics of your most productive retrospectives? 
  3. What is the appropriate level of ceremony? 
My Experience

Retrospectively, I can recall The Good, The Bad, and The Mail-It-In.

One team had the common sense to rotate leadership amongst team members, so each retrospective had a different flavor. It made it lively. It kept it fresh. All good.

Another team, having grown impatient with the lack of candor, adopted a variation of the ritual of passing the rock, dubbed passing the action figure. An action figure, bestowed with alchemistic powers, was passed to each team member.

If you held it, you were expected to say something that was bothering you, something uncomfortable, something controversial, or something wildly informative about team dynamics. Again, good.

Other sleep-walking teams mail it in. For those teams, the retro is just another check box on the list of agile ceremonies.
    Mail-It-In Retrospectives

    I stumbled on a promising antidote for Mail-It-In Retrospectives called Theatre of the OppressedAugusto Boal (1931 - 2009) was a Brazilian theatre director, writer and politician. Boal founded Theatre of the Oppressed.

    A facet of Boal's Theatre of the Oppressed is Forum theatre described as follows:
    1. Actors perform a play with a script that includes a relevant form of oppression.
    2. At the end of their first performance, where the oppressed in the script do not overturn their oppressors, the actors begin a second performance of the play. 
    3. In the second performance, any audience spectator - called a spect-actor - may call out stop!, then replace of the actor portraying the oppressed character. The actor stays at the side of the spect-actor.
    4. The spect-actor tries to overturn the oppression by using methods untried by the actor replaced. 
    5. The actors portraying the oppressors then improvise, in response to the spect-actor, attempting to steer the performance back to its original script of unabated oppression.
    Some project teams I have participated in coexist with mild, usually subtle, forms of oppression. Oppressive behaviors are uncomfortable to confront. Discussion of these behaviors rarely bubble up in retrospectives. Unresolved, they can be burrs in our collective saddle, or worse. At best, they kill our mojo, often strangling the free flow of ideas.

    I don't need to enumerate. They're personal and team issues. You know what they are, so act!

    04 October 2009

    Design Serves Human Purpose

    Humans have been designing for millennia.

    Today, fast prototyping and rapid iteration cycles have become conventional wisdom in software development circles.

    Enduring design serves a human purpose.

    Human-experience-focused prototyping is a development practice I will follow with interest in coming months. Future successful software products will be made by teams in collaborative environments hyper-focused on human experience.

    The Achilles heel of Big-Design-Up-Front (BDUF) is that it is rarely possible to know all design needs up front. Anticipating the many and varied outcomes a priori is daunting. And, many would argue, is inefficient.

    Nature works in iterative cycles - in generations of adaptive species - to modify DNA. Why should software be shackled with a Creator-like BDUF when it can mimic the feedback loop efficiency of natural selection?

    To encapsulate our trepidation for having to design and build products in an uncertain world, the authors of the book Subject To Change invoke ancient teachings
    To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.
    ~Chinese proverb
    From iteration zero to subsequent production releases, human-centric software seems likelier to succeed and endure. In Subject To Change, authors from the user experience design company Adaptive Path, have observed how user experience can inform and shape our product vision and growth from startup onward.

    For products, software applications in our case, the authors of Subject To Change enumerate the facets comprising user experience:
    • Motivations: What do our users hope to get from our software?
    • Expectations: What preconceptions do our users bring to how our software should work?
    • Perceptions: How does our software affects the user's senses (e.g., see, hear, and touch)?
    • Abilities: How are our users able to cognitively and physically interact with our software?
    • Flow: How do our users engage with our software over time?
    • Culture: What framework of manners, language, rituals and behavioral norms do our users operate in?
    Human experience facets will likely be foremost in our minds in coming years and, in many cases, will likely supercede technical considerations (particularly technical considerations that have little bearing on product experience).

    Agile Development

    What have we learned about design from Agile Development?
    1. Bring the customer into the development process. Agilists have become adept at engaging stakeholders in the product development cycle. I would explicitly extend this concept to engage the end user (i.e., human experience).
    2. Value getting things right. Agilists produce early and often, then subject their product to the stakeholder’s approval. Again, I would explicitly extend this concept to include the end user (i.e., human experience).
    3. Be iterative and responsive to feedback. Because agile is, by definition, iterative and responsive, exploratory design and design changes are less costly than BDUF. With BDUF, no one wants to admit a year or two into product development, that a design approach everyone has been dutifully following, was flawed.
    Lean Manufacturing

    What have we learned about design from Lean Manufacturing?
    1. Value to our customer is our sole priority. Lean considers an expenditure of people's time for any goal other than value to the end customer, to be wasteful.
    2. Build our product when the consumer orders it. Lean Manufacturing was pioneered during Japan’s post-war recovery by Toyota. The innovation was to build cars when an order was placed rather than stockpiling cars in anticipation of sales; a necessity for Toyota’s survival in the low consumer demand environment of post-war Japan. This innovation led to a tight feedback loop between the production line and consumers.
    Today 3M has the motto: make a little, sell a little. This motto encapsulates 3M's iterative approach that places its products temporally closer to the whims of the consumer.

    Evolutionary Design

    Evolutionary Design is the idea that design improvements naturally occur over a series of iterations (cf. Evolutionary Design - A Conversation with Martin Fowler).

    Charrette is a French word meaning cart or chariot. The design charrette is thought to have evolved from frequent occurances in 19th century Paris where architecture students at École des Beaux-Arts would do frantic, last-minute collaborative design changes to their presentation en route to school in a cart ("en charrette"). Design charrettes have since come to signify collaborative design sessions.

    One way evolutionary design manifests itself in software projects is with impromptu design charrettes. That is, impromptu discussions that occur amongst the development team. Novice and experienced developers frequently have adhoc sessions around someone's cubicle, or around an open-plan Scrum pit, to discuss a design approach. Charrettes seem most helpful when everyone feels free to opine without retribution. These short and sometimes intense discussions are capable of rendering rapid, adaptive changes.

    If the team also considers a guiding principal like How will this help our user? then design serves a human purpose.

    Minimum Viable Design

    There have always been talented designers on my teams who, thankfully, did most of the heavy design lifting. That's not to say I didn't offer ideas or opinions, rather realizing my limitations I have often deferred to others. I am not adept at planning ahead, but I am usually quick to recognize when things are working (and when they're not).

    Minimum Viable Product or MVP, is a concept borrowed from Lean Manufacturing by Eric Reis as a strategy for rolling out new product ventures. Eric's incarnation of MVP is a mashup of agile lessons (e.g., release early, release often) and the realities of the funding cycles of a new venture. The MVP question is
    What version is the version of a new product that allows a team to collect a maximum amount of validated learning about customers with the least effort?
    An ever-so-slightly upstream companion concept to MVP might be called MVD or Minimal Viable Design. The MVD question is
    What design pattern or design approach will allow our team to push a release that starts (and sustains) the feedback loop with stakeholders and users?
    I am reminded of Naresh Jain's post Embrace Simple Design where he encourages us to use the
    Smartest Possible Thing That Could Possibly Work  ~Naresh Jain
    Poet Wallace Stevens called this the art of what suffices.

    To provide the utmost in utility and usability, software teams benefit from human connections and cycles of adaptive, rapid feedback. This is design for human purpose. It is an approach to design that is cast in the same mold as survival of the fittest.