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

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

Chapter 1. Scrum Startup

Taking that first step on any unfamiliar journey can be daunting and fraught with challenges. Questions such as Where do we start?, How do we start?, and most important, Why should we start? can often turn into momentum-dampeners that impact an organization’s goal of adopting a new framework such as Scrum.

The following three shortcuts aim to help you and your organization answer these tough questions and to put some spring into that first step!

Shortcut 1: Scrum on the Pitch provides guidance to assist in “selling” Scrum to those in your organization involved in its adoption. Shortcut 2: Fragile Agile identifies a selection of common pitfalls to watch out for during the early days of your Scrum journey. Finally, Shortcut 3: Creative Comfort discusses a range of steps to ensure an environment and culture that fosters a healthy Scrum team.

Shortcut 1: Scrum on the Pitch

Scrum is seriously not a tough sell. I must admit that obtaining buy-in for Scrum these days is almost like shooting fish in a barrel. Okay, well, maybe it’s not quite that easy, although I don’t think anyone would disagree with the observation of Ken Schwaber, cocreator of Scrum, that “Scrum appears to have crossed the chasm and is now more mainstream than radical” (Schwaber 2011). This progress has certainly made the lives of the new generation of Scrum evangelists somewhat easier than it was for our pioneers. At the very least, it means that we no longer have to withstand as many strange stares when we start presenting software development using descriptions borrowed from the sport of rugby!

On that note, let’s first tackle the question you’ve no doubt been asked many times in your Scrum-promoting travels: “What does SCRUM stand for?” Many people (even so-called qualified ScrumMasters) use this capitalized spelling, implying that Scrum is an acronym. If you fall into this camp, you might be surprised when I tell you that Scrum is not an acronym and was actually named after rugby’s scrum (yes, all lowercase this time).

For those not familiar with the sporting variety of scrum, it is a tight pack of burly, 250-ish-pound rugby players linked together like a jigsaw puzzle who work as one to drive back their opposition while progressing down the pitch (field) toward their try-line (scoring zone). It is this concept of tight, self-organizing, collaborative teamwork that gave birth to the agile development version of the word. This initial comparison was described by Takeuchi and Nonaka (popularly known as the godfathers of Scrum) in their groundbreaking paper, “The New New Product Development Game” (Takeuchi and Nonaka 1986). Hailing from a rugby-passionate country, I have witnessed the sporting scrum in action. It is similar in concept to the ancient Spartan shield-locking phalanx (see Figure 1.1)—immensely powerful if discipline is maintained and teammates work together as one.

Image

Figure 1.1. Just like a Spartan phalanx—impenetrable if discipline is maintained.

Werewolf Slayers?

Convincing stakeholders of the efficacy of Scrum is a job that I just love to do! Why? Well, I get a buzz seeing eyes light up when I talk about transparency, early delivery of business value, reduced waste, and risk mitigation. Further, it excites me when I hear the sigh of relief when I put forward the drastic notion that change should no longer be viewed as a hindrance but as an opportunity.

All that being said, we Scrum enthusiasts unfortunately are not werewolf slayers with a pack of silver bullets. The reality is that while the concepts behind Scrum are simple and intuitive, implementing them successfully is anything but simple.

So, what is it about Scrum that has made it the most popular agile framework? The answer to that question depends on who you are pitching to—the Scrum team (including the ScrumMaster, product owner, and developers) or the senior stakeholders (let’s call them the project sponsors). The rest of this shortcut focuses on the trigger points that most appeal to these two key groups.

Let’s start with a great quote from Mike Cohn, one of the founders of both the Scrum Alliance and the Agile Alliance, which makes for a great initial elevator pitch:

Scrum is an agile framework that allows us to focus on delivering the highest business value in the shortest time. (Cohn 2007a)

Okay, sounds good so far! Now, let’s get more specific and start explaining to our two groups what’s in it for them.

The Scrum Team

Let’s begin by exploring some key benefits that we can promote to the Scrum team, consisting of the ScrumMaster, product owner, and developers.

Reduced Context-Switching

The all-too-common tap on the shoulder with yet another request to work on something “more urgent” is removed. Scrum provides the construct of the protected sprint (which I personally like to call “fixed flex”). The protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session (see Shortcut 8) while also offering the product owner flexibility to modify the broader product backlog throughout the project.

Sustainable Pace

I’m not going to lie and say that if you adopt Scrum there will never be any late nights. That being said, Scrum is all about working at a steady, sustainable pace to avoid those last-minute, mistake-laden cram sessions. Scrum decimates the traditional culture of heroically working late nights and weekends just to prove how dedicated one is to the cause.

Rubin (2012) makes the point nicely:

One of Scrum’s guiding principles is that team members must work at a sustainable pace. (No more death marches!) In doing so, they deliver world-class products and maintain a healthy and fun environment.

No More Delegating Dictators

No longer does the dictatorial, delegation-addicted project manager determine who’s doing what and when it needs to be done by. Instead, the establishment of self-organizing teams is one of Scrum’s flagship goals. These empowered teams determine how the work will be tackled because they are the ones actually doing the work!

No More “Us and Them”

Although Scrum respects and appreciates an individual’s uniqueness, the idea of personal achievement is overshadowed by team achievement. Gone is the specific performance monitoring of individuals, not to mention any us-and-them mentality between various development functions. With Scrum, everyone pitches in to the maximum extent that they can to help the team finish what it collectively committed to completing.

A Dedicated “Shield and Bulldozer”

Nothing is more abhorrent to a focused developer than having to deal with politics, interruptions, and impediments. Thanks to the servant-leader ScrumMaster role (see Shortcut 4), the development team can focus on what it does best—developing great software. The ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.

Hopefully, you now have the future team convinced and ready to give Scrum a go.

Project Sponsors

Next, let’s uncover a selection of key benefits that pertain to our higher-level project sponsors.

Risk Mitigation

If you think about it, on a traditional software project, there is 100 percent risk and 0 percent business value delivered until the final day of the project when the software is (hopefully) released successfully. Massive 18-month release cycles incorporating waterfalling phases don’t offer meaningful insight or value until right at the very end (see Figure 1.2).

Image

Figure 1.2. Waterfall projects carry 100 percent risk until the end of the project.

By delivering working, quality functionality incrementally, the Scrum team provides genuine business value to the customer in weeks (or days) rather than months (or even years), and the risks are significantly reduced thanks to the faster feedback cycles.

Visibility, Transparency, and Fewer Surprises

Visibility is particularly pertinent for organizations whose project sponsors don’t have a software development background. To these sponsors, development can often appear to be a very opaque black box offering zero visibility. Scrum, however, is grounded in empirical process control that promotes transparency as a core tenet. It is achieved in part via easy-to-understand “information radiators” (such as the task board—see Shortcut 21) as well as regular sprint reviews that everyone is invited to.

Continuous Improvement

Along with transparency, the other two pillars of empirical process control are inspection and adaptation. These important elements are applied to both the product under development and the development process being utilized to ensure that continuous improvement is occurring across the board. “Inspect and adapt” is Scrum’s core mantra.

Change Is an Opportunity

No longer do product sponsors have to ruffle feathers when they come up with a great new idea that they want to add to the product backlog mid-project. Referring back to the concept of fixed flex, the project sponsors, with the permission of (and via) the product owner, are liberated and welcome to add to the product backlog as they see fit, at any stage throughout the project.

Good News and Not-So-Good News

See, I told you it was easy! The good news is that I don’t think you’ll find many members in either of the key groups who won’t get at least a little bit excited by what Scrum has to offer.

The not-so-good news, though, is that however easy it might be to sell Scrum, backing up your pitch with a highly effective Scrum implementation is a very different story. Even for those of you who may have managed to get a Scrum implementation off the ground, getting your team humming like a finely tuned Scrum Ferrari rather than a beat-up old Scrum Pinto requires patience, an open mind, and some scrapes and bruises along the way, as well as handy books like this one!

Shortcut 2: Fragile Agile

Possibly one of the most frustrating comments that I hear when speaking to novice software teams is, “We do Scrum—we work in sprints, we have a daily scrum, and we even have a product backlog.” In addition, although they may not explicitly say it, you can often add, “We don’t write any documentation, we release haphazardly, we plan on the fly, and we don’t care about buggy code because we’ll just fix it up with a bug iteration.” ARGH! These people give Scrum a terrible name, and worse still, when their projects inevitably fail, it is very difficult, if not impossible, to win back the senior stakeholders who have been burnt by a badly warped Scrum implementation.

It’s a Framework, Not a Method

You will often hear Scrum described as a method—this description is incorrect. Scrum is a framework of practices tied together by a small set of clearly defined rules. There are significant differences between a method and a framework. A method implies a one-size-fits-all, formulaic approach, whereas a framework offers a more flexible platform from which a variety of approaches can be derived depending on the environment.

To correctly implement Scrum, it is important to follow the few prescribed rules and to work within the framework of practices. So long as the approaches you choose to implement adhere to this premise, you are on the right track. As Schwaber (2011) writes in his blog, “Scrum is like chess. You either play it as its rules state, or you don’t.” Extending this analogy, we can say that implementing the Scrum framework partially is like choosing to play chess with 20 pieces instead of the standard 32 pieces. Although there is a slim chance that the game will work in some form, the fact is that the 20-piece adaptation is an alternative and untested game that shouldn’t be called chess (see Figure 1.3).

Image

Figure 1.3. Just as you wouldn’t change the rules of chess, you shouldn’t change the rules of Scrum.

Scrum does not contain redundant rules or practices. As such, for it to work as intended, it must be implemented holistically—partially adopting Scrum is tantamount to not adopting it at all.

Qualifications versus Qualities

A ScrumMaster certification is certainly helpful, but depending on who is getting certified, it still might not mean all that much. I recall years ago, during my first ScrumMaster course, one attendee was a project manager from a bank who seemed to believe he was the drill sergeant from the movie Full Metal Jacket.1 I remember thinking to myself that even if this course went for 2 years, this guy would never get it. The bottom line is that the qualities of a ScrumMaster (see Shortcut 4) are significantly more meaningful than a certification.

1. www.imdb.com/title/tt0093058.

Abusing the Agile Manifesto

Those who tend to warp Scrum may even occasionally quote the words of the Agile Manifesto (Beck et al. 2001) to justify their complete lack of documentation and absent planning:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

image Individuals and interactions over processes and tools

image Working software over comprehensive documentation

image Customer collaboration over contract negotiation

image Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Anyone who abuses the Agile Manifesto in such a manner has either (a) not read the final line, (b) forgotten the final line, or (c) ignored the final line.

It is extremely important to remember that while the items on the left are valued more, the items on the right are almost always needed even if they are required in only a limited capacity (depending on the type of project).

A Few Scrum Antipatterns

What follows is a sample selection of symptoms that will immediately indicate that Scrum is being corrupted and warped. These symptoms should not be confused with “teething” issues faced by novice (yet genuine) Scrum teams. For example, a daily scrum that doesn’t always start on time is not ideal, but with the right motivation, it is a process that can improve and isn’t necessarily a signal that the team simply doesn’t get it.

Test Sprints

Quality assurance should be treated as an integral part of the development process. A requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done (see Shortcut 11). However, sometimes the message gets twisted. When this happens, it tends to manifest as an initial bunch of “functionality” sprints that focus purely on banging out new code (to give the impression that progress is happening), followed by a bunch of “catch-up” sprints for identifying and fixing bugs.

The typical justification for this behavior is that the team wants to validate their work by at least showing the general functionality to the users of the software first. When I come across this situation, I point out to the team that just because they might be working in sprints, it doesn’t mean that they aren’t waterfalling. Remember that until the functionality is fully tested and releasable, it is not complete and should be considered unreleasable (therefore useless) and very high risk.

Another implementation of this antipattern is the scenario in which the programmers and testers are working in different sprints: for example, the testers may be working one sprint behind. This situation arises primarily when automated testing practices are still immature and reliance on manual regression testing is still heavy. This staggered sprint scenario inevitably leads to the same catch-up sprints just discussed.

Never-Ending Sprint Zeros

Sprint zero isn’t really a sprint but an artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint (with all of the required trimmings).

This preliminary work doesn’t typically have a timeframe, nor does it exhibit all of the typical structural elements found in a real sprint, such as a sprint backlog and well-formed requirements.

Although I’m not a fan of the misleading sprint zero label, I don’t actually have an issue with the concept of a preliminary stage. My main problem with sprint zero arises when inappropriate work is bundled into it that delays the starting of real sprints. Let’s take a look at what should and what shouldn’t go into any sprint zero (see Figure 1.4).

Image

Figure 1.4. Sprint 0 tasks should be kept to the bare minimum.

Just because the items in the Don’t Include list in Figure 1.4 might appear more nebulous than the concrete functional requirements, it doesn’t mean they can’t be estimated, planned, and broken down into tasks and therefore included in a sprint. In fact, I would argue that because of the nebulous nature of this work, it is even more important to wrap the proper sprint mechanics around it in order to offer greater visibility and tighter control.

Random-Sized Sprints

A regular sprint duration is important for a number of reasons that are outlined in Shortcut 8.

One of the most common excuses I hear for sprint length fluctuation is that the team wanted to sneak in a few extra days to finish some nearly complete requirements so that the sprint review is more compelling.

I believe there are only two reasons for varying the sprint length:

image When a new team is experimenting in the early days following initial formation.

image When all work is completed before the last day of the final sprint (see Figure 1.5).

Image

Figure 1.5. Once determined, maintain a consistent sprint duration.

Estimation Isolation

This situation has been prevalent in every non-Scrum environment I’ve worked in. It is instigated when a senior developer is asked in isolation to estimate the duration of various pieces of work. You might well ask why this is a problem considering that someone so senior should be the most qualified to offer estimates. Well, this is exactly one of the problems. Although the senior developer might be the most experienced, in most cases he or she won’t be doing the actual work. The senior developer’s abilities will no doubt differ from the abilities of the team members who actually tackle the tasks, and so it follows that his or her estimate is going to differ from the eventual reality.

In addition, it isn’t an individual who is doing the work—it is the team—and as such the team as a collective should make the estimation (see Shortcut 14). When only one person conducts the estimation, there are no checks and balances in place. What if the individual is having an off day or perhaps misheard some vital detail and made an incorrect assumption? When a group of diverse team members is involved, such slips are much less likely to occur thanks to the multiple layers and filters processing the information.

Reliance on the Spec

If you start hearing comments such as “If it’s not in the spec, it won’t get done” or “I implemented exactly what was in the spec,” you can also be sure that your clothes are already wet courtesy of the waterfall that the team is standing in. It also demonstrates that your team members have become bureaucrats who have lost their ability to communicate with other human beings. Any so-called spec should exist only as a placeholder or reminder, and the actual requirements will manifest in both the dulcet tones coming out of the team’s collective voice box as well as in the actual working software that the team produces.

Poor ScrumMaster Selection

If your ScrumMaster doesn’t maintain the attributes detailed in Shortcut 4 and/or doesn’t perform the functions detailed in Shortcut 26, then you are more than likely being led by an imposter. How do you spot an imposter? Well, if the ScrumMaster is making unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant, then there are going to be problems.

Listen to Your Folks

Heed the advice that your parents probably gave you once or twice: If you’re going to do something, do it properly. In the same way that you wouldn’t change the parameters of chess, you shouldn’t change the parameters of Scrum. Either implement Scrum within the boundaries of its framework or don’t call what you’re doing Scrum.

Shortcut 3: Creative Comfort

Does this sound familiar?

ScrumMaster: “Good morning guys!”

Developer 1: (Grunts)

Developer 2: (Barely recognizable nod)

Developer 3: (Headphones on and no facial recognition detected)

Once upon a time, this typical morning ritual was one of the most annoying aspects of coming to work. The morning greeting, the most trivial of human interactions, would always put me in an irritable mood to kick-start the day. Why? Simply because interactions similar to the one described can make you feel as though you’re entering a shrine rather than a hive of productivity.

Some of you might think it’s somewhat lame to cheerily say good morning on a particularly cold and gray Monday morning: “We’re engineers, damn it, not bubbly sales people,” I hear some of you say. Tell me something: If you went over to your pal’s home, would you mumble a greeting under your breath and sit on the couch without saying anything further? I doubt it, but if you did, how do you think your pal would feel? Pretty annoyed, I would imagine.

A smile and a genuine “How are you?” makes you feel that you’re among friends, immediately putting you in a more productive and lively frame of mind. It’s the small things like a friendly hello in the morning that can start making a difference in how a team operates and how the team members interact with each other.

The advice in this shortcut can be applied to any team environment, but because Scrum teams are probably the most tight-knit groups that you will operate within (unless you are actually locking your head between two sweaty teammates’ midriffs—yep, that is what an original rugby scrum is all about), it is even more important to ensure that everyone is feeling energized and excited about coming to work.

We are at work for most of our waking hours. We often spend more time with our colleagues then we do with our spouses and children. For those of you who just read that sentence and sighed profoundly, you need to read on, because coming to work should not be like entering the dark coalmines.

The good news is that it is extremely easy to implement some very simple (and inexpensive) measures to maintain team member satisfaction.

Individual Gratitude

After all of this Scrum talk promoting the centrality of the team, you might be feeling that individual recognition is a no-no. Scrum is certainly more focused on the achievements of the team than on those of the individual, but it does not mean that individuals simply become cogs in a machine. The fact remains that teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.

I was the ScrumMaster in a new Scrum team that performed so well during a particularly critical project that we were recognized in the national companywide awards with the Team of the Year prize. This recognition was genuinely appreciated by the group, but it was obvious to me that each team member was much more appreciative when I personally went to each one of them and sincerely thanked them for a job well done, acknowledging specific contributions that they had made. Tony Schwartz, president and CEO of the Energy Project, blogs in the Harvard Business Review, comments on why individual appreciation matters so much:

Feeling genuinely appreciated lifts people up. At the most basic level, it makes us feel safe, which is what frees us to do our best work. It’s also energizing. When our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value. (Schwartz 2012)

I’m certainly not recommending that the team shouldn’t be thanked collectively, but as Dale Carnegie, author of How to Win Friends and Influence People (1981), poetically puts it, “leaving a friendly trail of little sparks of gratitude on your daily trips” certainly goes a long way.

Physical Environment

I remember a few years ago when an email illustrating the funky environment of the Google Zurich offices went viral (“Jobs at Google” 2005). I recall many of my non-software friends were incredulous at what they perceived to be capricious spending on furniture and fixtures that they claimed were more suited to a playground than a serious office. “Do they do any actual work there, or do they just goof around having fun all day?” an attorney buddy of mine bemoaned at the time.

Our industry is the leading light in guiding the corporate world out of the dark days of stark, gloomy offices that feel more like Industrial Age factories. Unlike my legal friend, many technology companies (in particular) understand that doing serious work while enjoying one’s physical environment is actually possible!

Now I’m not saying that you need to go out and stock up on colorful beanbags, incandescent lava lamps, and slippery-slides. However, aiming to turn your physical working environment into something that feels a bit more like home shouldn’t be viewed as capricious and whimsical but as a goal that just makes sense!

Scrum relies heavily on an interactive physical environment that promotes the Scrum value of openness, so the following list should be considered the basics for an environment conducive to Scrum:

image Plentiful whiteboard and wall space that can house the various task boards and associated artifacts.

image Plenty of light (although I have worked with the odd developer or two who had vampire tendencies and preferred the dark).

image Open desk space for each team, with partitions only to separate the different teams.

image Ample chair space to allow for comfortable walkthroughs (see Shortcut 12).

image A small, round discussion table for each team within its working area.

image Readily available, large meeting rooms with projectors and whiteboards for the Scrum meetings, such as sprint planning, reviews, and retrospectives.

image Do-not-disturb zones where team members can go to think in peace—this area should include a desk and some room to pace around.

image Private areas where personal phone calls can be made.

image Buffering from the noisier elements of the organization, such as the sales or customer service teams who typically talk on phones for much of the day.

Tools of the Trade

Offering developers the latest and greatest technology shouldn’t be seen as a magnanimous gesture. Do you think carpenters see a sharp chisel as a privilege? No, they see it as a bare necessity to complete a professional job.

The funny thing is that, in my experience, developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit. As the software commentator Joel Spolsky (2007) points out, “Programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!” Now, I’m sure Joel is not advocating paying non-competitive salaries, but the point is that by simply providing the right tools for the job rather than maintaining traditional false economies (by offering old hand-me-down machines to save a couple of bucks), you are not only keeping developers happy but also improving overall productivity!

Identity

Humans are tribal by nature, and we like to feel that we are part of an elite group. Scrum lends itself nicely to allowing these social dynamics to develop, thanks particularly to the strong encouragement to collocate team members within the same contiguous area. Once this first step has been achieved, it’s time to really build those strong bonds. I encourage (but certainly don’t force) Scrum teams to adopt a name and a color, just as sports teams do, and to decorate their area with corresponding posters, logos, and banners. As Tom DeMarco and Timothy Lister point out in their landmark book Peopleware (1999), “Jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.”

In one company that I introduced Scrum to, we ended up with a Team Spitfire, Team Thundercats, and even a creatively named Team Awesome, all of whom waged friendly battle by constantly teasing each other for breaking the build or for having overly long daily scrums. I truly believe that this innocent competition improved productivity as well as pride in the quality of the work produced.

Although team identity is vital, it is also really important that the team identifies with and feels engaged with the product they are developing. As Cohn (2009) aptly puts it,

One of the best ways of adding energy is increasing passion. The more passionate people are about their projects, the more likely they are to fully engage in them each day. The product owner is the key here. Product owners need to convey a compelling vision around the product being developed so that team members are enthusiastic about working on it.

A nice way that I have seen to help build this passion and sense of involvement is to include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.

Shining Happy People

Making our working environment feel like home or, better yet, like an exciting amusement park (including the resident jokers and clowns—I’ve had plenty in my teams) perhaps takes us back to our most carefree times during childhood when we were arguably at our most creative and happy.

It is an illusion that it takes grandiose gestures such as bonuses, important-sounding job titles printed on delightfully watermarked business cards, or initiatives like Google’s famed “20 percent time” (Wojcicki 2011) to keep people motivated. I don’t even think it is critical that people feel a constant sense of “mastery, purpose, and autonomy,” as written by Dan Pink in Drive: The Surprising Truth about What Motivates Us (2011), to feel productive and happy (although it certainly helps). Instead, a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Wrap Up

The three shortcuts discussed in this chapter focused on a selection of tactics, tools, and tips to help you and your organization get Scrum off the ground. Let’s recap what was covered:

Shortcut 1: Scrum on the Pitch

image Scrum’s elevator pitch.

image The concept of fixed flex, used to reduce context-switching while still offering scope flexibility.

image A range of key benefits relating to both the Scrum team and the project sponsors.

Shortcut 2: Fragile Agile

image How to differentiate between a framework and a method.

image Reasons it is more important to focus on an individual’s qualities than on his or her qualifications.

image A selection of Scrum antipatterns to watch out for.

Shortcut 3: Creative Comfort

image Ways to improve team morale by focusing on team and individual appreciation.

image Ideas for improving the physical working environment to ensure a collaborative and productive space.

image Tips for helping your teams create a sense of identity and purpose.