Problem solving & low scale decision process

In this post, we’ll try to address the decision process that happens at low scale, more precisely within a team of 2-8 people building software (see http://alexandre-masselot.blogspot.com/2011/08/creating-scientific-bioinformatics.html for the role of such a team). By low-scale, we mean that we will not talk about high level orientation choices (even though there is much in commons), which are out of the scope today.
Once a goal as been stated beforehand (upper management, marketing, scientific, sprint start meeting or whatever), we must decide on how this goal should be reached and it is exactly this step that we’ll talk about here.
Such decision taking is of course a daily process in software development that can involve the full team, a subset for a dedicated aspect, a mix of developers and customers or even only two persons in pair programming. It can cover brain storming, architectural aspects, risk planning, strategy, task scheduling, technology choice, minimal viable product target (http://en.wikipedia.org/wiki/Minimum_viable_product), software design etc. This process can take a few minutes, one hour or even full days (off-site brainstorming).

During an expedition in Patagonia in 2001, two of us faced the challenge of crossing during 15 days an incredibly crevassed area with heavy loads - 40kg. The final target was clear: reach a pass (we christened it “relief pass”). Meanwhile, every hour we had to stop and decide which route was the safest, the shortest, less dangerous and possible for the next move. Each of us often had diverging opinion upon the best choice, so we took the habit of explaining our own preferences in turn, talk about it and decide. The emerging solution was often not one or the other initial proposal, but a third one, where the point was not to make our own solution win, but to build together the best one. The argument was lasting a couple of minutes and let us reach our target... alive.

What is a good decision?
Once the goal as been stated, the decision(s) has to be taken taken on how to achieve this goal. Two important aspects are to be taken into consideration:

• a clear scope on the pre-requisite, in order to identify what should be fulfilled;
• a best (cheap, simple, fast etc.) possible solution is to be designed to attain the target; 
• team members must adhere to the selected solution (“low scale” means that they will have to implement the solution, so better be motivated);  

Decision process is not just blah-blah and waste of time, as we often here.

Poor (and common?) decision process patterns
You can certainly add your favorite situations here, but here are a few common patterns:

• God words: some upper, self-assumed wiser chief design problem, solution and details of implementation. Little if any room is let for the team to challenge solutions. 
• “Expert” team member get it all: a team member, who is regarded (or self-regarded) as the most expert explains the problems to others and forces his own solution. Being the most expert, he can easily kill any suggestions (if any) by other team members. As a hard-worker, he is looked as a rescuer of the project and with many nights of works, maybe will solve the problems. 
• The loudlier speaker gets it all: a variation of the previous pathology. The one who speaks the faster kills the discussion. 
• No (clear) agenda: people meet “to take decisions”, but no agenda or goals have been clearly stated or identified beforehand. 
• No decision process: no discussion takes place at all. Solution (which will concerns other team members) is assumed by one developer. 

We all have certainly seen such processes more than once (and personally, I have often taken the role of the bad guy - in the past;) ), but let’s see what we can do to improve the process.

Improving the process
In order to reach a better decision (as defined earlier), we can propose three steps.
Identify the goal

Of course, before trying to find a path to a target, we must know where we head to. We can refer to a previous post dedicated to agile planning http://alexandre-masselot.blogspot.com/2011/08/creating-scientific-bioinformatics.html.
Rely on the team intelligence

Most often wiser than an single individual (check paper by Woolley below), the group will design a more efficient solution to the problem. We can apply a few rules to help the process:

• try to mix various profiles in the team: junior/senior, women/men, different technical skills, scientists/customers/developers as they will raise different opinions.
• Let people express their points of view, their questions. A key aspect is to get the discipline of not interrupting the person talking and to let people who express the need to talk one after the other. Well, that’s only politeness but it’s very effective or we’ll see only the loudlier speakers getting the token. This point is even more crucial when we have some participant on the phone. 
• Encourage “shy” (or silent) people to give their advice. Intelligence is little correlated with aggressiveness or even self confidence. Building a team culture of “listening to others” is not that hard and everyone soon feels comfortable with it.

Get the team members commitment

Well, if we apply the previous rules, it is straightforwards that decision becomes one of the whole group. And the group soon grew up into becoming a team, with a strong spirit.

Everyone feels more at ease with the implementation stage and should not hesitate to relaunch micro-decision talks with the same patterns during coffee (or cigarette, for smokers) breaks.
Finally, practice shows that discrete team members soon become more active, less introvert and everyone benefit from this spirit. And junior members, through these discussions, will grow up much faster.

Further readings

Evidence for a Collective Intelligence Factor in the Performance of Human Groups http://www.wjh.harvard.edu/~cfc/Woolley2010a.pdf