Joy, Inc. is a curious title for a book about Agile team building. But that, in fact, is what Richard Sheridan's...
book is about. Subtitled How We Built a Workplace People Love, the book is an eye-opener on what it really means to develop software collaboratively. Some of Sheridan's ideas about Agile teamwork -- such as working in pairs and rearranging physical workspaces -- are not unfamiliar to software pros. Others ideas, such as developing empathy, creating joy and eliminating fear, feel more foreign. Sheridan, CEO of Menlo Innovations, a software consultancy in Ann Arbor, Mich., said that new, unfamiliar ways of working are exactly what software development demands. "You can't [continue to] use the old way of doing things. The projects are too complex; the stakes are too high; they require collaborative teams."
Here's what I took away from my recent conversation with Sheridan and from reading Joy, Inc., published in 2015.
Change the way you self-identify
Agile teams working today are made up of members with different skill sets, where individuals identify themselves according to their expertise. But Sheridan insists this approach hinders effective Agile team building. No more saying "I'm the database guy," or "I'm a Java developer." On his teams, developers are multilingual: "They do Java one week and Swift the next." The team collectively possesses a wide array of skills, and individual members help one another solve the problem at hand. This way of thinking is not new -- testers, for example, are accustomed to writing a little bit of code, and developers are adept at devising unit tests.
But Sheridan is taking the concept to a new level, as illustrated by an anecdote in Joy, Inc. He was attending an industry conference with a young developer who joined Menlo straight out of college. When attendees introduced themselves to her, they said things like I'm a Java developer, or I'm a .NET expert. "She thought it was strange that they defined themselves by a piece of technology. They asked what kind of programmer she was. I'm a software programmer, she replied. They pushed her further. What language did she use -- Java, C#, Ruby, .NET? She answered that she used whatever language worked best for the problem we were trying to solve," Sheridan wrote.
Not surprisingly, when Sheridan hires, he doesn't focus on technical skill sets. He is looking for people who demonstrate empathy for their fellow team members -- a quality he and others believe makes for successful Agile teamwork. "Do you play well with others? Do you make your partner look good?" He's not the first person to raise these sorts of questions. But his approach to finding meaningful answers is something I haven't heard before.
At Menlo, the hiring process works like this: He brings in 30 to 50 candidates at a time, pairs them off and sets them to work on a software development task. The goal of the 20-minute exercise is to get your partner -- not yourself -- invited back a second interview. "You can likely imagine the twisting of brains at this point, as candidates want to make sure they get the second interview," he wrote in Joy, Inc. He is looking for one thing: "I want to see them help a partner who is struggling," Sheridan said.
Build trust, create joy
Why is empathy important in Agile team building? Because it creates trust among members, and trust makes an intentionally joyful culture, Sheridan said. "You can't work without trust, and you can't build it [simply] by saying 'hey guys, I need you to trust each other.'" Trust makes team members feel safe, not fearful. When people are happy and safe "creativity, energy, imagination, innovation and invention emerge," Sheridan said.
Are you making your teammates look good? Is your Agile team creating joy? Let me know.
Can there be too much of a good thing when it comes to teamwork?
This is what happens when teamwork gets mobbed
Is it time to shake up the Agile manifesto?