George Dinwiddie: When I left corporate employment for the life of a consultant, I looked around for places to learn how to be more persuasive. One of those places was the Amplifying Your Effectiveness Conference (AYE). I was a pretty good engineer, but probably a bit below average in people skills. And, one of the big reasons for going solo as a consultant was to take charge of my own career development.
Boy, was that an eye-opening conference for me! I can't come close to listing all the things I learned there and in the subsequent opportunities I've encountered since first attending AYE. Instead of learning how to be persuasive, I instead learned how to observe and understand. It turns out that it's very hard to get people to do something when they don't see any value in it, but they're quite likely [to do it] when that value is visible from their point of view. It's just hard to make that value visible without understanding their point of view.
I also learned to look at groups of humans from the systems thinking angle. Persistent behavior in groups is an indication that something in the system is rewarding that behavior. This realization gives us tools to make better choices—choices that result in a system that gives the results we want. For example, a manager wanting programmers to adopt technical practices that might give higher productivity or a lower defect rate won't change the status quo just by saying she wants them to do so. Instead, she might look for what makes these practices more desirable from their point of view and what other influences are inhibiting learning and the use of these practices. It may be that pushing hard for more productivity is inhibiting the team from taking time to learn new things.
All of the agile methods lean heavily on teamwork to get things done. The method descriptions don't often call that out explicitly, but they put practices in place that enhance the collaboration and interdependencies of small groups of people. I've found that teams that start with an effort to build a "real team" out of a work group tend to succeed much more easily with an agile adoption. Groups that avoid changing the way they relate within the group tend to find little value in their agile attempts.
Don Gray: What's the difference between faux and real teams?
George Dinwiddie: You can look at this difference in several ways. One is in terms of results. Real teams tend to get more done than faux teams. That's because they make good use of everyone’s talents. Everyone contributes what he can, and everyone helps his teammates be able to contribute more.
It's also because real teams are more aware of how their work fits together. There's not a lot of wasted effort on solo work that goes in the wrong direction. That's not to say there's no conflict on a real team. To an outsider, it sometimes looks like there's more conflict. It's out in the open, where it can be readily dealt with by the team members. It's collaborative conflict, even when there's a strong difference of opinion. The conflict is resolved in tiny steps, without anyone going a long way down a path that doesn't fit with the rest of the team.
On faux teams, the conflict may be overt and insolvable, but in corporate environments it's more often hidden and unreachable. The individuals may not be clear or may not agree on the group's purpose. Some individuals likely feel excluded from the real decision making. People may be cautious about revealing their thoughts and feelings because they don't trust that they'll be well received.
Members of a real team know why they're on the team. The share the goals of the team and care about them. They understand who is taking what role, even if the roles are changing fluidly. They trust their teammates and commit—either explicitly or implicitly—to work together in a mutually beneficial fashion.