“Trust only movement. Life happens at the level of events, not of words. Trust movement.” — Alfred Adler
David J. Anderson has recently stated the opinion that trust is the essence of agile development methods. He says that trust is more of what agile is all about than short feedback loops and a focus on people as people. I have a different perspective.
David says that neither of these latter techniques are new and, to some extent, he’s correct. However, although iterative and incremental development has been around for quite some time, these “iterations” were often months long rather than weeks. Even on agile teams, iterations are also a relatively coarse form of feedback. The XP teams I’ve worked on have tried to keep feedback loops between development and the customer in the few hours to few minutes range. This is quite different than the vast majority of pre-agile incremental and iterative software development projects. It doesn’t take much process or organizational overhead before it starts interfering with those very tight feedback loops.
I’m not exactly sure what “treating people as people” really means although I understand the emotional element of not wanting to be treated like an interchangeable part. However, I don’t believe that simply treating a person as a person necessarily results in agility. The focus of agile teams is on people working together in a opportunistic and synergistic way to fully leveraging the team’s aggregate skills and wisdom. It’s impossible to predict exactly how this interaction will look for a specific group of people in a specific context. That’s the danger of heavier process-oriented approach. The fallacy is that someone can know the best way for this specific team to get their job done. My experience is that project leaders with this perspective tend to treat people and teams as abstractions with predictable performance characteristics rather than highly variable, unpredictable, and extremely adaptable human beings. Most of the software projects I’ve led or worked on have existed in a dynamic environment. For me, one aspect of “agility” is the flexibility that teams of people have in adapting the way they work to best fit a specific situation. Given the “specific situation” (the team, the organization, the project goals) is constantly changing, it’s easy to see how rigid development processes tend to be far less effective than agile ones.
Now, back to trust. Is it the essence of agility? I don’t think so. I believe it’s a side-effect. I believe the essence of agile software development is delivering more value to the customer. Put another way, the goal is to find better ways to provide the customer with what they expect within the expected resource limitation (time, budget). Short feedback loops (very short, not months long) help keep developers from straying too far from what the developers are building and what the customer expects to be built. Emphasing team adaptibility and empowerment rather than treating them like a multiagent software generator that can be “programmed” with rigid process instructions allows the team to respond to unforeseen events with less impact of project deliverables. Again, this helps the team meet expectations.
When one person depends on another, I believe trust is a side-effect of meeting expectations reliably. Customers depend on developers. If developers consistently deliver high business value software on time then customers will trust them. When the developers deliver high quality software frequently, the trust develops more quickly than with long feedback cycles. Developers depend on customers (especially proxy customers) to steer them in the right direction. Close interaction with customers and continuous feedback from them improves the quality of that steering. Expectations are met, trust is built. I agree that there probably is a process feedback loop when increased trust results in the organization allowing the team to be even more agile. In that sense, I agree with David that, without trust, it may be very difficult to loosen up the process to allow ultrashort feedback loops and adaptive, empowered teams.
I wish I was going to be Denver next week for the agile conference. I’m sure David’s talk and the following discussions will be very interesting.