Where do you sit as your Agile team's designated business expert?

Where do you sit as your Agile team's designated business expert?

"You're doing it wrong!"

If I had a dollar for every time I've heard an overbearing Scrum Master, misguided "Agile expert" or overzealous individual claiming to be an Agile coach say these or similar words, I'd be a rich man indeed.

What is right or wrong is often situational in Agile. The Scrum Master who insists that you must sit with the team may or may not be correct as to where you would be most effective. The idea that there is one and only one correct answer to the question of where you should sit is too simplistic.

Read More

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 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.


† Select quotes from the 6 July 2016 Webinar, Scrum Guide Refresh

†† ibid. Ken Schwaber

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.