The Agile “self organising team” paradigm demands new skills of team members – including the people skills for which they may once have depended upon their Project Managers. For teams transitioning to self-organisation, management can play an important role in helping them learn new ways to communicate and collaborate. But where to begin? This article proposes some strategies for imparting new skills without crushing a team’s growing self-organization, and suggests some sources of helpful material for developing new skills.
“That it is people who write software is terribly obvious . . . and ignored.”
-- Gerald M. Weinberg, quoted by Alistair Cockburn in Agile Software Development.
Agile Raises the Bar
Author Alistair Cockburn has challenged the false stereotype of programmers as non-communicative individuals, saying: ”Programmers just like to communicate about things they like to communicate about, usually the programs they are involved in. ... They just don’t like joining in the chitchat about things they consider irrelevant.” What’s different with Agile is its emphasis on cross-functional teams and face-to-face communication, which greatly broadens the scope of what’s “relevant” to a developer’s effectiveness.
Now, in addition to programming excellence, developers must speak the business jargon of their customers, decipher the body language of their war-room teammates, learn to give constructive feedback, and figure out how to pair-program with diverse personalities. The intensity of Agile work, often attributed to improved throughput, may also come from the increased demand to remain productive while handling complex relationships inside and beyond the team.
Once our cubicle walls are gone, either figuratively or (better) literally, we can no longer hide, waiting for the manager, the business analyst, or the tech writer to figure out “the people stuff”. To achieve high-productivity it’s essential that the team be self-managing, meaning that interpersonal or so-called “soft” skills must increasingly find their way into the team’s day-to-day work.
Who Should We Train?
It’s tempting to think that such training should go to the more mature members of the team, to “business-y” roles. Not so! Agile levels the playing field: all members contribute equally to the team’s product - the team can be influenced or limited by the behaviour of any member. Scrum practitioner and coach Simon Baker reminds us that even the act of programming is “a social engagement, a conversation” which benefits from enhanced people skills:
Successful pair programming is as much about effective soft skills as it is about technical skills. Each person engaged in pairing needs to be sensitive to the other person, and listen effectively and read their body language; be able to convey ideas, engage in constructive disagreement, offer alternatives without judgement or condescension and persuade the other person; have the ability to sense when to offer help and be humble enough to ask for it. It's a shame many programmers struggle with these soft skills.
So, How Do We Fix Our Teams?
Should managers now take on the role of “fixing” teams and team members? Must everyone do everything well? Should we just cross-train everyone for every role? For self-organizing teams, such intervention could work against adoption of the new paradigm. For true effectiveness, a coaching stance is more appropriate: helping the team decide, for itself, how to distribute the work and who to cross-train. The objective is not uniformity of skillset, but effectiveness and whatever enables effectiveness in a given context. On the subject of cross-training, one programmer wrote:
I don't agree with the premise of improvement of weaknesses. I like the premise of enhancing talent and being aware of weaknesses. “Know yourself” doesn’t mean go learn everything and become a Swiss Army Knife.
Scott Ambler, who coined the term “generalising specialist” concurs:
A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. Big difference.
Traditionally, performance objectives include a training plan to broaden each member’s knowledge, but these are infrequent, and it’s hard to guess what skills the team will need a year in advance. Training targeted toward to real, current situations would be more effective – but how can a manager find the help and resources the team needs on short notice? Here’s one place to start: let the team find them.
Help the Team Look for Solutions to Pressing Problems
One way to help the team learn the skills they need is to to encourage them to discover what’s holding them back, and support their search for answers. The search for improved communication should be viewed as an experiment, as is any process improvements the team applies: try it, reflect, learn, try again. Provide material that fosters learning: journals, books, articles and podcasts. But don’t forget time as a resource: offer them coaching, conferences, time to surf the web or to visit with other teams to find solutions, or add a “learning” task to the next iteration. When teams hunt down their own answers to what hampers their ability to produce value, they get the benefit of learning immediately followed by application, a great way to make training stick.
If effective, the team's own continuous improvement efforts can turn up needs and even suggest strategies. Esther Derby and Diana Larsen's Agile Retrospectives: Making Good Teams Great can help teams develop this valuable practice.
Note, though, that this reactive approach counts on the team’s ability to spot trouble, to speak frankly, and to imagine where to look for help. An inexperienced team may stumble upon an important “people issue” but consider it a mere annoyance, missing the warning it offers. And, under stress, as when trouble breaks out, they may not be in the best shape to start looking for answers - turning to habitual behaviours instead. For some teams, additional strategies may be helpful.
Model New Ways to Approach Problems
For teams just emerging from cubicles, the skills needed for constructive collaborative meetings may be largely absent. Bring in an outside facilitator, or find a natural facilitator in the team and train them as a ScrumMaster or facilitator. A designated facilitator can help a team get beyond frustration, to solutions. A facilitator remains impartial and removed from the fray - he or she can encourage the team to see their people issues more objectively, as a normal part of growing their own process.
Facilitation takes the sting out of difficult conversations and models new ways to interact and problem-solve. For example: too often new facilitators focus on their comfort zone, inside the team, and they forget to set expectations with stakeholders and others outside the team. For example, an outside facilitator can help an apprentice learn to interview the sponsor of a meeting or a project, and come to agreement with them, to ensure that all participants are focused on the real end goals, setting the team up for success.
Team members are likely to learn through observation to facilitate - they may even ask for training. Depending on the stability of the team and their environment, facilitation could be a short-term role, with the facilitator could taking on other responsibilities as the team becomes increasingly self-facilitating. Sometimes a new “facilitator” role emerges to serve an entire department, stepping in to train facilitators or lead retrospectives when there is a problem or a gap, as is done at large corporations like HP and Siemens. There are members of the Agile software community, including Ainsley Nies, Diana Larsen and Esther Derby, with a wealth of experience who have done this and can help others to do it.
Why Wait Until Trouble Comes?
After studying many successful teams, Alistair Cockburn identified that - despite people’s weaknesses - there are three things we can always count on:
Even before trouble appears, let team members know that interpersonal communication skills are valued as highly as programming skills. Then quietly watch what goes on in the team room and listen to what comes out of retrospectives - remembering that it takes some teams longer to face the fluffy issues, so they not only need encouragement, but on-going support.
Watch out for team members who are sensitive to group dynamics or political issues. There may be one who senses what’s needed simply by “looking around,” and who responds as a good team citizen by taking the risk to raise people issues - and you may be surprised at who it is!
For example, a team member may express concern about how to make a team-room work well for everyone involved. Rather than researching and manage this herself, a manager could take this opportunity to offer this team member a resource he himself can use to contribute to the team’s transition. In this case, Cockburn’s book Agile Software Development presents theories on how to make team rooms work – and what to avoid. Here's a mentoring approach: get two copies of the book and meet a few times with the team member to discuss how the material applies to his situation.
Through guidance in the form of questions, mentoring, suggestions and resources a manager may offer help without infringing on the team’s growing confidence in self-management.
Where Are All These Resources?
It can be difficult to search for “soft skills for geeks” on the web. Which keywords can one use that are not present in millions of blogs on unrelated subjects? And which solutions are compatible with Agile methods? Books on management, communication and facilitation are starting to emerge from the Agile community: watch for news on sources like InfoQ.com/Agile, AgileJournal and agile mailing lists like ScrumDevelopment, ExtremeProgramming, LeanDevelopment, Agile Management and LeanAgileScrum. These lists are frequented by experienced practitioners, and so are also good places for novices to ask for directions to the right resources.
There's the annual Accelerating Your Effectiveness (AYE) conference, which aims specifically to help software practitioners and managers learn better people skills. It was inaugurated in 2000 by a small group of consultants, including Gerald “Jerry” Weinberg who has been providing valuable resources for managers and software developers for 25 years. (Weinberg has written numerous books, from "The Psychology of Computer Programming” in 1971, perhaps the first major book to address programming as an individual and team effort, to 1997’s“Quality Software Management, Volume 4: Anticipating Change,” aimed at software change artists).
The AYE Conference, hosted by a handful of software thought leaders, AYE is a collaboration of experienced practitioners who create a rich and varied 4-day soft-skills conference which some consider the highlight of their professional year. These skills are best learned interactively, but if you just can't send someone, the conference website is a good starting point for web research. The bulk of the conference content springs from presenter experience with self-organizing teams and groups, and their articles and presentations from past years are preserved on the conference site, including these, from 2007:
- Rewriting the Story of Resistance, by Dale Emery
- Peer-to-Peer Feedback, by Esther Derby
- Convincing Management that Context Switching is a Bad Idea, by Johanna Rothman
In addition, there are many practical sessions on communication and facilitation skills each year at the Agile Alliance’s Agile200x conference. Although the proceedings must be purchased, session proposals and abstracts are freely available, and these may help point you toward people thinking about topics that interest your team. This is just the beginning of your research: by discovering where these people blog and publish articles you are bound to come across yet more helpful writers and coaches.
The article library of the AgileAlliance is also a good place to look, there should be communication and facilitation skills articles sprinkled through these categories: Self-Organization, on Communication, and People.
Well, Maybe When We Have More Time…
We never have enough time. But time isn’t the only resource we can leverage to get more done! Schwartz and McCarthy remind us that what they call “personal energy” is a renewable resource:
By fostering deceptively simple rituals that help employees regularly replenish their energy, organizations build workers’ physical, emotional, and mental resilience. These rituals include taking brief breaks at specific intervals, expressing appreciation to others, reducing interruptions, and spending more time on activities people do best and enjoy most. Help your employees systematically rejuvenate their personal energy, and the benefits go straight to your bottom line.
They cite the example of Wachovia Bank, where participants in an “energy renewal” program produced 13% greater year-to-year revenues from loans than a control group did. And they exceeded the control group’s gains in revenues from deposits by 20%.
Scott Ambler, talking about Agile Single Sourcing reminds us that “in agile software development you want to travel as light as possible, and the easiest way to do that is to choose the best artifact to record information.”
When teams are made up of specialists who only know how to work with a small subset of artifacts you will often capture the same information in several places… When people are generalizing specialists who have one or more specialties plus a general understanding of the complete software lifecycle they can work with a wide range of artifacts, reducing the need to capture the same information in several places.In fact, this extends beyond artifacts: how much of your team’s current documentation could be eliminated by timely, effective discussion or by just conferring with the right person? Teams undaunted by people issues are likely to collaborate better, make decisions faster and reduce “wasted” documentation and communications.
So, if you’ve got a lot to do… can you afford not to improve the personal energy and communication effectiveness of your team members, now? If you really “don’t have time,” ask yourself whether you are managing a Death March project and need to recalibrate. (Alternatively, Jerry Weinberg has been heard to recommend the strategy of offering prayers to Saint Jude, patron saint of hopeless causes).
Easy Does It
Armed with these strategies and resources, it still rather important to allow the team, and individuals, to “pull” resources in as needed, to build their confidence, rather than management “pushing” them upon them! And so the last word on this goes to coach Dale Emery, master of metaphor :
… “you can lead a horse to water but you can’t make it drink” means “We smart change agents can tell people about our brilliant ideas, but we can’t make them adopt the ideas.”And this is offered as a lament, as if it’s frustrating that we brilliant change agents can’t make people adopt our brilliant ideas.
Here’s an idea: Try leading a thirsty horse to water and see what it does. If the horse is tired, lead it to shade and a soft place to lie down. If the horse is hungry, offer it hay and oats. If the horse doesn’t need anything, maybe leave it alone.
About the Author
Deborah Hartmann is a bilingual Agile practitioner, trainer and coach based in Toronto and working internationally. Deborah is passionate about making work both valuable to the business and enjoyable for the team. She's coached large and small businesses in Agile adoption, has been Lead Editor for InfoQ's Agile Community since April 2006, and facilitates various OpenSpace conferences for the XP and BarCamp communities in Canada and the US. With Naresh Jain, she is co-founder of AgileCoachCamp. In his article Don't Let Miscommunication Spiral Out Of Control, Joe Rainsberger has applied lessons learned at AYE to the challenges of interpersonal communication, and offers a couple of additional resources.
Related InfoQ content
Read more on Teamwork, Interpersonal Communication, Self-Organizing Teams and Leadership on InfoQ’s Agile Community.
Image Credit: The photo of "Matthew" (name changed to protect the innocent) is a still from last year's winning entry in the AgileAdverts competition, called "Developer Abuse".
