Effective collaboration is far more important to us than having a Product Owner (A.K.A. Single Throat To Choke) select and prioritize work.

We seek out differences in opinion rather than expect one person to make key decisions.

Two collaborative practices that help us economically evolve great software products/systems are:

• Prioritizing — splitting essential from non-essential functionality so that we may order the work by importance.
• Bargain hunting — discovering the least expensive, highest value way to produce essential functionality.
  

For any given week of development of our Agile eLearning software, our lead Customer (me) presents a rough sketch of priorities, a diverse group of us refine those priorities (dropping what we thought we needed), and then we collectively hunt for bargain ways to build what we need.

Prioritizing and bargain hunting are best done by a community of diverse roles rather than one person with a single perspective.

In larger shops, we help establish a diverse group of people who collaboratively prioritize and bargain hunt. These folks are usually managerial or technical people in Customer and Development Communities.

Customer Community Roles

Key roles I like to see within a Customer Community include:

• Lead Customer—A facilitative leader who listens, questions, thinks deeply, helps resolve conflict, understands organizational needs.
• Subject matter expert—Understands what the product/system must do, what users most need.
• Business analyst—Understands or learns feature details and their importance to users.
• Sales and marketing—Understands what closes deals and attracts customers.
• Operations—Understands what customers complain about the most.
• Architect—Understands how architecture can help to deliver greater value faster.
• QA—Understands what done means.
• etc.
  

Development Community Roles

Key roles within a Development Community include:

• Lead Developer—Understands technical issues, the software, the organization, the people.
• Experienced designer—Understands design trade-offs, creative ways to deliver high value.
• Technology dabbler—Understands many old/new technologies and how they can provide bargains.
• Problem solver—Understands creative ways to solve problems, including non-software solutions.
• Architect—Understands how/when architecture plays a crucial role in avoiding waste.
• Programmer—Understands how to produce the right quality of code for the given priority.
• etc.
  

Disagreements about priorities, value or sufficient quality are inevitable.

Leads resolve such conflicts, arrive at consensus or make a final decision.

The emphasis is on the community, rather than the lead, since we value the community perspective more.

The community and its collaborative planning practices may play a huge role in saving time and money.

At XP2002, Jim Johnson, chairman of the Standish Group, described the enormous cost and time differences in developing a federally mandated SACWIS (Statewide Automated Child Welfare Information System) for Minnesota and Florida. Minnesota did the work with 8 people in one year for USD 1.1 million, while Florida had used over 100 people and spent USD 170 million by 2002, without delivering anything.

They hoped to deliver by 2005.

Jim noted that the Minnesota team was better at reducing scope in requirements and using standard infrastructure.

This suggests that they had a culture focused on finding bargains and prioritizing essential functionality.

On the other hand, the bloated Florida team was perhaps blindly following a specification, not splitting essential work from inessential work and not looking for bargains.

If you want to be genuinely Agile, not pseudo Agile, form a diverse community of roles to continuously prioritize and hunt for bargains.

Stay tuned for a future post in which I’ll describe bargain hunting in greater detail.