The Trust Cycle

My Dad is constantly telling me that to build a high performing team, you've got to drive trust deep. One of the central reasons I enjoy working on the Infrastructure team in the Macintosh Business Unit is our mutual respect and trust. I just found a new blog on agile methods and what do you know, but that's exactly what he defends: Trust is the Essence of Agile

Agile software development brought the idea of trust to the forefront. When there is trust, there is less waste, less extra work, less verification, less auditing, less paperwork, less meetings, less finger pointing, less blame-storming. Building trust between the engineering group and the customers is the first goal for any agile manager. Equally building trust with and amongst the engineering team is also essential. So many aspects of agile methods are about building trust - frequent delivery, focus on working code rather than documentation, face-to-face communication, pair programming, peer reviewing, stand-up meetings, shared responsibility and joint accountability, direct customer collaboration including on-site customers and customer involvement in modeling sessions, estimating, tracking and reporting based on customer valued functionality, information radiators, big visible charts, burndown, cumulative flow and ultimately complete transparency into entire engineering process. Agile for the first time, enables us to run software development like other parts of a business. It clears away the fog. It lifts the veil of secrecy. It blows away the opaque clouds and reveals the naked truth of what is really going on.

Good stuff. He's working here at Microsoft now, trying to change things around. It will be interesting to see the effect.