In Scrum is a Developer just a Coder?

A Developer on a Scrum Team. What does that actually mean? What do they do? Explore some common myths, and discover what’s expected from Developers on a Scrum Team.

Robert Pieper: Alright, a question we always get in class is, “What is a developer?” because it sounds kind of loaded. Like you’re a developer and you’re thinking coder, especially if you’ve been in tech for  any number of years. And basically, the way I think of it is, it’s anyone who develops value. They’re sort of a product developer, not so much a coder developer. But they make the stuff; they make the things that you’re selling; or they make the things that you’re giving to your customers. And that’s the way I think of it. I mean, Jason, what do you think?

Jason Malmstadt: Yeah, I would agree with that. I would also add that a developer, at least on a Scrum Team, is someone who is acting as a team player. So what you don’t want is each individual person taking their tasks, they don’t want to talk to anybody. They just want to do their own thing. You know, go off in their corner, work, work, work, and I’ll come back and throw it together at the end. And that doesn’t really work in a Scrum Team. A Scrum Team is full of developers who are team players who are collaborating together to achieve a single goal. How about you, Greg.

Gregory Crown: I think the team concept is brilliant. It needs to be, I think, definitely fleshed out if we can start to envision team players as having overlapping skills even in addition to just simply working as a team collaboratively. Some overlapping skills, ensuring that whatever is needed for the product can be done and can be built by the team as a whole. Having those skills available and present in your team is key. So those skills can be diverse. It’s not just coding, putting the Lego blocks together, if you will, somebody needs to understand the benefit of testing, perhaps, and maybe even be a really good documentation writer. Some of those things are all necessary as part of the developer skills. Robb, do you have anything else to add to that?

Robert Pieper: Yeah, yeah. I mean, you mentioned a bunch of different skills. And I think of a developer as also somebody who doesn’t think, “Oh, that’s not my job.” My job is software developer number three, and that’s clearly below my title.” No, a team player is somebody who jumps in, they say, How can I help? They’re always learning new things. Good teams are resilient, they’re robust. They can adapt. And if you can only do one job, well, what if you need a vacation? Or what if we need a different skill that week? So they take ownership in results and they focus on that and then they do what it takes to get it done.

Jason Malmstadt: Yeah, I think there’s this myth out there that you have to be a generalist, you know that what you’re saying is that you have to have lots of different skills and then people take that too far and think, “Oh, I have to be able to do everything.” It’s like no, no, we can honor your specialty. You can have a specialty skill set that you’re deepest in but we want to flex outside of that specialty to help the team achieve its goals. So if the best thing that the team needs from you right now is doing something that’s outside your specialty, roll up your sleeves and get some testing done or or try something new that you haven’t tried before. That’s what you need to do to be a team player on a Scrum Team.

Gregory Crown: Something that came to mind. You mentioned testing and I think that speaks of quality issues as well. Developers who don’t take accountability of quality, I feel like leaves the team wanting and leaves the product wanting. So a key aspect I think developers within teams need to keep in mind is, you own the quality, you’re accountable for that. Not just understanding what is needed, but making sure it happens that it’s built into the product. This has been kind of a fun round robin conversation. I love that we get asked these questions in class. They seem so simple on the surface, but then you start breaking them down and seeing that, wow, a developer is not just a coder.