In a TV commercial for an auto insurance giant Geico, a clueless boss says to the hip gecko (the company's mascot),"Trust is key when talking about Geico. Ya gotta feel it." The executive then suggests they take part in a trust exercise "where I fall backwards and you catch me." He rises, turns his back to the tiny lizard, and begins to fall. The gecko-outweighed by, oh, 180 pounds-mutters, "Oh, dear."
Trust is key in all kinds of business settings, including the most daunting part of software development: defining the product's requirements. Without trust, development teams experience project churn, high turnover, low morale, and unhappy customers. Stakeholders may cultivate hidden agendas, spread rumors, whine instead of contribute, and even subvert the team's work.
But contrary to the TV boss's beliefs, you don't nurture trust among your team by making people (literally) trust that they have each other's backs. And even though you "gotta feel it," trust isn't simply a feeling. Instead, trust grows out of good requirements practices that are established up front-at the start of your project-and serve as key elements of the team's standard processes.
Insights About Trust
Reina and Reina (2006) identified three types of trust that organizations need to foster. Contractual trust is based on an unstated agreement that everyone is jointly responsible for the success of a project. This is the kind of trust the insurance guy is looking for: you have my back, and I have yours. If things change, we will renegotiate. Communication trust depends on frequent and honest communication. Team members share (not withhold) information, tell the truth, acknowledge their errors, respect confidentiality, and seek and provide feedback. Their actions are consistent with their words. Competence trust means that team members respect everyone's ability to get the job done. They promote mutual learning and development of everyone's skills and knowledge. The good news? Using good requirements practices-the ones you should be following anyway-builds these three kinds of trust.
Building Trust by Defining Vision and Scope
A product vision describes what the team needs to build and for whom, and it explains how the product will serve its customers and will differ from existing products. Developing a vision of your product builds trust. I like to facilitate this process by using hands-on activities, for example, leading team members in drawing a picture of the before and after state or creating an imaginative "product box" (Hohmann, 2006). I combine these activities with writing a vision statement, often by using Geoffrey Moore's product vision format (Moore, 1999). This process builds contractual trust by establishing shared goals for business experts and technical staff. It acts as a contract for what will be built, and it establishes boundaries within which trust can operate. If the team can't agree on the vision, you're not ready to plan and build the product. As the project unfolds, teams should also maintain a glossary to define business terms. When team members understand and speak the same language, it builds competency and communication trust.
It's crucial to have the right stakeholders participate in defining the product vision and requirements. The first step is to identify stakeholders and other sources of requirements information. Consider a variety of people who can take on the perspectives of different stakeholders: product owners, champions, sponsors and buyers, end users, subject matter experts, developers, business analysts, project managers, specialists in testing, QA, auditing, regulatory issues, training, sales, marketing, and so on (Gottesdiener, 2005).
You build communication and contractual trust by planning how and when to involve stakeholders. You sustain trust by following through and collaborating to explore, elaborate, and decide on requirements. Another good practice-planning how the project will acquire and improve team skills-also promotes competency trust.