Scrum By Example – New People on the Team

After six months ScrumMaster Steve has finally found someone to fill the role of Senior Software Developer on the team. The goal is to find a person who can round out the team and play many roles (see: Bottlenecks). After many interviews, they’ve settled on Kirby^[1] who has over 20 years’ experience developing software, both server-side and GUI. He is a self-proclaimed expert in most of the technologies the team uses, and that’s where the problems start. In addition, the team members assume that he is being very well paid, perhaps better than any of the rest of them.

Attempting to learn the basics of the code base in his first few Sprints, Kirby takes on GUI, Middle tier, Server and Testing Tasks. He asks his teammates for code reviews and the code is pretty good, however it becomes clear that he can be touchy on some subjects and isn’t eager to receive negative feedback. On the subject of feedback he says, “I’m a Senior Developer, I don’t need to learn from you, it should be the other way round.” At first the team just try to accommodate his needs, but after five to six weeks, tensions begin to rise. Ian (the Middle Tier guy) feels threatened; he sees Kirby trying to occupy the niche he has occupied on the team. To compensate, Ian spends more time doing server side work, which in turn causes Doug some concern. Even Tonia feels a little bit threatened as Kirby starts doing some automation work.

Seven weeks into Kirby’s tenure, during a daily stand-up (Daily Scrum), he is describing his work to display book prices in the local currency when Ian (usually a calm individual) blurts out, “He’s stealing my work”. Steve swings into action saying, “Ian, thanks, this seems important, could we discuss after Standup and let Kirby finish?” Ian agrees sheepishly. Steve turns back to the team and just says, “Why don’t we pick up again with Kirby.” After standup, Steve grabs Ian and says, “Let’s go out for coffee.” Over coffee they chat, and Steve hears Ian’s view on the situation:

• Kirby isn’t open to suggestions or comments about his code
• Kirby is pushing him out the work that he does regularly
• Kirby often denigrates the quality of the existing code
• Kirby makes it clear that the other developers should be learning from him

After coffee with Ian, Steve goes for a walk with Kirby to hear his point of view:

• Kirby sees that the code doesn’t have the quality (see Technical Debt) he would expect of it
• Kirby is aware that he’s sometimes seen as pushy and isn’t sure how to solve that problem
• Kirby understands how Ian feels push aside but isn’t sure that this is his problem to help solve

Steve spends the rest of the day buying coffee and tea for the rest of team, talking to one person at a time. While they don’t feel as much pain as Ian, they feel some of it.

The question is what to do now?

Analysis

First and foremost, Steve can’t take sides here. He can look to find the positives he sees going on, but can’t champion anyone’s viewpoint. As soon as he starts to do that, he will erode his credibility as a neutral ScrumMaster. The best he can do is get the various players talking and see if they can resolve the problem. To see some of the problems here, read Brian Buzzoto’s “Watch for Triangles”.

My viewpoint as Editor: Many of the things Kirby is doing – working across the code base, doing testing work, writing unit tests, generally raising the code quality – are good for the team. The problem is that in doing this, he comes across as a know-it-all.

The key here is remember Tuckman’s Model of Team Formation (Forming, Storming, Norming, Performing). When even a single team member changes, the team reverts to Forming, and after seven weeks they’ve rediscovered Storming. The Storming part of process can’t be avoided, skillful ScrumMastering aka interference, in fact interference makes it last longer.

Story

The next day Steve gets Kirby and Ian to sit down and talk. He sets out ground rules: talk about your feelings, talk about events, use “I” statements not “You” statements. He suggests the goal isn’t to solve any problems today, just understand how the other feels. Even if they still disagree, they need to understand the other person’s viewpoint. In future, Ian suggests that checkin every day with how their working relationship is with the other person.

… The story could/should continue for weeks. At this stage let’s assume that they’ve at least started to understand each other. Maybe we will see hints of this story in future posts.

Analysis

It’s striking that this problem occurred in part because the team weren’t involved in the interview process. Hiring well is a very difficult problem, it’s even harder when the people who will spend the most time with the new hire haven’t met them before. I find it very effective to involve team members in the interview process.^[2] I would even get the potential hire to pair program with the rest of the team as part of the interview. There is nothing like a few hours of coding (spread across the entire team) to get a sense of what working with them will be like.

See Also: Onboard New People Without Losing Scrum Team Magic

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.