On Consensus
On ConsensusI 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 and GoldOwner. 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 BusinessDomainExperts? 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! :-).
--JeffMantei 2000-12-06
The most useful working definition for consensus that I've come across is:
Consensus is :
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.
See LetsPlayTeam
EditText of this page
(last edited March 29, 2005)
or FindPage with title or text search