"Trust" isn't a word I hear much in relation to software development, but trust--actually, lack of trust--is the source of many common software development practices. These practices mitigate some risk of working with distrusted parties, but they're inefficient, even harmful. We produce better, more valuable software when we replace distrust-based practices with a strong, trust-based relationship... although that's easier said than done.

The clearest example of our distrustful relationships is the typical arms-length relationship between product manager, responsible for business value, and developer, responsible for implementation. (Although I refer to these roles as individuals, both can be groups of people. Also, the product manager role isn't always formally defined.) Often, each side is afraid of being blamed for failure and neither trusts the other to perform their duties competently. Artificial walls are erected, replacing direct communication with obtuse requirements documents and formal sign-offs.

In this environment, I see dysfunction on both sides. Product managers often treat the software product as the development team's responsibility, not spending enough time on identifying and communicating business value. Developers often treat the software product as a jumble of requirements to be built in order of technical importance, tightly controlling change and limiting options for improving value. As a result, the most essential aspect of software development--how this very expensive software will provide value commensurate with its cost--is neglected and the product falters.

In trust-based environments, we replace arms-length relationships with close collaboration. Developer and product manager share responsibility for success and work closely together to produce the most valuable result. Product managers make small changes in features to meet technological constraints, reaping large cost and time savings. Developers focus their efforts on delivering value, not technology, allowing ROI-increasing interim releases to be delivered. Changes to requirements are welcomed, because both parties understand that they are introduced only when their value substantially exceeds their cost.

Of course, putting developers and project managers together isn't going to automatically build trust. First and foremost, the team must be set up to succeed. Trust isn't possible if product managers don't have time to be part of the team or if developers have trouble delivering to their estimates.

Even once the basic elements are in place, trust can't be mandated; it requires slow relationship building between individuals. We can help the process along by giving our teams opportunities for frequent, meaningful, shared successes. My favorite way of doing so is to introduce short iterations and frequent releases, as it's very effective and provides many other benefits. Be cautious with this approach, though, as it requires prior experience and careful mentoring.

This is a complicated subject with diverse interactions, so my goal with this newsletter is to introduce the concept rather than suggest specific changes. I've barely scratched the surface of replacing distrust-based practices and I hope to cover this subject further in future newsletters. In the meantime, take a look at your current software development practices. How many of them are based on distrust? How would converting to a trust-based model improve the value of your software? The answers aren't easy, but they're certainly worth exploring.