Teams Blog

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.

I was fired from my first true project manager job. Though I’ll note that the person who fired me was himself fired a few months later, there were some legitimate beefs. The biggest mistake I made was in not telling the sales staff what they were asking for in my first assignment was impossible. I wanted to make a good impression and seem cooperative, but of course the project failed miserably and I never really recovered my credibility. I also didn’t understand the PM role in a customer-facing position. Though the project process I applied in each of my projects was appropriate, and worked well in the rest of the projects, I did not adapt it enough to meet the ultimate outcome: a pleased customer. The boss said I was “too process-focused.” At the time I was flabbergasted by the statement, given that he was a PMP® (certified Project Management Professional) and yet had zero PM processes in place. Projects were inefficient and often missed their targets.

We both might have kept our jobs had we found a better balance between outcome and process. A TeamResearch News summary I just posted reports on a study that addresses this need. It found, first, that student teams who took time to do any planning at all did better at a game requiring teamwork than those who didn’t. Those whose planning focused on the goal rather than the process did better when some of their resources were taking away halfway through the game. The researcher believed the outcome teams were better at adapting their processes to the change. The type of planning made no difference when a team member was added late. I’d guess adding a member required no process change, whereas losing materials might.

This was reassuring to me because my teamwork training method, The SuddenTeams® Program, reflects these findings. The study author, Harvard-trained researcher Anita Woolley of Carnegie Mellon University, writes in her article that managers should “pay attention to how they structure early team meetings and the relative emphasis they place on processes versus outcomes.” Based on what the scientific literature had told me, I have teams address both goals and processes. But the order of events relative to this issue is:

1. Set a team mission.
2. Set goals toward meeting the mission.
3. Identify team stakeholders.
4. Document team and work processes.

Immediately after that, the team dives into process improvement. Written processes are a key step in every quality improvement system like TQM and Six Sigma, and invaluable for improving efficiency and reducing conflict. But The SuddenTeams Program puts the emphasis on what the team is accomplishing and for whom before defining how to get there. As the study shows, and my firing taught me, both the outcome and processes are critical to maximum team performance, but you have to keep your eye on the prize.

Comment