Sally was puzzled and concerned. The nature of her Scrum team’s daily standup had taken a step backwards these last several days. Because of the lack of meaningful response to her gentle prodding at the standups, Sally knew that as ScrumMaster, it was time to probe a little deeper. As she drove to work that morning, she resolved to talk to the three developers on the team one-on-one to see if they could shed any light on their recent behavior change.
The team was regressing from its highly collaborative state to a collection of individuals. The standups were no longer a coordination point where the team discussed their collective sprint commitment and their shared progress. Instead, the standup had devolved into a series of individual status updates. Sally noted just the day before that one developer who finished early simply took on another task instead of assisting someone else who was working on a higher-priority task – even when it was clearly evident that the other team member was struggling.
Worse, there was even some bickering between the developers about the various tasks. It seemed that suddenly, each developer had a strong preference to work solely in certain areas, to the exclusion of anything else and to the determinant of the team. And the effects and behaviors were beginning to trickle to the rest of the team.
Sally had tried to get the team to recognize the problem, talking to the developers using informal, open-ended inquires like, “How do you feel about the team’s standup this morning?”Sally was hopeful that she could guide them to reflect on their participation in context with Scrum practices.
Unfortunately, she received rather brief, “they’re fine” responses and shoulder-shrugs. While the QA staff had begun to voice some concerns of their own, those concerns were quickly dismissed by the developers. The new status quo was in danger of becoming good enough, odd for a team that had worked very hard the past year to understand Scrum and had seemed determined to excel as a team.
As soon as Sally reached the office, she walked directly to Mark’s desk. Mark was always in early, and she wanted to talk with him first, as the most senior developer on the team.
“Mark, do you have a moment?” Sally asked as she approached Mark’s desk.
“Sure,” Mark replied, turning away from his monitor and reaching for his coffee cup. “I need another cup of coffee, can we walk and talk?”
“Works for me!” Sally enthusiastically replied. She waited for Mark to get up and take a few steps away from his desk before continuing. Sally’s intent was to clearly state her observation and be direct as possible. She did not want any ambiguity or evasive answers.
“Mark,” she began, “I’ve noticed that during this sprint, you’re not interested in any task other than your own. Instead of collaborating, all that you’re doing is reporting your status. For example, you didn’t offer to help Allen with his task the other day, but chose instead to move onto another task. I’m sure that you have the knowledge and experience that would be valuable to Allen, but it seems that lately you and the other developers on the team don’t want to share any information or assist each other in any way. What’s really happening here?”
Mark’s eyebrows rose as he considered Sally’s questioning. Sally was a good mirror; he hadn’t considered how his behavior had altered in the past week or so, but he immediately recognized that Sally was right. And Mark was experienced enough to understand why.
He let out a deep breath and said, “Well, I’ve just had my annual performance review, and it’s a good bet the others did, too…”
After talking with Mark and the other two developers on the team, Sally determined that the management team, in an effort to “raise the productivity bar” – and conforming to the HR practices of the company – had worked hard at establishing SMART goals for the development staff.
Unfortunately, in an attempt to be as specific and measurable as possible, the line managers had established goals that involved each developer taking ownership of specific functionality along with the objective for each developer to personally and visibly drive results for improving that functionality. Aside from teamwork issues, sooner or later there would be debates about product priorities with the Product Owner!
This individual focus undermined the team-oriented nature of Agile/Scrum practices. It took a meeting with the VP of development to get agreement that the goals should be changed, and Sally pledged to work with the line managers to help craft goals that were team-oriented and fit within Scrum development. The VP also agreed to get more education for management on the Scrum process itself, so that they could understand how to change their management style and work with teams that ideally should become self-organizing and autonomous in nature.
While this post was a fictionalized account, I’m curious if any of those reading have experiences with performance management and goal-setting (good or bad) related to agile or team-based development that you would like to share. And does anyone have a great solution that they’ve implemented?