Indeed, and IMHO an ‘adequately agile’ approach reduces the cost of any
necessary hard turn (major adjustment).

> you need to be able to quickly and frequently vet your course with a
> decent-sized group.

Group members qualities are determinant (better a handful of adequates ones than an army of morons). Hoping to enlist an adequate set of people, often small (let’s say ‘a handful’), by attracting many may work, but replacing a handful by many (not containing any handful) is doomed.

There is no wisdom in a crowd, as such (someone wrote that any crowd is a headless monster), but only a few folks who are ‘gems’ for the topic at hand because they master it and like (or have) to show it. They know the topic because they care (and vice-versa: positive feedback), while others don’t. This is true for sourcing, inquiring and collaborative work.

Some experiments showed that crowds are able to select a better-than-average solution, but it only works when there is a stake for the crowd. Those people bet and hoped rewards, therefore they taped into their own social networks in order to gain useful hints.

Identify ‘the handful’ it is only possible while interacting with the crowd, one cannot specify its characteristics beforehand. Moreover there are many ‘handful’ types, for example some able to describe problems and others solutions.

In my opinion the best focus group is, in most cases, a set of existing customers and serious prospects selected because they emitted, for example through your support service (or bug-tracking system) reports (’files’/'tickets’/…).

Neglect any blatantly non pertinent report (things solved thru corrective maintenance, RTMF…)

Let your sales and marketing teams preselect a fraction (10%?) of those wishes. They will favor financially promising stuff.

Then have your developers select, among the retained fraction, a very small set of “interesting” ones. They will favor innovation and letting them select will have them eager to fulfill the mission.

Beware: no one has the right to modify the ticket, only use what the customer wrote/said!

Then contact all the customers and select the wish backed by a willing, serious and available one. Analyze the wish in order to define its generic components, what can be done in order to extend the usefulness of a tool fulfilling it. Grab customers and prospects interested by the generic problem, let all those people (customers, mktg and developers) meet, maybe offer tools to collaborate, but let the customers & prospect be the large fraction of the audience, and have your people only there to catalyze the dialog and to listen. Focus in order to produce a good description of the problem to be solved, of the need, the constraints (not the solution!). Fight hard in order to have the most charismatic, highly motivated and available attendee become the group leader. Maybe offer a collaborative platform for their work.

As a co-founder and CTO of IDEALX, which became http://www.opentrust.com/, I already applied most of this.

Ning networks are also useful in the way that they connect peer groups. For example I’m a member of the University Web Developers Ning Network. There users can ask questions ranging from what content management system they should employ to questions of ongoing support. The network has groups dedicated to topics ranging from design to specific software programs used in Web development. Having access to a a group of peers who face similar challenges and problems is a great resource. It’s like having a team of mentors on call.

Social media also helps keep us up-to-date in our fields by exposing us to articles recommended by peers and is a great way to solve tiny problems quickly. If one needs a quick fix on something technical, the answer is probably a moment away on Twitter. I think this also supports agility because it helps us spend more time on the important things and less time researching problems that often amount to troubleshooting. Tapping into the collective wisdom is helpful on a variety of levels.