Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (2014)

Chapter 2. Attitudes and Abilities

If you look at a typical classifieds list, it’s evident that, when defining job roles, many organizations seem to place an overly significant emphasis on surface-level roles and responsibilities. For Scrum to succeed, it is imperative to take a different approach, delving deeper into the inherent and fundamental attitudes and abilities that are required of a Scrum team member.

The following three shortcuts will help you dig below the surface of these new roles to really appreciate what is required for a team member to excel.

Shortcut 4: Masterful ScrumMaster identifies seven key abilities that great ScrumMasters should possess. Shortcut 5: Rock Stars or Studio Musicians? focuses on a selection of attitudes that we should require of our team members. Finally, Shortcut 6: Picking Your Team Line-Up offers guidance on how best to assemble an effective working Scrum team.

Shortcut 4: Masterful ScrumMaster

I don’t believe that the important ScrumMaster title should be bestowed on someone just because he or she knows the Scrum rules and practices back to front. Instead, this title should be granted only to those who genuinely understand and can bring to life the underlying ethos of the role. That is, a ScrumMaster should truly understand what it means to be a servant-leader. Robert Greenleaf, founder of the modern-day servant-leadership movement, describes this seemingly contradictory role:

It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions. (Greenleaf 2008)

So, what does servant-leadership entail in the context of Scrum? Well, let’s look at some of the attitudes and abilities that should come naturally to a real-deal ScrumMaster.

Leading without Authority

The ability to lead without being bestowed butt-kicking privileges is the ultimate challenge for a new ScrumMaster. It is often hard to join a group, harder to lead a group, and hardest of all to lead a group without explicit authority (see Figure 2.1).

Figure 2.1. Leading without authority requires a genuine servant-leader.

Ruling with extreme authority may seem easy on the surface, but any toppled dictator would agree that it is not a sustainable long-term option. Although a dictator may force results for a period of time, without the respect of his or her followers, it is only a matter of time before the so-called leadership crumbles and chaos reigns, irrespective of the force used to maintain control. A truly respected leader requires no authority and certainly no force. People want to follow this person and are inspired by this more subtle brand of leadership.

I believe that this ability is innate, though perhaps hard to develop. For those who are not quite there but are willing to try, here is a shortlist of starting points:

Drop the ego.

Genuinely care about both the team and the product.

Act fairly and consistently toward all team members.

Exude confidence yet humbleness at the same time.

Make yourself extremely approachable at all times (bathroom breaks are an exception!).

Bring about Change without Fear

As Woodrow Wilson, the twenty-eighth president of the United States, put it, “If you want to make enemies, try to change something” (Wilson 1916). Change is scary to most people; it takes them out of their comfort zones into a strange new world where their status and expertise are potentially under threat. The problem for the enthusiastic new ScrumMaster is that introducing Scrum will transform a project team’s world. Even constructive change, when not handled carefully, can be viewed negatively by team members.

When joining a new Scrum team, you should not rush in and change everything at once. Be patient; observe the environment, the current practices, the individuals, the team, the technologies, and the broader organizational landscape. Be a fly on every wall, and talk to as many people as possible. Even if your mandate is to jump in and totally “scrummify” the place, first gauge the readiness of those who need to be involved. You get only one chance to make a first impression, so if you strike before the optimal time, enacting change becomes that much harder.

Find and foster allies as soon as possible. Those who have an early adopting mindset and are excited about positive change will prove invaluable in assisting you to embed new practices.

When you’re ready, start slowly, and first implement one or two initiatives (perhaps introduce the daily scrum and a consolidated product backlog). Achieve a couple of small yet decisive victories, communicate the proven benefits, and build from there. Once you have established your credibility, the environment will be much more conducive to rapidly rolling out the rest of your initiatives.

Be Diplomatic without Being Political

The ScrumMaster is the hub connecting the spokes. These spokes are the previously disconnected departments that need to be brought together in perfect harmony to function as an effective Scrum team. More often than not, there will be a deeply entrenched silo mentality in place, separating the engineering team from the marketing team (see Figure 2.2). Worse than this is the sad fact that these silos are often more akin to fortresses, with barricades to keep the other “tribe” out. Breaking down this us-and-them mentality requires delicate diplomatic skills. It is about promoting broader team benefit and a healthy respect for all roles required to get the job done. The ScrumMaster should never take sides or get caught up in company politics—this is about productivity and maintaining a healthy working environment—and as we all know, politicking is mutually exclusive to both of those goals. As Rubin writes:

Figure 2.2. A great ScrumMaster will bridge the gap between departmental silos.

The ScrumMaster is transparent in all forms of communication. When working with team members there is no room for hidden agendas; what you see and hear from the ScrumMaster must be what you get. (Rubin 2012)

Behave Selflessly without Downplaying the Role

I remember watching the Tour de France (the annual, grueling 2,500-mile cycling race) and being amazed by the sprint finish of a particularly energy-sapping stage. After the speed picked up considerably, there was an almighty mess of bikes battling toward the line. With only a few miles to go, two riders from the same team broke out of the melee, one riding in relative safety on the back wheel of the first rider, who was forced to negotiate his way through the daunting impediments all around him. After doing all the hard work, the first rider slowed down and fell back into the rest of the peloton, having spent every ounce of his energy, leaving his teammate clear of the pack to take victory. This seemingly selfless role in a cycling team is performed by the lead-out man, whose duty is to use every last vestige of his endurance and tactical thinking to protect his teammate and guide him to victory without taking individual glory. A ScrumMaster needs to perform like a lead-out man; team recognition needs to be placed above his or her own. However, just because one is selfless, it doesn’t mean that their pivotal role should be downplayed. Although the lead-out man (or woman) won’t be standing high on the podium, the role he or she plays is recognized as absolutely vital to the team’s success.

Protect without Being Overprotective

The metaphorical comparison that is commonly used when describing the role of the ScrumMaster is that of the sheepdog, guiding the flock through treacherous terrain and protecting them from hungry wolves. I like this comparison, but I also warn about taking this part of the function too far. A good ScrumMaster is careful about overassisting a team in the same way that a mom or dad (with all the very best of intentions) needs to be careful not to become a “helicopter parent”—constantly hovering and not giving the child a chance to solve his or her own problems.

The ScrumMaster needs to implicitly know when to jump in to aid the team and must also realize when it is okay just to sit back and let the team try to resolve their problems so that they can grow both personally and professionally.

Maintain Technical Knowledge without Being an Expert

Although technical experts can make great ScrumMasters, I often find that there are two big issues when the ScrumMaster is either a technical or domain expert:

When a team member is stuck, it can be awfully tempting to jump in too early to help him or her resolve the problem.

The desire will be strong to get overly involved in the technical/functional details within the sprint planning sessions (see Shortcut 8). In these situations, the ScrumMaster can potentially become distracted from the core facilitation responsibilities.

Be Comfortable Never Finishing

A ScrumMaster may reach a glorious day when he or she looks at the team and is tempted to say, “Wow, we totally rock! There really isn’t anything more I can do to improve things here.” No matter how well things are humming along, remember that achieving perfection is an impossible ambition, and improvements can always be made. Furthermore, a team will change over time, through natural attrition, promotion, and in some (unfortunate) cases expulsion, so when these dynamics change, there will be plenty of work to do and improvements to be made.

Next Generation Leadership

Genuine ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions—it is important to look deeper below the surface to find the foundational roots and understand what they are about.

Finally, I implore organizations to remain open-minded when trying to identify future ScrumMasters because they may originate from any background. They are people who can successfully demonstrate the abilities discussed in this shortcut, and although not everyone can be a ScrumMaster, a ScrumMaster can be anyone.

Shortcut 5: Rock Stars or Studio Musicians?

When no one is looking, I would really like to sneak one extra line into the Agile Manifesto:

We Prefer Attitude over Aptitude

That is, although there is value in aptitude, we value a great attitude more.

Don’t get me wrong: aptitude is certainly important, but if I had to choose between a proficient developer with a super attitude and a genius developer with a surly attitude, I would choose the former over the latter.

Rock Stars

There is a movement in IT recruiting circles to try to locate “rock-star” developers. I’ve always had an issue with this juxtaposition because it sends a confused message to the market. Let’s think about this for a minute: What are the qualities that are synonymous with rock stars? I’m sure you’ll agree that rock stars are typically perceived as charismatic, creative, and individualistic—good traits, right? Flipping the coin now, let’s look at some of the less laudable, stereotypical characteristics—think temperamental, attention-seeking, and arrogant, with a healthy dose of my-way-or-the-highway attitude thrown in. Does this sound like the type of person who would play nicely in a tight Scrum team? I think not.

Studio Musicians

Now, let’s look at studio musicians. These musicians are happy to live out of the limelight and instead support the lead singer in producing a great album. As long-time music industry veteran Bobby Owsinski writes in The Studio Musician’s Handbook (2009):

Studio musicians are expected to be creative, be extremely versatile, and have a formidable skill set. . . . The fact that you are working very closely with other players, engineers, producers, artists, label and agency people (and who knows who else) usually means that the easier you are to work with, the more likely you’ll get asked back.

There’s a way to do things in the studio, and it differs from playing live. A studio musician’s protocol exists, and you’ll be expected to abide by it. Suffice it to say that if you like being the center of attention, then studio work may not be for you.

My conclusion: I’d much rather have a team of studio musicians than a team of rock stars.

Scrum Values

How should you go about selecting a team of studio musicians to ensure that your scrum doesn’t collapse under the weight of immense ego and constant bickering? The best place to start is with Scrum’s core values, which should be embraced by all team members, forming the basis of their professional personality. These values are shown in Figure 2.3.

Figure 2.3. Scrum’s core values should be embraced by all team members.

In addition to these values, I am always seeking the following attitudinal attributes in my Scrum team members: energy, empathy, curiosity, and friendliness. Let’s explore what I mean in more detail.

Energy

I’ve worked with some really smart developers who were easygoing and friendly enough. Sounds like our type of candidate, right? Well, these same developers had special powers akin to those of the soul-sucking Dementors from Harry Potter.¹ Using their zombie-like interactions, these developers were somehow able to sap all positive energy from a room, especially during the daily scrums, where the aim is to set an energetic tone for the entire day. So, if any low-energy team members are dragging the rest of the group down, see if there is anything bothering them that you can help with.

1. To learn more about Dementors, go to http://harrypotter.wikia.com/wiki/Dementor.

Empathy

Working in a close team requires patience and understanding. Each team member is reliant on others to help achieve the collective goals, and the reality is that we are all prone to having off days. A flat tire, a late babysitter, difficult personal circumstances, or simply feeling unwell—any number of things can throw us off stride. When these situations inevitably arise, teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield.

Curiosity

Development teams are cross-functional. As you’ll read in Shortcut 6, these teams are ideally made up of members possessing “T-shaped” skills who have the ability to work adequately outside of their specialty when the need arises to help avoid bottlenecks. This requires team members to be willing and eager to extend their skill sets, taking every opportunity to learn more about the functions that they are not necessarily expert at.

Friendliness

I remember working with a somewhat antisocial yet highly intelligent developer who I felt needed a talking to after a particularly critical attack on a new product owner. Our conversation went something like this:

Me: “Irrespective of what you thought of his ideas, there are ways and means of communicating without resorting to verbal nuclear bombardment.”

Him: “Well, I’m not being paid to make friends—I’m here to do a job.”

Me: “Well, yes and no, pal. You’re correct in that you are here to do a job; however, you are also being paid to work in a highly collaborative team environment. The more friendly you are, the more effective you will be.”

Him: (Silence)

When selecting a team member, I’m not just looking for someone who is polite; I try to identify someone who is genuinely friendly. It is much easier to rally to a friend’s aid than to a stranger’s (or even worse, someone you dislike), and it goes without saying that working with friends is much more fun (and that can only be a good thing). As Jurgen Appelo, author of Management 3.0 (2011), writes, “It doesn’t mean you have to be close friends with everyone. That’s not even possible. But simply knowing a little more about their life, their families, their home, and their hobbies (and them knowing some more about yours) would be a great start.”

Respect

Respect is one of the core Scrum values mentioned earlier. I feel it is important to explain my interpretation of respect in more detail, because unlike the other Scrum values, its application can sometimes be ambiguous.

Let’s face it: people (even very smart ones) occasionally come up with some less-than-stellar ideas. Perhaps they misinterpreted some fundamental input, or maybe they just got excited and blurted out what was on their mind without filtering it first. Unfortunately, I’ve worked in several environments where a brainstorming session ended up feeling like a cagey Olympic judo match, the participants cautiously waiting for each other to slip up so that they could throw their “opponent” across the room with a heavy dose of criticism.

Hostility is the last thing you want in a creative zone. Instead, a constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion. As Dale Carnegie (1981) writes, “Show respect for the other person’s opinions. Never say, ‘you’re wrong.’” When people hear “you’re wrong” too many times, their ideas (including the good ones) are likely to dry up pretty quickly (see Figure 2.4). There are far better ways of disagreeing without being disrespectful.

Figure 2.4. The effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Time to Make Music

I believe that Scrum’s success is premised on the fact that you have a team with the same positive, collective attitude. A group of brilliant yet egotistical individuals will never work as well as a group of solid yet collaborative teammates.

Remember that Scrum is about the team, not the individuals. That doesn’t mean individuals aren’t recognized as unique and integral; however, it does mean that their personal goals should be superseded by those of the team. Owsinski (2009) writes

Everyone is there to play their part as perfectly as possible. When the red light is off, the personalities are as diverse as you would see anywhere, but when it’s time to make music, everyone’s focus is 100% locked on the music.

Give me studio musicians over rock stars any day of the week, thank you very much!

Shortcut 6: Picking Your Team Line-Up

Sporting coaches deliberate for many months in anticipation of the annual draft pick, carefully considering whom they will target for potential inclusion on their teams. You’re not always going to have the luxury of choice, however—just as when picking the line-up for a sports team, significant care must be taken when bringing your Scrum teams together. This is particularly pertinent if you are running a pilot project where the future of Scrum at your organization rests in the hands of a select few.

You must consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics, to name just a few. Most important is the selection of a team that is more than comfortable saying goodbye to their previous hierarchical team structures as well as the all too common us-and-them view of the world.

Everyone Is a Developer!

A successful, self-organizing Scrum team has no place for divisive, clannish structures that create functional silos within teams. Silos are often formed either on functional grounds (such as programmers versus testers) or on hierarchical grounds (such as technical leads versus non-leads).

Scrum combats this problem very simply: it views all development team members as equals and labels them accordingly with the collective title “developer.” Whether you are a programmer, tester, user-experience designer, or technical writer, Scrum regards you as a developer. On a philosophical level, I really like this approach—it levels the playing field and reflects the fact that, to develop software, all functions need to participate (it isn’t the sole domain of the programmer who previously monopolized the developer title).

In practice, this new vernacular can be a bit of a tough transition, so I like to frame it slightly differently. I explain to the team that it is like being a medical specialist; irrespective of specialty, all specialists are still doctors. In the same way that a doctor might specialize in neurology or pediatrics, a developer might specialize in programming or testing. I typically use the more specific “specialist” title (programmer, tester, etc.) when referring to developers for the sake of clarity, even though I certainly advocate the theoretical underpinnings of the broader developer title.

Scrum Team Size

I’ll keep this next section short and sweet because there really isn’t any contention in the community on this particular topic. As Mike Cohn confirms in his most recent book, Succeeding with Agile (2009), “The generally accepted advice is that the ideal Scrum team size is five to nine individuals.” I’ll simply add that my preference is for the lower side—typically five to seven.

Development Team Ratios

When it comes to determining the makeup of the development team, there is certainly no one-size-fits-all rule because every project and team is different. However, if you have no idea where to start, to get you going, I suggest a ratio that I have worked with successfully on multiple occasions (although I highly recommend that you inspect and adapt accordingly):

3 programmers : 1 tester : 0.5 “deep specialist(s)”

A few things to note:

You may have multiple deep specialists working on a single Scrum team. By deep specialists I mean those who focus purely on niche areas, such as database administrators, user-experience designers, and subject-matter experts.

0.5 doesn’t mean that I like working with pygmy specialists—it means that these developers split their time across two projects. We discuss this contentious suggestion a little more later in the shortcut.

This ratio assumes a high level of test-automation maturity, leaving the tester to focus on the functions detailed in Shortcut 18.

With this ratio, I make mention of deep specialists. Although there is no problem including deep specialists in your Scrum teams, it is important to remember that Scrum is about finishing what is started as early as possible. To accomplish this type of flow, the concept of “swarming” is very important. Swarming means that rather than multiple developers working on several product backlog items (PBIs) at the same time, it is preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs. When deep specialists create a bottleneck because they are unavailable at critical junctures in a PBI’s progress, the team faces a problem. To get the best of both worlds, I recommend encouraging developers to develop T-shaped skills (see Figure 2.5). As Kenneth Rubin (2012) explains, a developer who has T-shaped skills possesses deep vertical skills in a specialized area (such as user-experience design) as well as broad, but not necessarily deep, skills in other relevant areas (such as testing and technical writing). Team members with T-shaped skills better enable swarming behavior.

Figure 2.5. Encourage developers to have a deep specialty and multiple competencies.

Cohn (2009) recommends an approach that I’ve adopted to help nudge teams in the right direction:

In your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally.

With receptive team members, the level of knowledge transfer will be very rapid, and although it might feel that the first couple of sprints are slow going, you will start seeing returns on this investment very soon after.

Fractional Assignment

In the previous section, I mentioned a 50 percent allocation for deep specialists. This “fractional assignment” is not overly popular across the Scrum community, and for good reason. James Shore and Shane Warden, authors of The Art of Agile Development (2007), put this down to the fact that

fractional workers don’t bond with their teams, they often aren’t around to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty.

I totally agree that ideally you want all team members dedicated 100 percent to the team. That being said, I have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team. That doesn’t mean I disagree with Shore and Warden, nor does it mean there aren’t occasions when you certainly need full-time deep specialists; however, it does mean that we often have to make the most of the skills available, and in many situations, we don’t have the luxury of full-time deep specialists.

As a sort of consolation prize to the purists reading this book, I point out that although I am not against splitting developers across two projects, I am adamant that no one should ever be split across three or more projects—that level of context switching becomes very counterproductive.

Another option that you might like to consider, especially if a deep-specialist is required to work on more than two projects at the same time, is to treat them as consultants and trainers for the rest of the team. So, instead of including them as part of the actual Scrum team, they are shared across multiple teams and assist on specific tasks while at the same time educating the other developers.

Can a ScrumMaster Work with Multiple Teams?

I hear this debate waged incessantly throughout the Scrum forums and user groups. Before offering my viewpoint, I will share some statistics presented at the global Scrum Gathering (the primary international Scrum conference) by Scrum trainer Paul Goddard (2011):

Seventy-five percent of ScrumMasters dedicate less than half of their time to being a ScrumMaster for their current team.

Forty-five percent of ScrumMasters support two or more different Scrum teams.

Eighty-eight percent of ScrumMasters take on additional responsibilities beyond that of a ScrumMaster.

Many in the Scrum community will strongly argue that the ScrumMaster role is significant enough to justify a “one team = one ScrumMaster” configuration. I support this argument, and Shortcut 26 highlights plenty of conclusive reasons demonstrating why being a ScrumMaster is absolutely a full-time role. That being said, it helps to remain open minded. I, for one, have acted as ScrumMaster on up to three teams at the same time, which, perhaps not ideal, can still work effectively assuming that the teams in question are well on their way to a mature state of self-organization. Let’s explore this juggling act a little further.

First, brand-new Scrum teams require one full-time ScrumMaster—no question about it. These fresh teams require significant levels of education, guidance, assistance, and most of all, constant inspection and adaptation. Taking on more than one brand-new Scrum team is not at all realistic.

Maturing teams that are settling into Scrum successfully, without systemic impediments (such as ugly politics or similar issues), and who are trending positively on the continuous improvement scale can potentially manage with a ScrumMaster working across two different Scrum teams.

Finally, elite, mature Scrum teams that are truly self-organizing, where improvements are more about fine-tuning, can arguably get by with a ScrumMaster working across three similar Scrum teams (see Figure 2.6).

Figure 2.6. Just how many teams a single ScrumMaster can handle depends on the maturity of the teams.

Attitude over Aptitude

Attitude is so important that I dedicated an entire shortcut to it, so instead of stealing my own thunder, I recommend that you read Shortcut 5.

Embrace Heterogeneity (But Beware)

Having had the opportunity to extensively travel and live on multiple continents, I can understand and appreciate the benefits that heterogeneity offers, and this is particularly evident when working in software teams. As software development is ostensibly a globally standardized industry, many of us have worked in environments that resemble the United Nations General Assembly.

Teams that consist of members from various cultural backgrounds, ages, experiences, and specialties are often far more interesting and end up forming environments that are breeding grounds for synthesizing novel solutions to problems.

But beware! In a few of the teams I’ve worked with, I had to sensitively break up some cultural cliques that had formed on the basis of geographical origin. The formation of cliques led to situations in which various languages (verbal, not programming) were being spoken in the open working area. Although it’s human nature to gravitate toward people with whom you have much in common, I am very much against cultural cliques in a Scrum team setting. It causes feelings of exclusion, not to mention the potential lost knowledge-sharing due to others not comprehending the various questions being asked.

In addition, I have found that with diverse groups, team members need to be careful about sharing insensitive jokes and idle banter that might cause unintentional offense.

Household Rules

Lyssa Adkins, author of Coaching Agile Teams (2010), recommends forming what she calls “rules for living together” for handling scenarios similar to those just detailed.

For example, on one of the teams that I worked with, we had a set of “household rules” (see Figure 2.7) that we all followed.

All for One and One for All!

I always notice the magic moment when I’m working with a team and realize that no longer am I among a group of individuals but a cohesive, tightly knit team. The moment when this “jigsaw puzzle” clicks into place sometimes occurs when everyone is involved in an intense yet convivial discussion about the project, but often, it simply occurs when everyone is having some fun, enjoying a communal laugh over a joke or two. Seeing that gel form is my favorite moment—it is then that the Musketeer attitude truly appears, with all members of the team genuinely feeling they are in the same boat, knowing and believing they will win or lose together as a team (Rubin 2012).

Wrap Up

The three shortcuts discussed in this chapter focused on a selection of tactics, tools, and tips to help you and your organization appreciate the underlying attitudes and abilities required for a team to perform efficiently—even exceptionally. Let’s recap what was covered:

Shortcut 4: Masterful ScrumMaster

What it takes to be a genuine servant-leader

The key abilities required of a great ScrumMaster

The innate attitudes demonstrated by a true ScrumMaster

Shortcut 5: Rock Stars or Studio Musicians?

The potential issues with rock star developers

Why we want our developers to think and behave more like studio musicians

A selection of values that should form your team’s professional personality

Shortcut 6: Picking Your Team Line-Up

Recommended development team size and specialist ratios

The problem with fractional assignment of work and how to manage it if required

Factors to consider when determining whether a ScrumMaster can work with more than one team

Figure 2.7. Prominently displaying your household rules reminds team members how they should treat each other.