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.
To build contractual trust and ease communication, software teams need to define methods for evaluating and prioritizing requirements. These criteria establish boundaries and provide a basis for healthy communication about competing needs. Developing and testing prototypes of the product helps customers make smart choices about what to build and when to build it (Schrage, 1999).
Making Decisions Transparently
Transparent decision making builds and sustains all three types of trust. A crucial part of this process is to develop decision rules and protocols and to stick with them. Another technique is to use a gradient of agreement in which people classify their views along a spectrum (Gottesdiener, 2001; Kaner, 2007). For example, when I work with agile teams we use this tool to check for agreement on our iteration or release commitments.
Good Teamwork Practices
Good teamwork practices help your team members learn to trust each other. One is to build prototypes and models to improve team competence, support communication, and unleash team members' creativity. It's also a good idea to display the team's work-plans, work-in-progress tracking boards and charts, requirements and design diagrams, and more-to make the work transparent and visible. These "information radiators" (Cockburn, 2002) are powerful ways to build and sustain trust.
Well-planned meetings foster contractual trust (the purpose is clear), communication trust (the right participants are there and the meeting processes are effective), and competency trust (communication results in healthy reliance and learning). You can also build trust by holding informal daily stand-ups, prototype demos, reviews, inspections, and facilitated workshops (Gottesdiener, 2002).
It's crucial to hold retrospectives, where team members reflect on their product and process for an iteration, a release, a milestone, or a project. Retrospectives facilitate transparent communication and joint accountability (which is part of contractual trust). These sessions also enable and build individual and team competence.
A team's ability to establish and sustain the three types of trust is an early and critical indicator of project success. Fortunately for project managers, you don't need "trust exercises" that only mimic the real thing. Good practices for eliciting, defining, and developing product requirements also engender trust among the entire project community.
References
- Cockburn, Alistair. Agile Software Development. Addison-Wesley, 2002.
- Gottesdiener, Ellen. "Decide How to Decide." Software Development Magazine, Vol. 9, No. 1, January 2001, pp. 65-70. Available online: http://ebgconsulting.com/articles.php#people
- Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, 2002.
- Gottesdiener, Ellen. The Software
Requirements Memory Jogger: A Desktop Guide to Help Software and Business Teams
Develop and Manage Requirements. GOAL/QPC, 2005. - Gottesdiener, Ellen. "You Know When It's Not There: How Trust Enables and Enhances Collaboration." Cutter Journal, Vol. 20, No. 8, August 2007.
- Hohmann, Luke. Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley, 2006.
- Kaner, Sam, et al. Guide to Participatory Decision-Making. Jossey-Bass, 2nd edition, 2007.
- Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. HarperBusiness; Revised edition, July 1999.
- Reina, Dennis S., and Michelle L. Reina. Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization. 2nd edition. Berrett-Koehler Publishers, 2006.
- Schrage, Michael. Serious Play: How the World's Best Companies Simulate to Innovate. Harvard Business School Press, 1999.
