The benefits of empowered teamwork are one subset of the benefits of Agile software development. Having served as a project manager in an Agile company, I have seen this firsthand, but a talk by an "Agilista" last night confirmed my belief.
If you know about Agile, you might want to skip down three paragraphs as I explain it to newcomers. Traditional "waterfall" methods start a software project with an attempt to capture everything the end user needs to do and estimate the time and money needed. Once that information is approved, next comes design of the software. Then the software is created ("coded"). Next comes the testing phase, during which mistakes ("bugs") are fixed until the client accepts the software. Finally comes rollout of the product. Each step flows downward into the next, hence the "waterfall" allusion.
In Agile, an initial set of requirements is collected and prioritized by a "product owner" working with the client. These are broken into small chunks, feature by feature, and captured in a "product backlog." The product owner, a facilitator, and the other team members take a short period to do some initial design work. Then they decide how many of the features they can finish within a pre-selected time, usually two to four weeks. In perhaps the best known Agile method, the period is a "Scrum" and the facilitator is a "Scrum Master." Once the team decides what to do, that set cannot be changed short of an emergency. The team then does a mini-waterfall of sorts, finishing the selected set of features to the degree they could be released to the customer (whether or not they are right then). After a demo and lessons-learned review, they repeat the whole process with the next set of features, starting the next business day. They're done with the whole thing when the customer says they're done.
At a meeting of the local chapter of the Association of IT Professionals, Robert Galen spoke on "Mature Agile Teams--Sixteen Essential Patterns." Galen is director of research and development at iContact, an e-mail marketing company, and also has his own Agile consulting practice. Along with making me feel better about two points over which I parted ways with the aforementioned company--for those keeping score, I was right on one and half-right on the other--he provided a number of points about teamwork that work in any environment.
One of his 16 "patterns" was "Truly Collaborative Work." Examples on his slide included, "Developers willingly engage in Testing." This is not common in waterfall projects, and I have witnessed how it improves quality and cooperation. Another point was, "Members help each other out." Science has shown that "organizational citizenship behaviors" improve team performance. "Listening to each other; mutual respect" appeared as well. In poorly performing teams, people listen at each other, listening but not really hearing (hence my Active Listening class).
"Behaving Like a Team" was another of Galen's patterns. I especially liked his point about "Providing each other congruent feedback." Agile promotes a practice I suggest for all teams in my teamwork book, daily "stand-up" meetings. These are conducted literally standing up, for a maximum of 15 minutes. Each member reports on only three things: what I did in the prior work day, what I plan on doing the next day, and any blocks I've run into. The last item becomes a top-priority action item for the facilitator. Galen said members of effective teams also participate in "Passionate debate." He added "conflict," but I later suggested the word "confrontation." The scientific evidence shows that conflict of any type harms teams, but members must be willing to confront each other to make better decisions. Galen also said members will spend personal time together and succeed or fail "as a team."
The research literature supports the use of self-managed or self-directed teams in most circumstances. Under his pattern, "Quality on all fronts," Galen said Agile teams are "Self-inspecting; self-policing; self-learning."
He did an excellent job of defining the role of the supervisor of a self-managed team. My oft-repeated summary is, "Tell the team what direction you need it to go, give it its boundaries, and get out of the way." Then you fall in behind, making sure the team has the resources it needs and nudging it to stay on course. A previous speaker last night had a great analogy. Josh Anderson, Agile Coach at Teradata, likened this to raising the bumpers when you take kids bowling, so their balls stay out of the gutters. Galen's related pattern was "Saying NO as a Leader." He emphasized that managers can't just walk away from the team, and added in bullet points:
- "Sometimes direction is required."
- "Courage to tell it like it is."
- "Behind the scenes, 1:1 Coaching..."
Finally, he emphasized, members' first loyalty must be to the team. This made me uncomfortable, because plenty of teams have failed by focusing too much on themselves. But Agile's emphasis on including at each step the customer's representative (the product owner), and often the customer, is a perfect way to align team cohesion with business goals.
