Scrum: What's in a Name?

Scrumpdillyishus or Scrumdidilyumptious?

While pondering potential titles for this blog post about my work experiences with software development methodologies over the years and my eventual usage of the Scrum process framework, I eventually recalled the Dairy Queen slogan, "Scrumpdillyishus", and thought that perhaps I might use it as a play on words.

However, en route to recovering the exact slogan that Dairy Queen used in the past, I ran across a number of websites which either claimed slightly differing slogans, or indicated that "Scrumpdillyishus" was actually the slogan for other products, such as the Willy Wonka chocolate bar which actually went by the name "Scrumdidilyumptious".

Fortunately, I discovered in the history section of the Dairy Queen "About Us" page that Scrumpdillyishus was a Dairy Queen registered trademark that dates to the 1970s. But regardless of whether this non-word was used as a corporate slogan or registered trademark (or both), the question that comes to mind is the following: "What's in a name?"

 

Scrumdillyishus

While everyone should likely know by now that "Scrum", a term from the sport rugby which "refers to a tight-packed formation of players with their heads down who attempt to gain possession of the ball", is a bit of a misnomer for the increasingly popular process framework, the name has stuck, and one of the questions that now surfaces is whether a team is really following Scrum if it uses the term to describe its approach.

Back in 2011, I went through my first round of Scrum training to get the first available certification for the process framework, available through the Scrum Alliance: "Certified ScrumMaster (CSM)". After a few years of experience with various incarnations of agile methodologies before and after this certification, I recently attended my second round of Scrum training to obtain "Professional Scrum Master I (PSM I)" from the scrum.org organization.

While there is a high degree of overlap between these two certifications, one of the key marketed differentiators between the two is that PSM training is consistent regardless of instructor (the others are that the PSM I certification does not require training, but does require the passing of a nontrivial exam).

 

Scrum

So according to scrum.org, what is "Scrum"? The training materials indicate that an answer of "yes" to the following 9 questions [emphasis added] indicates that Scrum is being followed:

• Is there a Scrum Team with a recognized Product Owner, a Development Team with 3 to 9 members and a Scrum Master?
• Is there an ordered Product Backlog?
• Is there a Sprint Backlog that shows remaining work in the Sprint?
• Is each Sprint 1 month or less in duration?
• Is a potentially releasable product Increment produced each Sprint?
• Does the Scrum Team create a plan for the Sprint in a Sprint Planning Meeting?
• Does the Development Team re-plan each day at a Daily Scrum?
• Is the Increment inspected by stakeholders at a Sprint Review?
• Does the Scrum Team conduct a Sprint Retrospective each Sprint?

 

Scrum?

As mentioned at the end of my prior blog post, the instructor called on me specifically during PSM training to answer these questions in relation to one of my recent projects, because I had commented earlier in the training that it was questionable whether the recent project of mine had adhered to some basic tenets of Scrum, leading to the question as to whether that project really used Scrum.

The answer was said to be "yes". However, I do want to point out that while the definition of "Scrum" might be delineated by these questions, this delineation is highly dependent on the definitions being used for the various terms comprising these questions (which were not taken into account during the question-and-answer exchange), listed here in order of appearance:

• Scrum Team
• Product Owner
• Development Team
• Scrum Master
• Product Backlog
• Sprint Backlog
• Sprint
• Increment
• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

 

A Process Framework

Do you see anything missing? Remember that Scrum is not a process, but a process framework. What this means is that there exists flexibility with regard to using specific agile practices not mentioned within the bounds of the relatively small Scrum Guide, such as Planning Poker or a Wall Board. Just remember that if your team wants to use Scrum, everyone should use terms in a consistent manner as presented in the Scrum Guide, because it can only hurt organizational communication if done otherwise.

Explanations of all of these terms are in the Scrum Guide. However, it does seem to make sense to discuss one of the basic building blocks of Scrum around which the first question listed above revolves, and can arguably be one of the most contentious, because it is one of the only terms not unique to Scrum: "Development Team". (The terms "Sprint" and "Increment" are also not unique to Scrum, but arguments typically involve more trivial subjects such as duration and whether software is actually deployed to production.)

 

The Development Team

An immediate answer to the question "Of what does a Development Team comprise?" will likely be provided with a resounding response of "Developers, of course!" But what is a developer? And what is a developer specific to Scrum? Part of the probable confusion with this term is that it seemingly points to a team of "developers". The wikipedia entry for "software engineer" briefly discusses the confusion around this debate:

Prior to the mid-1960s, software practitioners called themselves computer programmers or software developers, regardless of their actual jobs. Many people prefer to call themselves software developer and programmer, because most widely agree what these terms mean, while software engineer is still being debated.

The term programmer has often been used as a pejorative term to refer to those without the tools, skills, education, or ethics to write good quality software. In response, many practitioners called themselves software engineers to escape the stigma attached to the word programmer. In many companies, the titles programmer and software developer were changed to software engineer, for many categories of programmers.

These terms cause confusion, because some denied any differences (arguing that everyone does essentially the same thing with software) while others use the terms to create a difference (arguing the terms mean completely different jobs).

 

The Development Team and Scrum

Due partially to the introduction of Scrum, however, the statement above – that most widely agree what the terms "software developer" and "programmer" mean – is simply no longer accurate (and it can be argued that this statement was never accurate).

While PSM training only indicated that one should remember that business analysts (a.k.a. BAs) and quality assurance (a.k.a. QA) testers are a part of the Development Team, CSM training was a bit more explicit in mentioning that "programmer" is not equivalent to "developer":

The development team is comprised of the programmers, architects, business analysts, testers etc with whom we are familiar, and all of these individuals are "developers".

So let's take a step back and outline what this means. It is important that all stakeholders on your projects form a consensus on the basic building blocks of Scrum, with "Development Team" arguably being the most fundamental. If I was to white board the relationships between Product Owner, Scrum Master, and Development Team, it would look like the following:

 

The Product Owner is always one person and the Scrum Master is always one person. The Development Team, however, consists of one or more individuals. For this example, let's assume a team of 7 developers (a quantity just 1 above the midway point from 3 to 9):

 

Notice that no relationships are drawn between these developers, unlike the relationships in the previous drawing of the Scrum Team. One of these developers, for example, could be considered the architect who works alongside three programmers, a business analyst, and two quality assurance testers. However, none of these terms are technically Scrum terms. The Scrum Guide discusses this topic as follows:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Of course, some developers can serve more than one role, such as architect and developer. And remember that the concept of a "project manager" does not exist in Scrum. What about all of the other roles that can exist within a given organization? Perhaps there is a quality assurance manager or a development manager. How might these individuals fit in from a project perspective? Let's take a look:

 

Does this drawing look like the Development Team is self-organizing? What are the roles of the two managers in this scenario? Remember, all that is being discussed here is the team structure of the project itself. Long-term project-inspecific reporting relationships etc within the organization are out of scope with Scrum.

What is likely to happen here is that the Scrum Team will become undefined and that the individual Developers will be less apt to work with each other to determine what is best, and instead be directed by others not associated with the project. In some sense, this situation is similar to a Scrum Team incorrectly having two Product Owners. If the two Product Owners are at odds with Product Backlog entries, for example, upon whom should the Scrum Master rely with regard to priorities etc?

Sure, the concept of a "development team" is not unique to Scrum. The key takeaways here are that an answer of "yes" needs to be given in response to the 9 questions listed above, and the terms used for these questions need to follow the Scrum Guide. One aspect of Scrum that seems to get misinterpreted is the concept of a Development Team. While there are project stakeholders who work with the Product Owner, and likely other individuals within a given organization outside the Scrum Team, all of these individuals fall outside the definition of Scrum.

This post was written as part of my own retrospective to you about the past project of mine mentioned earlier in this post. During that project, an attempt was made to verbally convey this information, but the participants in the conversation did not see eye-to-eye until I started white boarding. It is my desire that this post might help you in your Scrum journey as you sort through what Scrum is really all about. Remember: "Agile" is not synonymous with Scrum, and unfortunately, "Scrum" is not always Scrum. If you want to adopt processes that deviate from the framework outlined by the Scrum Guide, that's fine – just don't call them "Scrum".