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

Chapter 10. Larger Lessons

When you’re working hard and sprinting away, it can sometimes be very difficult to see the wood from the trees. To finish up, in this final chapter we’re going to take a step back and look at the bigger picture to fully appreciate what is truly important at the end of the day.

The following three shortcuts provide the final three larger lessons. Shortcut 28: Scrum Rollout Reckoning examines a selection of “macro” metrics focusing on ways to measure your organization’s evolving Scrum and agile abilities. Shortcut 29: Eyes on the Prize delves into the importance of self-organization for unleashing your team’s full potential. Finally, Shortcut 30: Shortcut to the Final Level shines the spotlight on three immensely powerful and fundamental words: transparency, inspection, and adaptation.

Shortcut 28: Scrum Rollout Reckoning

If you read Shortcut 19, then as promised, here is part two. If you didn’t, don’t worry because I am sticking to my earlier assertion that you can read these shortcuts independently, but hey, it doesn’t hurt to promote another handy shortcut, now, does it? Anyway, the big difference between this shortcut and Metrics that Matter is that now we are ready to move up a level and discuss metrics from a more holistic Scrum rollout perspective rather than at a Scrum project level. The same core advice still applies, such as the need to use metrics for good and not for evil purposes, which we explore shortly.

How Agile Are We?

I sometimes hear industry colleagues comment that their project team is “about 85 percent agile,” or they might say something like, “We are using Scrum to about 50 percent capacity.” The typical question that goes through my head when I hear comments such as these is, “What the hell doesthat mean?”

Let’s take a look at the first point: “We’re 85 percent agile.” Really? So, does that mean that if you do things a little bit differently, perhaps start implementing a few more practices, then you will soon be 100 percent agile? Wow, you can’t do any better than 100 percent, so when you hit this auspicious milestone, then I suppose there is nothing more to do except maintain what you’re doing, right? Wrong! I’ve said it before, but you shouldn’t need me to convince you that 100 percent agile perfection is never attainable! There is always something that can be done better, and considering that Scrum is fundamentally about continuous improvement, how can perfection ever be achieved? Classifying your agility in terms of percentages just doesn’t make sense.

I will answer the second point (using Scrum to 50 percent capacity) more succinctly—you are either doing Scrum or not. It is binary (see Figure 10.1). Implementing partial Scrum was discussed in Shortcut 2 via a comparison to chess—you can’t play without all the pieces. In the same way, you can’t be doing 50 percent Scrum—if you are then you might be doing something that resembles Scrum, but it sure isn’t Scrum.

Figure 10.1. Practicing Scrum is binary—you’re either doing Scrum or you’re not—there is no partial Scrum.

Humans Love to Measure

The obsession with measurement possibly starts for us when that first pencil mark is drawn on the wall by our proud parents measuring how tall we’re growing. Humans love to score and we love to assess our progress for a multitude of reasons. This isn’t a bad thing if done for the right reasons, such as gauging continual process and measuring what Scrum was able to deliver (especially relative to the initial potential benefits laid out in Shortcut 1). Assessment can also be a great team motivator to give everyone a sense of forward motion and progress in the same way that a belt system works in martial arts. Sure, to some, the belt is more important than the art; however, to most, the belt indicates that they have improved and been recognized for their hard work, and that isn’t a bad thing in my book.

There are two primary reasons that you might find it necessary to quantify the success of your Scrum rollout:

To decide whether you should continue with Scrum.

To assess your team’s progress along their Scrum journey.

Should We Continue?

How do you gauge whether your initial Scrum rollout has been successful? Well, you could rely on a bunch of numbers on a spreadsheet comparing your pre- and post-Scrum projects, but I for one don’t like using this approach (at least not in isolation), primarily because Scrum is not a mechanical process. It is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival.

An approach I particularly like that helps to enrich any quantitative feedback is a simple, subjective, collaborative survey that I first read about in Scrum trainer Gabrielle Benefield’s paper (2008). To gauge the effectiveness of their pioneering global Scrum rollout at Yahoo!, Benefield and Deemer used a simple survey based on the following six criteria:

How much the team got done in 30 days

Clarity of goals—what the team was supposed to deliver

Collaboration and cooperation within the team

Business value of what the team produced in 30 days

Amount of time wasted, work thrown out, cycles misused

Overall quality and “rightness” of what the team produced

Everyone involved in the survey had the opportunity to match the criteria to the following possible responses:

Scrum much worse

Scrum worse

Scrum about the same

Scrum better

Scrum much better

The aggregation of these results told a distinct and positive story about Scrum’s efficacy as perceived by the collective.

Costs versus Benefits

Now, irrespective of all of the warm, fuzzy results you hopefully obtain from your surveys, they shouldn’t be the only indicator of whether Scrum is going to be a raging success across your entire organization. Remember that, unlike an isolated pilot project, Scrum in the broader organizational context doesn’t operate in a vacuum. Transitioning from a controlled trial to a broad adoption introduces a range of new and often significant impediments that must now be considered. These impediments may include collocating cross-functional teams, modifying incentive schemes, adjusting the office layout, and overhauling sign-off procedures and client contract structures—just to name a few.

The cold, hard reality is that in some organizations, the initial Scrum rollout may serve only to identify the various environmental and cultural constraints that will impede the successful implementation of Scrum. The organization simply may not be ready, willing, or able to remove the necessary constraints.

Are We Getting Better?

Back to more positive news. Let’s say that Scrum is alive and thriving in your organization. It is only natural, then, to want to gauge whether you are stagnating or progressing.

To make this assessment, you need a relative benchmark that is pegged to either your past performance or your performance relative to others (particularly competitors).

Luckily for all of us, Mike Cohn of Mountain Goat Software and Kenny Rubin of Innolution have taken much of the pain away through the creation of the Comparative Agility¹ website. They explain that

1. To take the Comparative Agility survey, go to http://comparativeagility.com.

in Comparative Agility, we assume agile teams and organizations strive always to be better than their competition and their past selves. As such, there is no holy grail or “perfect ten” score to be achieved. In fact, there’s no predefined best-in-class or “Agile Maturity Level 5” to be achieved. Rather, Comparative Agility assessments present the results of a set of survey responses in comparison to some other set of responses. For example, using Comparative Agility it is possible to compare a team, project or organization to:

The total set of collected responses;

Responses from organizations in the same industry;

Responses from similar types of projects (such as commercial software, websites, and so on); or

Responses from projects with similar lengths of experience at becoming agile.

The 75 questions of a Comparative Agility assessment are organized into seven dimensions and thirty-two characteristics. The seven dimensions represent broad classifications of changes to be expected of a team or organization as it becomes more agile. The seven dimensions are:

Teamwork

Requirements

Planning

Technical practices

Quality

Culture

Knowledge creation

Each dimension is made up of three to six characteristics and a set of questions is asked to assess a team’s score on each characteristic. (Cohn and Rubin 2010)

The survey is user friendly and offers some fascinating insight into relative progress.

I have confidence in tools such as the Comparative Agility assessment that are written and facilitated by genuine experts. However, I do have a warning for you: if comparing to others is the only benchmark you use, then in essence, you’re letting others dictate your progress, and that can lead to stagnation. For example, if you take the survey and realize that you’re doing particularly well in relation to other organizations, you may feel a false sense of security. First, your competitors might not have taken the survey. Second, and worse, you may feel that you are in the luxurious position of being able to enjoy your time at the top and take your foot off the continuous improvement pedal, and that is never a good idea.

Keep It Simple

If you really want to keep things simple, just ask three questions:

Are your clients happier—are they remaining loyal and buying more products?

Are your team members happier—are they abandoning ship or are they smiling more?

Are your stakeholders happier—are they more relaxed and letting the team do its job rather than micromanaging?

In addition, the metric that should really interest you is the rate of Scrum adoption growth. Is Scrum delivering such great results that it is now beginning to spread across the broader organization, even crossing the chasm into other non-software related departments? For me, that is the ultimate success!

Spread the Good Word

In Australia, it is widely accepted that culturally, we’re not very good at celebrating success—this trait, believe it or not, even has a label: “tall-poppy syndrome.” Being humble and modest is at times admirable; however, when introducing change, celebrating success is critical to help maintain momentum, generate excitement, and encourage those who have been taking the risks. So, in this case, I say forget modesty and let the whole world know how well things are going! Conduct regular team meetings to discuss progress. Invite senior stakeholders to these sessions. Circulate emails, as discussed in Shortcut 25, with anecdotal stories to back up the statistics. Sing success from the rooftops! I don’t care how you do it, but you should celebrate your continual improvement and let the team and the organization share in the glory.

Shortcut 29: Eyes on the Prize

In my formative years, I was obsessed with the game of football (or soccer to my fellow Aussies and friends in North America).

During lunchtime at school, a whole bunch of us would head down to the fields and play some extremely intense, pick-up games. We would rapidly organize into two teams, and then we were off. When I look back at those enjoyable games, I am in awe at the amazing chemistry that seemed to automatically exist between us. Somehow, we all immediately worked out which position we would play in. Without the aid of uniforms, we were able to identify who was on each team simply by constantly talking. The dedication was outstanding (considering that nothing was at stake but daily pride), the interplay was amazing, and everyone seemed to know where everyone else was going to be. It was almost telepathic—if someone was caught out having to defend by himself, the rest of the team would sprint back to help out (even though they weren’t necessarily defenders). But best of all was the tight camaraderie—winning or losing, everyone was always encouraging each other.

I was also fortunate to have had the opportunity to play soccer for my state at a national level. My expectations were so high for my first tournament because I would be playing with and against some of the best of the best in the entire country! We had slick uniforms, super-talented specialist players, an experienced manager with plenty of impressive plans up his sleeve, and significant individual motivation (the national team would be selected from this tournament). So, how did this tournament go? Did we perform like the stars we thought we were? The answer is an emphatic no—we were plagued by mediocrity! Why? What went wrong, you ask? Well, we squabbled and finger-pointed over every little mistake; our meticulous game plan failed as soon as someone got injured; we didn’t know one another well, so we couldn’t play to each others’ strengths; driven by individual glory, teamwork was forgotten; and because of very rigid positional play, backup wasn’t forthcoming when someone became outnumbered.

Bottom line was that this command-and-control approach to playing soccer (combined with a bunch of prima donnas) was much less effective than our self-organizing, lunchtime games.

How does this anecdote relate to our Scrum teams? Well, having read this far through the book, you will realize that there is a great deal of work to do as a ScrumMaster. Being inundated with so much to do, you may find it very difficult to keep your eye on the holy grail: the fostering of a truly self-organizing team, akin to our kick-ass lunchtime soccer teams.

Explaining Self-Organization

Let’s now formalize (ironic choice of words, I know) what self-organization means, as it is often misinterpreted by the skeptics to mean something more akin to bedlam! I like Rubin’s (2012) description:

Self-organization is a bottom-up emergent property of a complex adaptive system. In such systems, many entities interact with each other in various ways, and these interactions are governed by simple, localized rules operating in a context of constant feedback. These types of systems exhibit interesting characteristics, such as being remarkably robust and producing amazing novelty.

A development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done.

Self-organization is extremely powerful, as demonstrated by my soccer example, and this can be backed up time and time again just by observing nature. Watch an ant colony, a beehive, or a flock of birds, and you’ll see clear applications of self-organizing behavior. Lyssa Adkins (2010) uses another great example from the world of entertainment when she describes her awe after watching a string quartet:

These four guys sat down, and with no one looking at anyone, no one counting down, no one doing even as much as taking in a big breath, they just started to play . . . As they played, they managed the music themselves, shifting and correcting as the piece went on. No conductor needed.

Environments and Boundaries

Whenever you try to explain the benefits of self-organization to a skeptic, it is critical not to ignore references to boundaries. Skeptics who draw parallels between self-organizing teams and a group of headless chickens need to understand that responsible team members are the ones best equipped to determine how to do their work and when they think it will be done. A manager who likes to dictate these directions is simply not as qualified to make these calls in comparison to the team actually doing the work. By dictating these terms, all that the manager accomplishes is the provision of a false sense of control to the rest of the organization.

That being said, team members don’t just magically wake up one morning in a state of fluent self-organization. Just like a plant, self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control and all over the neighbor’s fence. These boundaries don’t form themselves, nor do they stay maintenance-free. It is the ScrumMaster who needs to work closely with management to “Establish enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos” (Takeuchi and Nonaka 1986).

These checkpoints or boundaries come in many shapes and forms (see Figure 10.2). Let’s look at five of the big ones.

Figure 10.2. Whether a soccer team or a Scrum team, self-organization leads to better results and more fun!

Scrum Rules

First, the Scrum rules. Even though there aren’t any Scrum police who will jump out from behind the office coffee machine and fine you for not following the Scrum rules, a hefty fine might seem like a preferable option if the rules are not followed with discipline. If you’ve ever seen the bedlam that ensues when a soccer referee appears to get the rules wrong, you’ll find a similar situation can erupt in a Scrum team if the rules become ambiguous or change frequently. By consistently enforcing and reinforcing the (small) set of Scrum rules, the team’s conceptual self-organizing boundaries will be clearly established, allowing them to focus on actually doing the work.

Team Makeup

The team members rarely get to determine who forms their ranks even though they are the ones that must work together to self-organize. Get the wrong mix of personalities and/or skill sets, and the lofty goal of self-organization goes out the window (see Shortcut 5). Even with the right mix of people, conflicts will occur and dynamics will change. The ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one.

Physical Environment

Shortcut 3 discusses the importance of the physical environment, and the reality is that unless you generate a physical working environment that enables the collocation of team members, self-organization is going to be more challenging (but definitely still doable). Creating a contained yet open space that is conducive to natural and regular verbal communication establishes the physical boundaries to allow the self-organizing team to easily connect without contrived, formalized communication channels.

Culture

If individuals are constantly on a mission to cover up their mistakes and point fingers at other people, then you can rest assured that the chances of attaining self-organizing status is somewhere between zero and nil. The ScrumMaster and management are responsible for providing a cultural safe haven for the team to feel relaxed about working together (see Shortcut 24). This culture needs to also foster a collective team desire to continuously seek improvement opportunities and try out new ideas without fear of failure.

Requirements

A fundamental tenet of Scrum is that the product owner (via the product backlog) determines what should be developed and in what order rather than it being up to the whim of the development team. In addition, the agreed-upon definition of done (see Shortcut 11) sets the clear quality boundary, ensuring that expectations between the product owner and development team remain aligned.

Ensuring that the developers understand the constraints inherent in the product backlog and definition of done is critical to allow them the freedom to self-organize and develop the requirements in the most optimal fashion.

The Infinite Role

It always bothers me when I hear noble exclamations similar to, “As great ScrumMasters, we should always strive to make ourselves obsolete,” referring to the fact that once the goal of team self-organization has been attained, the ScrumMaster becomes redundant. This is nonsense, and I’ll tell you why.

First, change is inevitable. In the same way that a record-beating, all-star sporting team won’t stay together forever, neither will a brilliant, self-organizing Scrum team. People move on, team members have off days, and companies undergo restructuring that causes teams to split up. Where there is the possibility for change, there is the requirement for a ScrumMaster.

Second, impediments are never predictable. No one knows what issues will pop up out of the blue that can’t be resolved by the team, irrespective of how self-organizing they are. There are also impediments that shouldn’t be tackled by the team, but by the ScrumMaster, to ensure maximum time is being spent on the actual development work.

Finally, perfection is impossible. Nothing in the world is perfect, and improvements can always be made, even to mature, self-organizing teams. Fine-tuning and helping teams make incremental improvements is much harder (but potentially more rewarding) than making the obvious fast-track improvements that are easily identified in less mature teams.

Shortcut 30: Shortcut to the Final Level

Yes, I know—you’ve heard it repeated ad nauseam that Scrum is “hard and disruptive” (Schwaber 2006), and I’m sure many of you will have learned this lesson firsthand.

I don’t disagree with this contention, as Scrum certainly does come loaded with some serious transformational change stipulations. There are numerous hurdles to overcome, such as building cross-functional team cohesion; ensuring product owner empowerment; keeping high-performing, self-organizing teams together; and ensuring that senior stakeholders support the change from a systemic perspective.

However, I tend to look at Scrum in another way. I see it as completely infallible and always win-win. Sounds like a strange thing to say, doesn’t it? Well, let me explain.

Looking in the Mirror

Remember in Shortcut 12 when I discussed that being able to constantly inspect and adapt the work being completed in a sprint is like the team looking frequently into a mirror to uncover small issues nice and early? Now, let’s take that same principle to a macro level. Let’s face it—your Scrum project might not work out. It might downright flop for a number of reasons. However, if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle. If you can identify these issues, you should consider it an accomplishment! It’s just like physical health; if you’re unwell, don’t you want to know what is wrong with you so that you can choose a course of action to rectify the situation? Scrum is like a brilliant doctor with the ability to identify and diagnose all sorts of problems that you didn’t even realize you had.

Choose Your Own Adventure

Please remember that Scrum is a light framework with only a few key rules and a limited set of practices. This book is certainly not trying to lay down the law on how Scrum should be implemented; it is simply offering a set of interpretations and opinions based on a specific set of experiences. Whether you choose to listen to my particular recommendations or not won’t impact the fact that you are doing Scrum; so long as you stay within the bounds of the framework, you can truly choose your own adventure. Books like this one simply act as an optional travel guide for your journey. Just as for a vacation, all you really need is a passport, some money, and an understanding of the travel regulations and local laws, but apart from that, you are free to do what you like. Travel guides are not mandatory, but they can certainly help!

Experiment

In Shortcut 24, I offered some advice to help convince the conservative pessimists to free themselves from the fear of change. This advice is so powerful that it warrants being restated with additional gravity and emphasis in this final shortcut. If there are only three words that you remember from this entire book, they should be

TRANSPARENCY
INSPECTION
ADAPTATION

These three pillars of empirical process control form the foundation of Scrum and, if understood correctly, will ensure that you are always in a win-win situation. People don’t like change for many reasons, and one of the core reasons is that they feel there will be no room to move once the decision to adopt something new has been made. But here’s the thing: Scrum is open-minded. If something isn’t working, there is a very simple guideline: inspect and adapt. By being open and transparent, you’ll find it easy to inspect, and by regularly inspecting, you are able to adapt effectively. Adapting may include adjusting, reverting back to an old approach, or trying something totally new. A Scrum adoption should be seen as a big collection of small experiments (actions from your reviews and retrospectives) wrapped up in a big experiment (perhaps the Scrum pilot program that is initially run). If this is how Scrum is interpreted, there should never be any tears because at the end of the day, through transparency, inspection, and adaptation, the most appropriate happy path will eventually be identified to take your team and organization to the next level ofefficiency. As Richard Buckminster Fuller (2008), a systems theorist, put it, “Every time a man makes a new experiment he always learns more. He cannot learn less.”

Don’t Rest on Your Laurels

Some of you might be at a stage where you are now feeling pretty happy; you’ve been instrumental in getting Scrum up and running, it’s humming along nicely, and everyone is grinning from ear to ear. Time to sit back and let the good times roll, right? Wrong! Recall from Shortcut 4 that while you can certainly feel perfectly happy with the achievements made so far, you should never feel a sense of completion. Remember that nothing is perfect, so there will always be improvements to be made. Further, in a dynamic organization, nothing and no one stands still for long. Impediments can pop up at any time, team members will move on or get replaced, and departments could merge or split up. You should see your entire environment as one that is constantly in flux, irrespective of how placid it might seem at any specific point in time.

Flux requires a calm, guiding force that is able to react positively to change while smoothing out the creases in the team fabric before they become permanent wrinkles. With various staff coming and going at all levels, you need to be continuously educating the organization, and I’m not just talking about those involved in the software development efforts. Your ultimate goal is to convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do” (Kearns 2012). If agile becomes a part of the entire organization’s DNA and culture, the cascade effect will make the implementation of Scrum software projects so much more natural.

Exceeding Expectations

It’s funny, but when you immerse yourself in Scrum, you may uncover a fascinating side effect—it permeates into other areas of your life, becoming an innate way of thinking and behaving. For example, as I mentioned in Shortcut 11, I have used Scrum, with its associated artifacts and activities, at home to get our household chores done ever since our first baby came along. And I haven’t stopped there. I have embraced the underlying ethos of Scrum in other day-to-day activities. How? I try to work (and play) at a consistent and sustainable pace; I focus more on completing a task, be it a chore at home or a job at work, in its entirety rather than trying in vain to juggle five things at once (an old habit of mine). I no longer need my 3-year life plans; instead I allow my future to take a more flexible and emergent course. Displays of dictatorial command and control behavior, whether in the workforce or household, make me wince now, when in the past I may well have been that dictating commander. Instead, I aim to always use persuasion principles (that I adopted as a ScrumMaster) more akin to the flowing, natural martial art of Aikido. In this sport, rather than using direct force, you subtly blend with your opponent and redirect his or her attention to where it should be focused. These days I’m always asking myself how I can get a positive response and reaction from others without having to revert to authority and unilateral commands. I also now run very regular introspective retrospectives on myself—usually during the solitary trip to work in the mornings rather than waiting for that short window of opportunity on the 31st of December to set all of my unrealistic and quickly forgotten New Year resolutions.

Final Wrap Up

When I set out on my Scrum journey, I was expecting it to change the way my teams worked for the better. I certainly didn’t expect it to change many of my underlying philosophies and the way I behave in general. However, that is exactly what has happened. Not only has Scrum made me a better colleague and leader, but I truly believe it has also made me a better person.

My goal is to help extend Scrum’s transformational qualities far outside the software environment, and I hope you are encouraged to join me.

Thank you for letting me share my thoughts with you, and I wish you a safe and enjoyable trip as you embark on the next leg of your exciting Scrum journey.