Context Considered: Focusing Agile Investments for a Better Return

 Leadership/Team Feedback Loop

Leadership/Team Feedback Loop

Organizations invest a lot of money, time, and energy in Agile. Arguably we’re decades into the Agile game. We should be pretty good with this Agile stuff by now. So why are we not consistently seeing good results? Why do some Agile initiatives fizzle out? Why do some organizations abandon Agile in favor of the next big fad? In other words, why are we not seeing the bang for the buck?

Maybe it’s because we are so caught up in Agile as a idea that we don’t focus our investments on the relevant parts of Agile that matter most. Agile ain’t cheap. So why invest in those parts that don’t matter? The trick is to identify which do.

Agile ain’t cheap. So why invest in those parts that don’t matter?

Agile practices and how they are employed can support many outcomes. That said, some practices are better at supporting specific outcomes than others. For example, a shared team space tends to support the outcome of "we're all on the same team" better than the agile practice of automated testing. It's not that automated testing is a bad thing, it's just that it is not as effective in driving a one-team mindset. On the other hand, automated testing might be generally more effective at driving quality than a shared team space. (Shared team space can go a long way towards improving quality, but it's not as targeted as automated testing.) What I am driving at is that some Agile practices might matter more than others when you consider the context of the outcomes you wish to achieve.

Perhaps even more confusing is that the outcome that matters most to the organization might not be the outcome that matters most to a specific team. For example, the organization might choose improving quality as a goal, but an individual team might choose faster delivery due to a specific market opportunity. You see, context matters. Only when there is an inappropriate misalignment of goals or execution between organization and the team is there dysfunction.

So how do you consider context? Well, first step is to establish a meaningful organizational strategic improvement goal. A meaningful goal should address the greatest opportunity or risk that the organization faces.

agile-fluency-model-v2-simple-portrait-page.png

How do you check goal alignment between the organization and the team? Basically, ask the teams what matters most to them. A tool such as the Agile Fluency Diagnostic™ can generate good conversations about Agile proficiencies and their benefits and which fit best with the team's needs. (The Agile Fluency Diagnostic is a facilitated self-diagnostic that generates insights regarding default team behaviors. If you are interested in learning more about the Agile Fluency Model™ and its companion diagnostic tool, Jim is a licensed Agile Fluency Diagnostic facilitator and would be happy to answer your questions.)

How do your re-align if there is inappropriate misalignment? First, make sure that the misalignment is a problem. Organizational goals and team goals might be justifiably different. Also, the initial goal may be an invalid hypothesis. The key is to establish clear goals, execute, and then assess the impact. Check to see if you achieved the outcome that you wished. Were there unexpected and undesirable outcomes? Inspecting the outcome and adjusting course by revising the hypothesis is a basic tenet of Agile.

By focusing on the Agile practices that fit best with the outcomes that matter most we get better results. Better targeted investments generate better returns. Given that time, money, and capacity are limited, it's wise to be a good Agile investor.

Scrum Waves

 The great wave off Kanagawa - Print at the  Metropolitan Museum of Art

The great wave off Kanagawa - Print at the Metropolitan Museum of Art

I caught myself daydreaming about waves today.  What can I say, it's summertime and I have to admit that I've always been fascinated by waves, or more specifically, waves in water. It doesn't matter whether it's ripples on a pond, standing waves on a class 3 river, or rollers breaking in the surf at the beach — to me waves are mesmerizing, powerful, mysterious.

The next thing I knew, I was thinking about something Craig Larman said in a LeSS class that I attended earlier this year.

Most organizations rent Scrum rather than own it.
— Craig Larman

If you're wondering how I got from waves to Scrum and renting versus owning, it's a dream. Just stick with me. I'll explain.

Waves move through water, but are not made of water. When a wave passes, it is sort of like something happened to the water, but the water is not the wave. After the wave passes, the water hasn't changed. It's still the same water as it ever was. It is kind of like the water is renting the wave rather than owning it. It’s just a temporary thing that is just passing through.

Now if you happen to be at the beach bobbing up and down where the rollers begin their break and you decide to body surf a particularly big wave in to the shore, you might experience the thrill of the energy, speed, and dynamic nature of the wave. But after the wave has crashed on the beach and left you in its backwash, the wave is gone and the receding water is still just water. It is you, the body surfer, that is changed by the experience, not the water.

Now back to organizations renting Scrum rather than owning it. Organizations trying Scrum are often like water with Scrum simply a wave passing through. Waves come and they go. The people in the organization might get tossed and turned, but the organization stays the same. Scrum is seen as the fad that is the current wave. Soon, too, it will pass.

In my experience as a coach, Scrum works better when an organization acts like the body surfer, using Scrum as a never ending series of waves to effect positive change and having joy in the process.

Which would you rather your organization be — the water or the body surfer? Is your organization a renter or a buyer?

Scrum Values Take 1st Place

They're back! By popular demand, receiving 3 times more votes than it's nearest competitor, Scrum Values now take a prominent place in the latest update to The Scrum Guide™ (July 2016). Including the values in the Scrum Guide, in the words of Ken Schwaber, "puts the heart back into it."

The five Scrum values first made their appearance in the 2001 book, Agile Software Development with Scrum by Ken Schwaber and Mike Beedle, but somehow missed the cut in the 2010 and 2013 versions of The Scrum Guide™. While they may have seemed to have gone missing, the Scrum values have been with us all along, niggling little reminders that practices are just practices and that if you don't actually get the Agile mindset, you don't actually get Agile.

To jog our collective memories, the five Scrum values are:

  • Commitment - "doing our best"
  • Focus - "make it happen"
  • Openness - "know what is going on"
  • Respect - "as you are... for what you bring to the table"
  • Courage - "ability to take risk"†

In the 6 July 2106 webinar announcing the update to The Scrum Guide™, Ken Schwaber stated, "Scrum values are the lifeblood of Scrum." When asked why a focus on values is the significant revision to The Scrum Guide™, both Ken and Jeff Sutherland responded that the main challenge that they've seen with organizations realizing success using Scrum is a disconnect with the underlying values. "We see places where it doesn't work well, we find these values missing, or the values not really being followed completely... If your want the benefits, you adhere to the values... you embrace the values."††

We see places where it doesn’t work well, we find these values missing, or the values not really being followed completely... If your want the benefits, you adhere to the values... you embrace the values.
— Ken Schwaber

So, these things are important. 

Ten years ago I participated in a Scrum Gathering open space session in which the Scrum Values were the main point of discussion. I and the other Certified Scrum Trainers who convened the session were concerned that the values were not being given sufficient emphasis. Each of us had seen the struggles organizations had with implementing Scrum. Many of these struggles resulted in the abandonment of Scrum. We suspected that the root cause was a fundamental misunderstanding of Scrum as a set of practices rather than a set of values underpinning a framework. We believed that without the values there is no heart, no life to the practices. Each of us vowed to make the values a key point in our trainings and coaching.

  Scrum Values session at 2006 Scrum Gathering in Minneapolis. From left to right: Jim York, Geoff Watts, Bob Schatz, Tamara (Sulaiman) Runyon, Michele Sliger, Gabrielle Benefield, Chris Sterling, Bill Wake

Scrum Values session at 2006 Scrum Gathering in Minneapolis. From left to right: Jim York, Geoff Watts, Bob Schatz, Tamara (Sulaiman) Runyon, Michele Sliger, Gabrielle Benefield, Chris Sterling, Bill Wake

Living the values is not easy. But now that they part of the official definition of Scrum, they are part of the conversation. I am eager to see the difference that makes ten years from now.

Agile n+1

My Agile is better than your Agile.

Nah nah, no it's not.

Yes it is!

Is not!

Is too!

Et cetera...

To the point that eventually someone says, "Well, we're beyond Agile anyway. It's so yesterday."

To which I ask, "What part of Agile are we beyond?" If it's dogma, immutable bias, or canned solutions, I say good riddance for a' that! (with apologies to Robert Burns). They weren't consistent with Agile in any case.

Agile, in the Manifesto for Agile Software Development sense, is and always has been about a mindset. That mindset is expressed through 4 value statements and 12 principles. If you haven't checked them out in a while, go ahead and refresh your memory (http://agilemanifesto.org). I'll wait...

Good, you're back. As you may have noted, as expressed in the "Manifesto", Agile is not a methodology or a specific set of practices. It's not that simple, and we haven't even begun to get it even slightly right in most implementations. Face it. There's a lot of bad Agile out there.

So let's stop these Agile 2.0, Agile 3.0, Agile n+1.0 escalations and brash, sword-rattling posturing about abandoning Agile for the next bright shiny object and get on with it. There's still a lot of work to do.

Agile:

    think,
    
    understand,
    
    act;
    
    quickly;
    
    repeat.

Scaling — What's it all about?

Recent discussions around scaling agile remind me of the applicability of the shu ha ri model in martial art to success in agile. The path to mastery is not found in a cookbook or by taking a pill. As in the martial arts, scaling agile requires starting with the simple and progressing through practice to mastery.

Scaling agile requires starting with the simple and progressing through practice to mastery.
rock.jpg

Getting started is simple

The first step in scaling agile is easy — well, relatively easy compared to later steps. Before you contemplate scaling, first make sure you can create a single effective agile team. At a minimum, to create a single effective agile team you must start by giving the team what it needs to be successful, then listen for their emerging needs, and fulfill those needs quickly. Given the right ingredients and the right support, accomplishing this first step is almost a given barring major organizational culture issues.

But it gets harder

Step 2 gets a bit more complicated. On the surface it's pretty straightforward. Simply repeat whatever you did to create that first effective agile team. Be prepared though. It might not be so easy the second time around. Here’s why:

To achieve the first effective agile team, most organizations do things like dedicate staffing to the team; establish a team room; allocate tools, equipment, environments, and so forth to that team's exclusive use... in other words, remove all of the impediments that might otherwise get it the team's way of being an effective agile team. Then, if anything was missed and the team discovers a new impediment, swoop in and get the impediment out of the team's way.

Removing impediments for the agile team usually has the side effect of further constraining the rest of the organization.
rockwall.jpg

The problem lies in that removing impediments for the agile team usually has the side effect of further constraining the rest of the organization. For example, pulling staff to work on just one initiative, without reducing the total number of initiatives in progress, increases the workload for the remaining staff. Likewise, reserving a conference room for the exclusive use of an agile team as their "team room" takes formerly shared space out of the pool of available shared space for the rest of the organization.

So, while achieving the first team was relatively easy, getting a the second team to the same level is progressively harder. And…

We’re not done yet

Once you’ve proven that you can create a single agile team and then that you can do it again with a second team, you are still not ready to scale. You must now be able to repeat the process that you used to create your first 2 effective agile teams until you have enough teams to meet the demands of the initiative you wish to tackle.

notre dame façade.jpg

And here is where the wheels might fall off the bus. Unless something is done to balance the needs of the agile teams with the constraints of the environment in which they operate, the teams will cease to be effective agile teams — and you can’t scale effectively without the building blocks of these effective agile teams.

Scaling agile changes the organization

The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams.

The bottom line is that scaling agile requires significant organizational change. The ripple effect of the changes realized by the act of creating a single agile team grows with each additional effective agile team. The cumulative effect of these ripples gives rise to massive waves of change that can overwhelm an unprepared organization. The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams. Increasing that capacity is ultimately what agile is all about.