Developers and the Development Team

“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.

 

 

Scrum and Empiricism

“Scrum is founded on empirical process control theory, or empiricism.”

What?  Empiricism?

The first time I read this line in the Scrum Guide, I was quite impressed.  Being a pseudo-philosopher, I had a vague understanding of why empiricists and rationalists don’t generally like each other.  It’s an ongoing argument in the history of human thought.  To confuse the matters further, technically you can be a rationalist in one area (say mathematics) and an empiricist in another area of physical sciences.  But the dispute generally holds true.

The fact that Scrum takes inspiration from empiricism tells us something important about it.

The question underlying the philosophical debate is this:  How can we gain knowledge?  More specifically, we want to know what is the fundamental source of our knowledge.

How would you answer that question?

If you think your primary source of knowledge is your sense perception, then I congratulate you for being a child of a Scientific age that relies heavily on empiricism to learn about the world.  The Scientific Method, (if there really is such a thing) relies on sense perception.  I would argue that in modern societies the need for “evidence” to make any claims to knowledge is so pervasive that we can’t imagine any other possibility.  The rationalist positions would sound silly at first, unless we think very carefully about rationalists’ view of how knowledge is achieved.

An empiricist would believe that all our knowledge is derived from our sense.  We don’t have any innate knowledge.  Now this has worked well for Science in the last 500 years or so.  Scientists like reproducibility of their results.  In fact, recently there was a story published on BBC about a “reproducibility crisis” in the scientific world.

“Replication is supposed to be a hallmark of scientific integrity”, the above article tells us.

Rationalists, on the other hand hold that at least some of our knowledge is derived from reason alone.  There is a wide range of opinions among rationalists regarding the relative importance of reason for acquisition of knowledge.  Plato is probably one of the earliest philosophers showing rationalist tendencies.  His whole idea of eternal Forms and doctrine of knowledge by recollection have strong smells of rationalism as it was developed subsequently.  I guess what unites rationalists is their refusal to treat sense data as the only foundation for knowledge acquisition.

And that’s exactly the problem I have with empiricism: exclusivity.  Empiricists don’t leave any chance of any other source of knowledge.  What my specific problem is with empiricism is perhaps not important here, and I don’t really feel like defending my position.

But I do agree that Science totally relies on empiricism.  Being scientific about something means being an empiricist.

And that makes Scrum sort of a scientific enterprise.

And don’t get me wrong: it’s a good thing.  Scrum is all about inspecting and adapting.  As the Scrum guide tells us, each event in Scrum is a formal opportunity to inspect and adapt something.  If findings of a team are backed by evidence and observation, we have something tangible to talk about.

If, for example, we observe that not having an automated CI/CD setup adversely affects team performance, and if it is an observation that is shared among multiple team members, we can then do something about it.

Empiricism makes it possible to have a conversation.  It takes away opinions that can’t be substantiated with evidence.

I feel that is a huge contributor to the success of Scrum as a framework.

 

 

It’s not just the Bell Curve

The Bell Curve is our friend.  In a recent post, I argued that in Scrum teams the story point estimates work very well because we will inevitably overestimate effort required for certain stories and underestimate effort for others.  The net effect is that the overestimates will cancel out the underestimates in the long run.

But, there is something else that goes on in a Scrum team, that makes our estimates more accurate.

A Scrum team inspects and adapts.  One way that happens is that as the team goes through sprint planning sessions over many Sprints, a shared understanding of “What a story point means” starts to emerge.  The team develops an intuitive sense of what a typical 1 story pointer looks like; what a typical 2 story pointer looks like, etc.   The team members may or may not be able to articulate it precisely, but it’s there.

This sense of worth of a story point is unique to a group.  To me that’s exactly the reason why we should never compare the velocities of two Scrum teams.

But the fact that there is a shared understanding among the group members means that the estimates by different team members start to converge over several Sprint planning sessions.  As the project progresses, the instances of “this-is-a-3-pointer-not-a-13-pointer” sort of conversation become rare.  The team just knows what a 3 pointer means.

The variance of estimates goes down.  You notice similar estimates from different team members, which probably indicates that estimates get better over time.

And that’s another reason why story points work so well in Scrum.

P.S.  Special thanks to my good friend Ahmadreza Atighechi (http://ahmadreza.com/) for the thought provoking conversations that inspired this post.