Team Decisions & Commander's Intent

How does your team make impromptu decisions?

To keep Bill Clinton's presidential campaign sailing along on a singular tack, political strategist James Carville posted the declaration,

The economy, stupid

in their Little Rock campaign headquarters.

In Made to Stick, Chip and Dan Heath remind us that James Carville's declaration is known in military circles as the Commander's Intent.

Historically, military planners have observed that complex battle plans begin to break down as soon as the battle commences.

Everyone has a plan 'till they get punched in the mouth.
~Mike Tyson

During combat, innumerable variables dictate the prudent course of action. In the 1980s, military planners adopted the concept of Commander's Intent. The Commander's Intent is a direct, fast, and simple declaration like win hearts and minds or destroy the bridge. When faced with a decision in the field, everyone can weigh whether a course of action follows the CI.

The US Department of Defense defines Commander's Intent as

A concise expression of the purpose of the operation and the desired end state that serves as the initial impetus for the planning process. It may also include the commander's assessment of . . . where and how much risk is acceptable during the operation.

Is there value in declaring a Commander's Intent during project chartering? In many cases, I think so. The Product Owner might make the declaration

Provide fast search results

(making sure the team understands the distinction between fast search results and relevant search results).

During iteration planning, and during retrospectives held over the course of the project, team members are then able to repeatedly ask the self-correcting question

Are we providing fast search results?

In some cases, project iterations would benefit from a CI; particularly in iterations where the user stories roll up into a singular theme or goal. In such cases, the Product Owner, or the team collectively, might craft a succinct, high-level statement like,

Display targeted ads with search results

that sharpens the focus of the iteration. During the course of the iteration, the team is then able to ask the self-correcting question

How is this helping us Display targeted ads with search results?

Agile That's Made to Schtick

In Made to Stick, brothers Chip and Dan Heath ask

Why Some Ideas Survice and Others Die?

They use the attributes

Simple, Unexpected, Concrete, Credible, Emotional, and Story

to evaulate how and why ideas endure. The acronym SUCCES wafts uplike fried cheese curds, but this is a useful, albeit ionic, mnemonic.

While reading Made to Stick, I stumbled upon Scott Duncan's collection of Twitterverse truisms at Agile Software Qualities. Scott cherry-picked the worthy knowledge nuggets from the past months of Twitter chatter.

We can get at the essence of agility by distilling some of these knowledge nuggets.

Here are the quotes from Scott's blog that stick with me:

People who think they're on a hero's journey tend to disregard the ordinary schmucks around them. ~Brian Marick

Primary work of managers: establish conditions for teams to work in. develop people. work on the work system. ~Esther Derby

Instead of thinking, 'irrational', think 'rational from the perspective of a different set of values. ~Jerry Weinberg

The more authority I have over my own habits, the more I care about outcomes over dogma. ~ J. B. Rainsberger

The problem is thinking based on authority rather than responsibility. ~Jason Yip

Don't ship features. Ship improvements. ~Joshua Kerievsky

Succinct aphorisms stick because they're easy to remember. They're easy to remember because they have one or more of the attributes of SUCCES.

Aphorisms are literature's hand luggage. Light and compact, they fit easily into the overhead compartment of your brain

~James Geary, The World in a Phrase: A Brief History of the Aphorism

Beware Ceremony

The ScrumMaster asks,

"On belay?"

to signify the end of standup.

You and teammates affirm,

“Belay on!”

when the actual intent is to let your teammates fall to their deaths.

Some teams feel the need for a signal to indicate the end of a standup. Perhaps this is most suitable for a team comprised of recent agile adoptees.

For the more cynical of us, the “On Belay? / Belay On” question & response makes for a thought-provoking metaphor. It might be even an appropriate metaphor if every team-member has your back, but it might wear thin if there’s an undercurrent of mistrust.

In the post All For One, One For All - Signal the End of Your Stand-ups, agile coach Ken Clyne urges us to have a clear sign that standup is over. I'm torn about Ken's suggestion. I agree it is sometimes helpful to have a signal for the end of standup.

My first ScrumMaster, Markus Silpala, used to declare with varying degrees of enthusiasm,

"Scrum out"

Perhaps Markus sensed we were a joyfully cynical lot that could only abide a minimalist's touch.

My caveat is to be careful of gratuitous ceremony. I think Markus had it right.

I caution against the potential for rah-rah cheesiness in your standup. It's probably yet another flaw that has hindered my professional advancement, but I cringe at the first sniff of scripted ceremony.

Lazy Man's Agile

Many organizations mistakenly think that capital expenditures on software tracking & planning tools is tantamount to being agile. Plan, spend, and execute. It seems easy.

Tara Whitaker uses the Conscious Competence Ladder in her post Doing Agile is a Sign of Incompetence to expand on the distinctions between doing and being agile.

A common scenario that exemplifies doing agile is to ignore the first value in the Manifesto for Agile Software Development

Individuals and interactions over processes and tools

Capital expenditures on software tracking & planning tools do not guarantee your team will be happier or more productive.

Planning & tracking software CAPEX typically comes from the IT department with no coordination with the “beneficiaries” from the business side.

Short shrift is given to coaching. And there’s no budget left for courses or conferences.

I have dubbed this lazy man's agile.

Lazy man's agile is often less productive, and usually no more inspiring, than pile-driven waterfall.

Our lesson is simple.

People are first. All the other trappings are…well…trappings.

Don’t let the easy path of tools and templates drain the humanity from a great idea. People make software. People use software.

Hire coaches. Send your team to conferences. Define it for yourself. Craft a team understanding.

Pragmatic Suggestion

Start with the relatively low-cost, low-expectation of incremental improvement.

This is doing and being at the same time.

Quality's Okay, But Who's Paying the Freight?

One of my favorite truisms used to be

good software ain't cheap and cheap software ain't good

It's a parallel phrase that seems to ring true. I appreciate a catchy chiasmus as much as anyone, but now this aphorism seems like a marble in a rock stack.

Lets face it, sometimes cheap software is good. How often do we balance expeditiousness with quality?

Demand for our software services is throttled by the people who buy the products. It is almost always our charge to strike a balance between cost and quality constraints. Dogmatic pursuit of quality might be persceived as gold-plating. The economic reality is

selling software is a prerequisite for being paid to build software

~Mike Cottmeyer from Is Quality an Absolute?

Two observations about expeditiousness and software quality are:

1. Often teams are faced with a simple choice: more features or higher quality (e.g., refactoring, paying down technical debt, bug fixes).
   
   
2. Often that choice of more features or higher quality is determined by whether your product is a greenfield start-up or you’re supporting an established, public-facing product.

Start-up Product

In the context of a greenfield project or a start-up product, I have been introduced to the concept of Minimum Viable Product or MVP.

In Minimum Viable Product: a guide, Eric Ries explains that an MVP is made to elicit feedback. He defines it as

a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort ~Eric Ries

Kent Beck discusses Eric's approach in Approching a Minimum Viable Product where he uses MVP to address critical product assumptions, and to illuminate the unknowns, for his new product Tattlebird.

Presumably some degree of quality is sacrificed to get answers. The value of expeditious answers supercedes quality issues like user experience or reskinning a user interface.

Established Product

On the established, public-facing product front, Anna Forss wrote about establishing the notion of business value for bug fixes to the sales organization of her customer (cf. what value does bug fixing have for sales?).

Anna poses Fred Reichheld's The Ultimate Question

How likely is it that you would recommend product X to a friend or a colleague?

In the context of an established, public-facing product, she suggests that

...bugs create more detractors than features create promoters ~Anna Forss

In this content,

Value = Promoters - Detracters

Higher quality (user experience improvements and bug fixes) provides real value; in some cases more than new features. Sometimes error-free operation and usuability trumps new features.

If there's no need to walk the goldfish, use a fishbowl. ~Bobtuse

Given the context (startup or established), I understand the need to balance expedience and quality. As long we are focused on who's paying the freight and that their goals jibe with our mode of operation.

Usage-Centered User Stories & Story Mapping 2

Forward-thinking post-agilists, like Jeff Patton and David Hussman, have been thinking about and speaking of ways we might help product developers enrich poorly conceived user stories and ease challenging planning sessions.

Our challenge as product owners and developers is to consider and to incorporate user experience and user activities into our thinking and software planning.

In this 2- part series, Part 1 presents the how-tos of usage-centered user stories and personas. In this post an overview of usage sequencing and story mapping is given.

Jeff Patton, David Hussman, and others, champion a particular sticky note scaffolding call Story Mapping for considering how people will use your software; a simple structure that positions stories in the context of tasked performed and software usage. See Jeff Patton's post User Story Mapping.

Story maps support the primary intent of user stories: rich discussion ~Jeff Patton

User Story Mapping is an approach to organizing and prioritizing user stories. Mapping seeks to frame stories in the context of the user's tasks/roles and by the values derived from the software by the people using it. Following Jeff Patton's story mapping technique, you'll get a sticky note festival of

• Functionality of your software product,
• Personas who derive value from it,
• Activities the personas engage in, and the
• Usage Sequence the personas follow

User Story Mapping gets its legs from activity modeling (cf. Constantine's Activity Modeling and Usage-Centered Design) and from Jeff Patton's interest in context specific approaches.

Problem - Size Matters

When tackling user stories we're often overwhelmed by the size of the job in front of us (e.g., That's Not A User Story, That's An Epic!).

We deal with largeness by breaking it down into smaller pieces. We're just following an evolutionary rule of survival

Never eat anything bigger than your head

Breaking things up helps, but often an epic deconstructs into a slew of disconnected stories.

How can we deconstruct a large story or epic in a way that communicates more than a random hodge-podge of work bits?

Solution - Story Mapping

The building blocks of Story Mapping are persona activities and tasks. Activities have characteristics relevant to our software. An activity is comprised of a sequence of persona tasks.

To start a mapping, begin with a persona activity (e.g., Persona identifies himself).

List the activities your persona performs on separate index cards. Arrange the activity cards in usage sequence from start to finish as if you were answering the question What does this persona do with our software?, as shown below.

Add persona tasks on yellow sticky notes below the time line in the order that you would tell the story of the activity. Try to preserve the order of workflow from left to right. Arrange the yellow stickies as if you were answering the question What does this persona do in Activity n? as shown below.

If your persona does some of the tasks simultaneously, stack them vertically. Imagine you're narrating the story of a workflow.

Whenever you'd have an OR in your sentence, you'll probably stack the task vertically as in the persona does this or this

Whenever you'd have a THEN in your sentence, you'll probably arrange task in a sequential, horizontally fashion as in the persona does this then this

An illustration of persona tasks performed simulaneously (vertically stacked yellow stickies) and sequentially (horizontally sequenced yellow stickies) is shown below.

One of the questions that arose in the Practical Agility session was

Where are the stories I can start queuing up in my backlog?

If we consider each activity as a large story or epic, then these epics deconstruct into child stories as shown below.

Each of the persona tasks (Child Stories) in the mapping above could be pulled into a backlog planning tool as user stories. Subsequently these stories would be tasked and estimated by developers.

Important Caveat - To avoid confusion,

Persona tasks are completely different and unrelated to developer tasks.

A persona task is something a person does with our software. A developer task is something a developer writes to meet the criteria contained on a story card.

Story mapping provides a scaffold to post and arrange your index cards (Activity or Epic) and stickies (Child Stories) in a meaningful way. By representing persona activities across the top of the map, we can visualize end-to-end use of our software. A successful story map shows the decomposition and workflow across a system. It communicates the persona experience.

Queued Reading

Activity Modeling: Toward a Pragmatic Integration of Activity Theory with Usage-Centered Design by Larry Constantine.

About Face 3: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

User Story Mapping PowerPoint by Jeff Patton

How You Slice It blog post by Jeff Patton

Agile User Experience Design by Jeff Patton (March 2010)

Interview - David Hussman on Helping Organizations Adopt Agile

Usage-Centered User Stories & Story Mapping 1

Forward-thinking post-agilists, like Jeff Patton and David Hussman, have been thinking about and speaking of ways we might help product developers enrich poorly conceived user stories and ease challenging planning sessions.

Our challenge as product owners and developers is to consider and to incorporate user experience and user activities into our thinking and software planning.

In this 2- part series, this post presents the how-tos of usage-centered user stories and personas. In Part 2, an overview of usage sequencing and story mapping is given.

Last night, I attended DevJam's Practical Agility session held in the garage-band basement below Java Jack's Coffee Cafe. David Hussman, with props and praise to Jeff Patton and Allan Cooper, hosted and gave an engaging session to our group titled Story Mapping and Personas.

Following is my synthesis of the informational highlights of the usage-centered user stories and personas portion of the session.

Problem - Our User Stories Stink

With David's prompting, Practical Agility participants shouted out the following reasons our user stories stink:

• Titles - Bad, non-descriptive titles are all-too common
• Acceptance Tests - No list of assertions developers can write tests against
• Templates - Overuse of and Mindless filling in of As a User... templates
• Software Tools - Crummy software tools that are hard to use and introduce counter-productive habits.
• Confusion about what's a story and what's a task

Solution - Entitlements

Take time for a title. The word Placeholder is almost always insufficient. The assorted hindrances of the "Agile" software your company purchased and decreed you must use is no excuse. Shouldn't a story title indicate a function, feature or activity? Often story titles are a verb phrase like view list.

Make it short. Make it burn.

It is with words as with sunbeams. The more they are condensed, the deeper they burn. ~Robert Southey

Solution - Personas

Use personas, please. Creating and using personas is a simple, useful productivity boost. Why doesn't every software team use them? Without a Vulcan mind meld, have we truly realized the ways in which people will use our software?

Dude has to know who he's selling to ~David Hussman

Marketing professionals have long created personas to understand the whims and proclivities of their buyers. We should too. There is a reason staunch cola loyalists can't distinguish between Coke and Pepsi in blind taste tests. It is because the caramel-colored, sugar water snake salesmen know precisely what triggers your buy impulse...and it's not taste.

Want to try personas? Make a persona page for each category of persons who will use your software. If there's significant overlap between personas, pare your personas to the most common usages, then evaluate sub-cases.

A persona is happy if it has the following:

1. A Picture. Go crazy.
2. A Name. I like alliterations like Doug the Delivery Dude. Go crazy.
3. Columns for Characteristics and Values (i.e., the utility derived from the software).

Imagine the software we're about to write is attached to a scanner that tracks what goes in and out of Doug the Delivery Dude's van. In 95% of the cases, packages are hand-scanned by Doug without incident. In 5% of the cases, the package doesn't scan. That's where our software comes in...

Our software indicates an error condition when scanning fails and requires manual entry by Doug. Doug needs to confirm his identity, confirm the time, confirm his location, and most importantly, key in the package identifier.

In the characteristics column we need to consider:

• The context the software task or activity is performed in (e.g., standing in a dimly lit space)
• What the task performance or activity is (e.g., data entry)

In the values column we need to consider the criteria for the software to support task performance. What value would Doug hope to derive from our software?

Here's a swing at a persona page for Doug.

Doug the Delivery Dude
Characteristics	Values
experienced, but could be new employee might have big fingers impatient, since compensation is throughput-based distractible data keying done in dimly lit van might need reading glasses	Feedback if data entry is spurious (sound) Instantaneous confirmation (sound) Alternative if software locks up Reminder if anything missing (sound) Bright and high contrast (delivery van is dark)

Solution - Do Lists

A Do List is another name for Acceptance Criteria. There is fuzziness about the phrase acceptance criteria. Developers complain about story cards not including acceptance criteria. Why? Because developers use acceptance criteria to declare a task or story is done. As a product owner, give developers a bulleted Do List of every result that should happen. Developers, in turn, will convert the Do List into tests as a starting point for writing software. QA testers use the same Do List as a functionality checklist.

Product Owner's Do List	Developer's Test
Doug's identity is confirmed The time is confirmed Doug's location is confirmed This package is identified	Is Doug's identity confirmed? Is time confirmed? Is location confirmed? Is package identified?

Story Card Wrap

We've got a persona and a do list. Now, what's a good story title? While it might seem backwards, it's advantageous to decide on a story title after you have a persona and a do list since you will have done more noodling about the essence of the story. At least revisit a working title to refine it after you have a persona and a do list.

What is Doug's activity when he's using the software? Remember the context. Doug's scanner has failed, so he must use our software to manually key data. How about Enter Data as the story title?

The Not So Hot Classic Template:

As a User I need to __________ so that ________.

A Better Thingamajig That Mustn't Be Called a Template:

As Persona I need to Story Title so that

do item - acceptance criterion

From our example:

As Doug the Delivery Dude I need to Enter Data so that my

identity is confirmed

As Doug the Delivery Dude I need to Enter Data so that the

time is confirmed

As Doug the Delivery Dude I need to Enter Data so that the

location is confirmed

As Doug the Delivery Dude I need to Enter Data so that the

package is identified

In Part 2, we'll dive into usage sequencing and story mapping.

Queued Reading

Activity Modeling: Toward a Pragmatic Integration of Activity Theory with Usage-Centered Design by Larry Constantine.

About Face 3: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

User Story Mapping PowerPoint by Jeff Patton

How You Slice It blog post by Jeff Patton

Agile User Experience Design by Jeff Patton (March 2010)

Interview - David Hussman on Helping Organizations Adopt Agile

What Does Best Practice Mean?

Best practices are hard-earned gifts.

In the west, we rarely notice the box after opening a gift. A gift box has no story. It has no utility beyond obscuring its contents. It's disposable.

In Japan, wooden boxes for clay pots are works of art; often the box has hand-brushed calligraphy applied by the potter. Tomobako is the Japanese word for the hand-crafted box. A tomobako is typically made from the native kiri or empress tree (paulownia tomentosa).

Japanese potter Rosanjin called on Spanish artist Pablo Picasso while visiting Europe in 1954. This historic encounter is described as:

When Rosanjin did call on Picasso, he brought this most renowned Western artist an example of his potting. Naturally it was in the finest of paulownia wood boxes. Picasso was fascinated by the smoothness of the wood and glowed with pleasure as he stroked the surface. Impatiently, Rosanjin thundered "Not the box, not the box, you simple child! What I made is inside the box!"

--Masaaki Hirano & Sidney Cardozo, From The Art of Rosanjin

From Wikipedia, a best practice is

a technique, method, process, activity, incentive or reward that is believed to be more effective at delivering a particular outcome than any other technique, method, process, etc.

If best practices are hard-earned gifts, what is the box and what are the contents?

To me,

the box is the best practice

...not the contents. A best practice is like the kiri used in a tomobako. Kiri survives wildfire because its roots regenerate fast-growing stems. Kiri tolerates pollution and is insensitive to soil type.

The grain of a best practice has a handful of distinguishing characteristics. A best practice

• Addresses a problem or objective;
• Is defined within the context of a community;
• Represents consensus judgment;
• Is judged on results; and
• Is published

The inside of the box is the result or outcome.

What does Best Practice mean to you? I need to understand the benefit of doing something a certain way before I adopt it. Having an assertion hidden somewhere in project charter document that says

The team will use best practices <-----huh?

rings hollow. Vacuouus bromides like this remind me of the now defunct Dilbert Mission Statement Generator.

It is our job to continually foster world-class infrastructures as well as to quickly create principle-centered sources to meet our customer's needs

--Dilbert Mission Statement Generator

It is helpful if teams discuss, understand, and reach a consensus on best practices. That is,

1. Discuss industry-established and personal best practices
2. Understand how these practices might be beneficial to your customer
3. Reach consensus on which practices to adopt as a team
4. Display your best practices in a prominent location

Agile & Optimal Foraging

Honey Bees are oft cited as a biological example of Emergent Behavior and Self-Organization (see my post Self-Organization: Flocks, Schools & Colonies). These examples provide analogies that help us understand team behavior.

Optimal Foraging Theory is derived from modeling organisms achieving the ultimate goals of survival and reproduction. Continually optimizing organisms forage to maximize their energy intake per unit time.

Surviving organisms search for, capture and consume food containing the most calories while spending the least amount of time. Mathematically, organisms adapt to maximize the ratio

E / (s + h)

Where E is the average caloric energy intake, s is the average search time, and h is the average handling time.

A presumed advantage of Agile over the Waterfall Model is the compression of the requirements gathering and Big Design Up Front phases into concise story creation, iteration planning, and time-boxed spikes. In the optimization equation, the focus then is on decreasing the denominator. The advantages of agile over waterfall degrade somewhat as the quality of story creation and planning decreases. This is because search and handling time typically go up (denominator) as story quality goes down.

In the honey bee analogy, the Product Owner is the Queen bee. She holds the group knowledge. The Developers are Worker Bees who perform tasks for the survival of the community. The Subject Matter Experts are male drones (essential but expendable after their duty is performed).

Role	Honey-Bee
Product Owner	Queen
Developer	Worker Bee
Subject Matter Expert	Drone

One of the biggest honey clumps in agile is how stories are conceived, fleshed out, and distributed to the developers. Applying the honey bee analogy to the reality of many agile projects, the queen either has defective DNA or too many responsibilities and, as a consequence, the worker bees are left idling.

The queen has too many responsibilities - After all, she's the collective consciousness of the team and she might not understand her role.

The worker bees are left idling - On many agile projects, developers spend too much time foraging (e.g., searching for digestible stories and handling project artifacts). This occurs due to poorly written stories (e.g., a story title with the word Placeholder -- and nothing else) and when stories lack a bullet list of what constitutes done - acceptance criteria.

Iterating Toward Improvement

To survive and reproduce as teams and as Agilists we must, in a sustainable way, continue to adapt so that we maximize the value ratio.

Caloric energy intake, E in the optimization equation above, being replaced with the third agile principle

Deliver working software frequently

Average search time s and average handling time h, being replaced with second half of the third agile principle

. . . from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

Time-saving gains are still to be made in the denominator of the optimization equation. Teams need better tools, better techniques, and a few tweaks to realize those gains.

Tools: The first generation of agile software tools are a collective hindrance (see Is Version One a Software Chindōgu?) Software teams need better collaborative tools. Improved automation of story creation is needed. For example, software that generate test methods for developers (e.g., Fit). Product owners need better idea aggregators (i.e., a glorified mobile To-Do app for the iPhone or for Android). Developers and Product Owners need software tools that encourage good habits and don't bog down progress with usability issues. The good news is that the software only needs to be better than index cards and Post-It notes. Why can't we do that? I am excited about the potential for the Google Wave platform to grow such collaborative tools (see Google Wave and Collaborative Projects).

Techniques: Several Agilists I respect, pooh-pooh the prescriptive language of Behavior Driven Development (BDD) because it is formulaic or because it is unnatural and not how product owners work. I find the formulaic language to be a helpful foothold for floundering Product Owners (the queen bees with faulty DNA or too many responsibilities) and certaintly more scrutable on a story card than the title Placeholder (I have seen this story title more than once). But BDD is another step toward automation. BDD encourages Product Owners to talk in terms of Roles or Personas and to talk in tests (acceptance criteria). Software automation of such standardizations - if done right - decreases forage time for those hungry worker bees, the developers.

Tweaks: Two rules derived from foraging decision-making that apply to story creation, tasking, and distribution:

Rule #1:

Never eat anything bigger than your head.

Rule #2:

Consume items that lead to the highest gain in Energy/Time.

That is, make sure stories are properly tasked and sized in bite-sized chunks. And, make sure stories are properly staged and prioritized.

Do you have tools, techniques, or tweaks that have helped you?

The Emergence of Google Wave-Etiquette

Since the materialization of Google Wave as a fledgling, real-time collaboration platform, early-adopters have added the word Wavetiquette (Wave-Etiquette) to their lexicon.

wav⋅et⋅i⋅quette

   /ˈɛtɪkɪt, -ˌkɛt/ Show Spelled Pronunciation [wave-et-i-kit, -ket] –noun

1.	conventional requirements as to social behavior; proprieties of conduct as established in waves, wavelets or blips.

2.	a prescribed or accepted code of usage, as in a wave conversation thread.

3.	the code of ethical behavior regarding professional practice or action among the members of a profession in their wave communication and collaboration.

---

Origin:

July 2009. Wavetiquette is a compound word consisting of the English word wave and the French word étiquette. Wave is derived from old english wafian which means to wave. The French étiquette means prescribed behavior.

Synonyms:
Etiquette, decorum, propriety imply observance of the formal requirements governing behavior in a Google Wave thread. Wavetiquette refers to conventional forms and usages: the rules of wavetiquette. Decorum suggests dignity and a sense of what is becoming or appropriate for a civilized person. Propriety implies conventions of morals and good taste.

Wavetiquette - Points to Consider

First and foremost, Google Wave is built on the Extensible Messaging and Presence Protocol XMPP. XMPP is the proven, secure, and extensible Jabber instant messaging platform we have all grown accustomed to using.

Imagine a voluminous thread of discussion with multiple participants where you can see each letter others are typing and you may edit your and other's content at will. Some standards of behavior are needed to keep the flames to a dull roar.

On the Google Wave Sandbox Developer's Preview, early adopters J Aaron Farr (Daniel Teichman, Ross Garler, et al.) initiated a wave conversation on wavetiquette listing the following points of etiquette to consider:

1. When to edit a wave versus commenting?
2. Should you edit your own response or respond to your response?
3. Starting new waves versus resurrecting old ones (and how to politely point people to older waves)
4. Is correcting grammar and spelling always ok?
5. Any thoughts about adding new people to wave?
6. How to keep waves "on topic"? Should we?
7. How to respect the original author(s) of a wave?
8. How to keep wave groups on topic?
9. Do you let the person finish their thought before commenting?

Many of the challenges to Google Wave growth and adoption are soft issues rather than thorny technical issues.

How do we create suitable visual metaphors?

such that participants understand the conversation and are not stepping on each other.

And, early-adopters must establish and explore standards of behavior, that is

What are the social norms?

The introduction of Google Wave to mobile devices like the iPhone presents other soft issues. See a video of Google Wave demonstrated on an iPhone.