I am a Java Programmer. I am a User Experience Designer. I am a Quality Assurance Analyst. I am a Business Systems Analyst. I am a Technical Writer. I am a Data Analyst. I am Project Manager. Moreover, I am a Senior level Project Manager, et al.
Image source: Jeff – smartsignin.com
Wait just a minute… I worked hard to become what I am. I went to school, spent many long grueling hours, years even, perfecting my craft. I have certifications. When someone asks me what I do, I’m proud to tell them I’m a Java Programmer. This is my identity. Now you’re telling me I have the same title as everyone else on the team? Hogwash. I’m better and smarter than the others. I’m a rock star at this company. I make more money, and am more senior. I don’t like this idea of calling everyone a ‘developer’. But I’ll humor you because I know my boss supports Scrum. What I won’t tell you is that this has put a bad taste in my mouth. Scrum…
Identity is a person’s conception or expression of their individuality or group affiliations. And if I’m where I want to be professionally, my title is reflective of that.
Frank: Jim, what do you do for a living?
Jim: I’m a Java Programmer for IBM.
This is a pretty typical answer, wouldn’t you say? Jim identifies with his own personal identity first (Java Programmer), then the group (IBM). I get asked this same question a lot. Depending on who asks me, I may answer differently, but I do the same thing. Even though they only asked what I do, I deliver those goods and then some. I also tell them who I work for. I’m a unique individual, but I’m also a member of a larger team.
This ‘developer’ classification takes a bit of getting used to for folks new to Scrum, so let’s take a simple analogy… Think of your teachers in High School. You likely had at least an Algebra teacher, English teacher, Art teacher, P.E teacher, and Biology teacher. Regardless of their specialties, they were all ‘teachers’.
In this same way, a ‘developer’ on a Scrum team may specialize in data analysis, design, testing, technical writing, and yes, even programming.
So why does Scrum do this? Can’t we just let folks keep their old titles. They’re descriptive, everyone is used to them, and they’re a source of pride in many cases. Why upset the apple cart? In short, to drive cross functional, self-organizing teams, and create an ‘All for one and one for all’ atmosphere. When someone needs help with a task that isn’t part of my Personnel defined job title, it shouldn’t matter. If I can help them, I will. And if I can’t, I’ll learn, because there may be a next time. This may sound trite, but at the end of the day, we’re all in the same boat. We will succeed or fail as a team. Not as a bunch of individuals.
We usually do let folks keep their official, non-Agile titles, however. Personnel departments still use them as a way to distinguish pay levels and seniority. They normally have each title documented with a long list of requirements, responsibilities and salary scales. But guess what? We can do the same thing with the three roles in Agile (Product Owner, Scrum Master, and Developer).
Now I must come clean; occasionally I use the more specific ‘specialist’ title for folks, like programmer, architect, DBA, QA, etc. for referring to developers for the sake of precision, but if I don’t catch myself, the developers on the team usually do for me. Sometimes I’m not sure if it’s genuine, or a smartass thing. Regardless, they do understand that while we recognize our differences, we’re all members of the same team. And we’re all ‘developers’.
What is your experience with Scrum teams and the ‘developer’ moniker?