That’s Not My Job

A development team can have all the skills necessary to solve a problem, but not take advantage of them. Just like it’s possible to have whole development teams that are siloed by area of expertise, similar silos can exist within a development team, too. As a result, team members may refuse to reach outside the bounds of their competency to get an increment to done.

For example, let’s say there are two days left in a sprint. The dev team is done coding, but they still need to do a full regression test on a website to consider the work done. In the daily scrum, the tester comments that he doesn’t think he’ll have the time to finish and asks if anyone is willing to help. A software engineer responds, “I’m a Java developer—I shouldn’t have to execute test scripts. Can you develop in Java if I’m behind?”

This kind of comment is quite harsh but, unfortunately, isn’t uncommon, especially in companies that have switched from waterfall project management to Scrum. In waterfall, competencies are phases: When coding is done, the coding phase is marked as complete and coders move on to the next thing. Their accountability stops at writing code.

You can sometimes also trace the root cause of this type of mentality to the organization’s reporting structure. It’s common to have testers report to a test manager, engineers report to an engineering manager, designers report to a design manager, and so on. The bounds of accountability stop at the manager for that particular vertical. This can create an “us versus them” mentality, which may have existed in the organization for quite some time.

In Scrum, there’s only one title on a development team: developer. A developer on a Scrum team might write code, develop test cases, create user interface designs, write customer documentation, and so on. Regardless of an individual team member’s area of expertise, the whole team has a single accountability: to deliver an increment at the end of the sprint. If the design is complete but coders can’t finish their work by the end of the sprint, that’s the whole team’s problem to fix.

Is this anti-pattern happening on your team? If so, use your next retrospective to create shared accountability of the increment. Map out all the hands a product backlog item must touch before it’s considered done. Often this will result in a flow across the different competencies on the team (for example: to-do, analysis, design, development, testing, and done). After you’ve defined this flow, start asking questions:

• Is any part of this flow more accountable for the increment than any other?

• If a product backlog item gets stuck, is there anything anybody outside of that competency can do to help to move it forward?

• If a product backlog item doesn’t meet the definition of done by the end of the sprint, whose fault is it?

• If this team fails, are some roles more accountable for the failure than others?

• What can we do, starting next sprint, to collectively own the outcome of the sprint?

Creating whole-team ownership can be challenging. Try taking a coaching stance and asking questions that foster conversations between team members. The reality is that no one role within the team is the hero. A development team succeeds or fails together, and it’s up to us as Scrum masters to create awareness of that.