“Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule”.
This is what the Scrum Guide says about the Development Team. I find this last bit about “no exceptions” quite amusing because I haven’t seen many rules written in a way where the authors have explicitly said “no exceptions allowed”. It’s as if they are saying “we know what you are thinking: we know you will endeavor to break this rule at some stage. Let us stop you before you realize you want to break the rule” 🙂
But this use of the word “developer” causes some confusion.
A recent conversation on our internal Readify Yammer became somewhat confused when somebody claimed that BAs and testers are often part of Development teams as well, and not just developers. That seemed to be a very innocuous statement at the time and I obviously didn’t disagree with that.
But when I thought a bit more about it, I came to realize that perhaps, we need to acknowledge the distinction between a developer and a Developer!
So everyone in the Development Team is a Developer. A BA is a Developer. A tester is a Developer. A developer is also a Developer. A Product Owner is not a Developer.
To me, it seems that the general usage of the term “developer” in the industry refers to a person who writes code. Software engineers, programmers, coders etc are some of the other terms often used. In fact, in job interviews in the past I have been asked if I knew the difference between a programmer and a developer, a software engineer and a developer, a coder and a software engineer etc. As soon as the conversation takes that path, I know I am not getting this job, and would have to keep looking. To this day, I don’t really care about these distinctions. You can call me whatever you want, as long as you let me write code to solve your business problem. It’s a bonus if the term you use to describe my job is respectful as well 🙂
But within the context of Scrum, everybody in the Development Team is a Developer. Everybody contributes to the creation of the releasable Increment of the product.
They may use their distinct skill-sets to do that. That’s ok.
Why is this important?
I recently came across an article which talked about some new Scrum meeting that isn’t described in the Scrum guide, but was purported to solve some specific problems many Scrum teams have. The meeting was supposed to be attended by BA, a developer, and QA. Note that the Product Owner isn’t invited to attend this new Scrum event the writers were proposing.
I do have many issues with the whole approach of that article, but here I only want to focus on the issue of terminology. When you are proposing something new that is going to be so fundamental to a methodology (a new Scrum event in this case), you should stay true to the terminology used in the original body of knowledge. You shouldn’t try to introduce new concepts, and you should try to stick to existing notions that have specific meanings within the framework. When talking about Scrum, it makes sense to say for example, that in a specific meeting Product Owner and Developers must be present. That’s ok because within the context of Scrum, I know what these roles are. I feel uncomfortable if you start distinguishing between team members by assigning them roles Scrum doesn’t care about.
“Business Analyst” is not a Scrum role. If you say that only BA, developer, or QA are supposed to do something, attend some specific Scrum event or do something specific to a particular Scrum artifact, I would humbly advise you that that statement didn’t mean much. Distinguishing between team members on these lines goes against the spirit of Scrum.
This may sound like a useless semantic argument, but I strongly feel that thinking of everybody as a Developer ensures maximum visibility for the whole team.