What HR Doesn’t Know About Scrum
By Michael James

Scrum [1] is a framework for learning about products and the processes we use to build them. [2] Courageously applied, Scrum’s relentless “inspect-and-adapt” cycles leads to change beyond our software development practices.

Scrum has exposed the effects of outdated human resources management (HRM) practices at several organizations with which I’ve worked. [3] This article advocates modernizing these practices and their underlying beliefs.

Employees Treated as Rats in a Box
Typical HRM practices are rooted in popular misunderstandings of behavioral psychology. Attempts to motivate humans extrinsically are based on B.F. Skinner’s ability to elicit simple, conditioned responses from animals. For complex work, this punishment and reward game harms performance, even from rats. [4]

Organizations also have yet to fully discard the mindset of Frederick Taylor, a proponent of management practices that fail to harness intrinsic motivation and team ingenuity. Studies of human motivation reveal typical practices such as micromanagement [5,6] and performance appraisals [7] are counterproductive in the long run.

To make Scrum work, a business gives up these illusions of control in order to gain greater influence. Scrum development team members collaborate intensively to build products according to goals they repeatedly negotiate with the product owner, who is responsible for making the team’s business decisions. Results are demonstrated at the end of every fixed-length sprint (e.g., every two weeks). During sprint execution, team members develop intrinsic interest in shared goals and learn to manage each other to achieve them.

Team self-organization around business-driven goals will fall short when individuals also have goals of looking good for the boss or outscoring teammates in 360-degree peer review contests. HR professionals often are unaware the assumptions behind corporate behaviorism have been debunked by behavioral economists [8], psychologists, and other researchers, such as George Loewenstein, Alfie Kohn, W. Edwards Deming, and Dan Ariely. The long-term effects of performance appraisals and incentives undermine their intended aims: alignment, feedback, motivation, fair compensation, retention, morale, etc. HR should collaborate with Scrum teams to find other ways to achieve these aims.

Filling Scrum Roles
Each Scrum team is a cross-functional group of about seven people (aka the Scrum development team), plus a product owner, and a ScrumMaster. [9] The tips below may help HR provide advice on who is suitable for these roles initially.

A common pitfall is to assume a manager is the automatic choice for the ScrumMaster role. The effective Scrum-Master allows leadership to emerge naturally on the Scrum team and wields no authority over it. Even when the traditional habits of managers can be overcome,
their former subordinates typically continue to regard them as managers, rather than stepping up to team self-management. Next, everyone reverts to prior habits. Managers may be better suited for the product owner role. As product owners, they will get better results each sprint when someone else (i.e., a true ScrumMaster) helps interrupt the prior habits.

A Scrum development team requires a broad range of skills and habits in combining analysis, design, implementation, and test automation activities into a seamless flow, such as test-driven development. A collaborative team only initially requires one or two people with these skills. If Scrum is done properly, team members without these skills will be mentored in them.

Hiring
HR departments and hiring managers usually overemphasize credentials and skills, giving insufficient weight to the chemistry of the team. Rather than conducting a conventional job interview, let the candidate solve complex problems with the team for at least a day. Then, let the team make the hiring decision.

When tasked with assembling teams from scratch, I’ve ignored candidates’ résumés and collaborated with the candidates on simple programming assignments to get a feel for their personalities, skills, and habits. I once had to decide whether to include a candidate whose technical ability in this exercise was relatively low. The candidate was enjoyable to work with and eager to learn, so I included her on the team. As the project progressed, team members reported she was the social glue that helped the team succeed.

Reassignment and Firing
Experiments conducted by Will Felps demonstrate that one team member can destroy the effectiveness of an entire team by “withholding effort, expressing negative affect, or violating important interpersonal norms.” [10] In my experience, only about three percent of the workforce comprises slackers, downers, and jerks. Unfortunately, the bad apple’s disproportionate impact is exacerbated when teams cannot choose their own members.

An example: Andy has a tendency to mistreat Bob, modeling behavior that causes Charlie to mistreat Dan. Aaron habitually slacks off, demoralizing conscientious team members. In a misguided attempt to be “fair,” some HR departments make it difficult for teams to remove Andy and Aaron.

In another example, a team tolerated a negative team member for months. The team avoided notifying the hiring manager of the problem until after the bad apple had been let go for other reasons. The hiring manager reported feeling disappointed the team didn’t feel it was allowed to influence its own membership.

Scrum may reveal that your bad apples are not who you thought they were. Employees who appear negative under the restrictions of traditional management are often suppressed leaders who will excel when set free in the right Scrum team.

Effective Scrum requires long-lived, cross-functional teams. Enlightened HRM policy allows Scrum teams to select their own members within these constraints.

Job Titles and Forced Hierarchies
Job titles and hierarchies codified into HR policy aren’t ideal for Scrum team self-organization. Control should flow naturally from individual to individual as situations require. Titles suggest rank, hampering this fluid process. Complex work requires collaborative learning. Specialized titles such as “systems analyst” and “quality assurance specialist” imply limited responsibilities and skills. Ladders of job titles connecting types of
work to career progression discourage ambitious people from mastering the skills the team needs most. For example, our entire industry suffers a shortage of people with excellent skills in testing.

If life without forced hierarchy strikes you as wacky, consider the General Electric plant in Durham, NC. There, 170 employees (reporting to one plant manager) use self-managing teams to build the world’s largest jet engines. An example of a company without distinct
job titles is W. L. Gore & Associates. If you’ve flown on a Boeing 777 or worn a Gore-Tex jacket, you’ve already experienced the benefits of innovative HRM.

Beyond its relationship to the product owner, a Scrum team does not require management-imposed hierarchy or formal job titles. Consider dismantling explicit hierarchies and reducing job title distinctions.

HR as Part of the Solution
The practices this article criticizes are so pervasive that it’s difficult to appreciate their harm until one has experienced life without them. Without fundamental transformation, ordinary
organizations will get limited benefits from “doing Scrum.” To be an extraordinary organization, foster collaboration between HR and Scrum teams, making HR part of the solution.

This article originally appeared in the January/February 2010 issue of Better Software. To access it online, visit: http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_0110/#/0