I believe consensus is the single most relevant factor in determining the effort and time required by a software project (or perhaps any other human endeavor), and also the best predictor of its success.
Consensus may be broken down in different ways, but one way is to look at the populations involved. Each basic type of activity in a software project requires consensus. These include problem definition, requirements and analysis, design and construction, deployment, and administration.
For problem definition, to put it simply, you need a consensus between the GoalDonor
. If that commitment isn't there, you will
have problems down the road. You also need a kind of consensus (loosely interpreted) or "fit" between the problem to be solved and the available technology. Determining if there is such a fit is sometimes called a FeasibilityStudy?
For requirements and analysis, there needs to be a consensus between the
and those responsible for carrying the message to the development team. For example, the same concepts, relationships, business rules, etc. are understood the same way by both groups. Any discrepancy between these groups is usually magnified by downstream processes.
For design and construction, two types of consensus play a part. One is between the members of the software team. Every deviation from a common vision, such as hidden assumptions or misunderstandings, will usually show up as a bug. The other is between the developer and the computer (again, loosely interpreted). A lack of "consensus" in this area could be due to a LearningCurve
, poor documentation, or unreliable tools. Evidence of consensus in this area is when a developers expectations of the behavior of the development tools, libraries, target platform, and their own code are consistently correct.
I think a focus on consensus (sometimes in a broad sense) and the ways to improve it will dramatically improve our projects' productivity and success rate.
Consensus may be achieved by several means. Research and study can bring developers closer to domain experts and vice versa. Conversations, informal relationships also help. Various facilitation techniques do, too. Different methodologies affect whether a team converges on a common vision, given various team personalities and operating conditions. Culture and management style weigh in heavily.
Note that consensus does not have to be democratic. Some of the most effective consensus is achieved by a hierarchical system of authority, such as in the military. The effectiveness of a consensus, for the purposes of what I'm saying, is not based on whether people personally agree with something, but on whether they have the same internal understanding and act consistently with that understanding.
This idea of consensus explains how some teams can work very effectively with methodologies we think are "broken" and how state-of-the-art methodologies can fail.
I'm very interested in others' views and feedback on this insight (perhaps a redundant statement in this forum! :-).
The most useful working definition for consensus that I've come across is:
- finding a proposal that everyone can live with
- not finding a proposal that makes everyone happy.
More fully, from 'The Team Handbook', ISBN 0-9622264-0-8
- finding a proposal acceptable enough that all members can support it; no member opposes it
Consensus is not
- a unanimous vote - a consensus may not represent everyone's first priorities
- a majority vote - in a majority vote: only the majority gets something they are happy with; people in the minority may get something they don't want at all
- everyone totally satisfied
- active participation by all group members
- communication skills: listening; conflict resolution; discussion facilitation
- creative thinking
My favorite anecdote about consensus is the story of how the band 'Swing Out Sister' arrived at their name. It was the one name that all of the members agreed that they hated.