7 Agile Leadership Lessons for the Suits

CIO — Most of the 400 presentations at the Agile 2008 conference, held last month in Toronto, were geared for developers and testers. But the event held more than a few revelations and "Aha!" moments for IT managers, particularly revolving around team workflow, business value, company culture and the new role of the manager. Here are the key messages communicated by and to the Agile community.

1. Trust the Wisdom of Teams

Software is a result of a team effort, so a manager's main concern should be nurturing the team. But how many of us see our roles as enlightening an otherwise substandard and underperforming bunch of geeks who would escape their duties the moment we take our eyes off them? No, we never talk this way, but smart developers can conclude from our actions when a manager does not actually trust the team. The result is lower morale, underutilized brain resources and lost opportunities.

In his conference keynote, James Surowiecki, author of The Wisdom of Crowds, described how groups demonstrate better decision-making results than do individuals. We need to aggregate the intelligence available to organizations, he said, and develop frameworks for making near-optimal decisions.

Among the pitfalls that Surowiecki described was the importance of diversity because homogeneous groups become "dumber." The role of devil's advocate is essential, he said, to avoid group degradation. However, over time, a homogeneous group gets used to its devil's advocates and learns to disregard their reasoning. As a result, you need to mix up who wears the devil's-advocate hat.

2. Even Self-Organized Teams Require Coaching

Command-and-control practices inevitably lead to substandard results in software development. However, it would be naive and irresponsible to imagine that turning teams into self-organized machines means abdication from managerial duties. On the contrary, Agile principles require managers to become leaders, and that goes all the way up to the CIO.

Many presentations revealed several results-based techniques in team dynamics. One was a tutorial on "Coaching Self-Organized Teams" delivered by Joseph Pelrine and Steve Freeman.

Pelrine and Freeman focused most of their attention on models managers can use to leverage team conflict, such as the Abide model (attractors, barriers, identities, diversity, environment). By changing those parameters, the presenters said, you can change the results. Using the Flow model, managers can pay attention to the acceptable level of challenge based on an individual's skills to find a balance between anxiety and boredom; they suggest you can manipulate the flow channel based on the learning patterns team members demonstrate.

3. Adapt or Get Out of the Way! The New Manager's Role

What is Agile leadership? What does it mean to lead in an "agile" manner? This was the theme of the hands-on, dynamic and creative workshop "Agile Leadership" given by Johanna Rothman, the author of Behind Closed Doors and Manage It!, together with her coauthor Polyanna Pixton. The workshop concentrated on collaborative environments, trust, transparency of information, and building productive and sustainable teams.

The group considered that the most important duty of an Agile leader is to build trust on every level; it compared situations where "trust has not been built yet" and "trust has been broken." Trust is a fragile binary state; regaining trust is much more difficult than building it. Sometimes, broken trust cannot be rebuilt; a leader needs to simply accept this fact and move on, said the presenters.

According to Pixton, a key factor in building trust with the team is a leader's consistency in making decisions and what these decisions concern. We managers often forget the second part of that statement. When we do so, it leads to micromanagement, underutilization of the wisdom of teams and eventually to the deterioration of trust.

No matter how many people are on your team, the presenters insisted, you need one-on-ones with every team member at least once every two weeks. This includes the leader's peers. While this maxim hardly seems feasible for larger teams, every inch of retreat from it costs in trust deterioration.

The workshop was full of such "simple revelations" that offer "obvious" but often underutilized bits of wisdom. For example, one participant asked, "How do you make team members trust each other?" Rothman immediately replied, "You trust them first!" Perhaps the answer seems obvious, but do we always "walk the talk"?

Not every bit of advice is as easy to adopt. One presenter said, "Never rescue your team." Teach as little as possible, she said; instead, create as many options as you can. The team should feel the same pressure its manager feels. It's the only way to force your team to think and to offer solutions; and, she said, it's the only way to create a self-organized team. The manager's duty is to discuss with the team the risks associated with each solution. But when a team member comes to you for a solution, said the presenters, return the baton to him by first asking, "How would you do it?"

For example, one presenter said to a subordinate, "I have to apologize that I had to step in and do it for you. You probably think now that I do not trust you anymore. I apologize; this will not happen again." That's a tough lesson for a conventional manager!

Next: The Yearly Employee Appraisal, and other ways to de-motivate teams

Continue Reading