Simple Rules!

"But, it's not on the list."

For years, I started a facilitation workshop by having the students come up with norms for the class. My intent was to both create ground rules for the session as well as have the students practice an activity that they would likely use themselves as facilitators in the future. The facilitation technique for this exercise varied from class to class, but the output of the exercise was usually a flip chart page with a list of do's and don'ts which we would then display prominently somewhere in the classroom.

Even with the ground rules for the class thus established, I found over time that it was not unusual for someone to do something during the class that, while not technically against the letter of norms, certainly violated the spirit... and further, it was not unusual for the someone, when called out for their behavior, to point at the poster the group had created and say, "But, it's not on the list!" From this individual's perspective, the fact that their behavior was not specifically prohibited by the norms captured on the flip chart page somehow made the behavior acceptable, no matter how disruptive the behavior might be.

On the positive side, the disruption gave the whole class an opportunity to practice their facilitation skills in another exercise, a retrospective, the intent of which was to improve the class norms — two birds with one stone, you might say. However, what also became clear over time was that no matter how valuable the activities of facilitating team norms creation and running retrospectives might be, no list, no matter how exhaustive, could possibly cover all undesirable behaviors of ingenious disrupters.

What to do?

For inspiration, I turned to something a wise man, Dee Hock, said:

"Complex rules and regulations give rise to simple and stupid behavior." 

Dee Hock's words put the class norms poster in a new light. Instead of growing the list of items on the poster, what if we considered a new approach? 

For this new approach, I drew on additional wisdom from Dee Hock:

"Simple clear purpose and principles give rise to complex and intelligent behavior."

What if instead of a long list of norms — rules and regulations, you might say — we came up with a simple set of principles that along with our class purpose statement would help guide us through the workshop?

Participate!

The first attempt at simplifying the class norms was a bit extreme. In the next class, the students decided on one principle as their norm: Participate! This one principle could inform individual choices as varied as arrival and departure times and when to return from breaks to how to use technology such as cell phones and computers during the class. We also found that the Participate! principle affected how students experienced the class. In addition to being physically present, the students tended to be more intellectually and emotionally present, as well.

This change worked so well that I decided in the next class to replace the ground rules poster with a simple poster on which was written the one word "Participate!" The team norms facilitation exercise shifted to one in which we discussed the difference between principles and rules and how using a principles approach might impact the work we did in the class. Confident that we were on to something, I decided to adopt this new approach to the class norms exercise. The principles poster with it's one word "Participate!" became a standard going forward.

For a few classes all went well... until one class, in which we learned that not all participation is desirable.  During this class, a difference of opinion between two students resulted in some unpleasant things being said by both parties. A resulting uncomfortable moment of silence was broken by one student congenially remarking, "Well... I'm not sure that's what we meant by "Participate!" To their credit, our verbal combatants chuckled and one, with remarkable humility, asked that we try out "that retrospective thing" to improve the class norms.

Respect!

With Dee Hock's advice in mind, the class engaged in a retrospective to decide what to do. After a few minutes of discussion in which having and expressing different opinions was upheld as desired, the group decided that the interactions in the class could be made more effective by adding the word "Respect" to our current one word principles list. Respect would then inform the act of participation. We made this change and the class was a great success. To this day, these two principles serve as simple rules for all my classes and workshops.

What are your "simple rules"?

Look around your team environment. How do existing rules and regulations impact your team's interactions? What principles are present? Are they explicit? How do these principles inform your team's interactions? Can "simple rules" make a positive impact on your team's effectiveness?

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.

 

The Elusive Product Owner

elusivePO.jpg

Every Scrum Team needs a Product Owner. You know you need one — a good one preferably. Where are you going to get one? Why are they so hard to find?

To start, recognize that the bar for a Product Owner is pretty high. The Scrum Guide™ says "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team... the sole person responsible for managing the Product Backlog."† These simple words convey a lot of responsibility. Let's consider the implications and how these implications might help you identify your best candidate for the role.

"Responsible for maximizing the value of the product"

Hmmm... when does the responsibility for maximizing the value of the product begin and end? The Scrum Guide™ does not explicitly tell us, but there are some pretty clear hints. For example, the statement that "The Product Owner is the sole person responsible for managing the Product Backlog."† combined with a later statement that "As long as a product exists, its Product Backlog also exists."†† imply that the Product Owner's tenure of responsibility for maximizing the value of the product coincides with the existence of the product.

How long is that for your product? Some products have lifespans that span decades, or longer. The Product Owner is not maximizing value for a segment of the product's lifecycle, but rather for its entire life. Is your Product Owner going to be around that long? If not, perhaps we're looking for a Level 5 leader to fill the Product Owner role — someone who builds enduring success even when they are no longer present.

In a different dimension, where does the responsibility for maximizing the value of the product begin and end? To explore this dimension, let's look at the second part of The Scrum Guide™'s statement.

"Maximizing the work of the Development Team"

In addition to maximizing the value of the product over its life, the Product Owner is responsible for "maximizing the value of the work of the Development Team." Yes, a Product Owner supports the Development Team, helping them be the best that they can be, but this responsibility extends beyond the Development Team.

Keep in mind that the Development Team does not exist in a vacuum. The Development Team is a single element on a potentially complex value stream. The work of the Development Team creates no value if the output of that work is blocked by other elements on the value stream.

So, if the Product Owner is responsible for maximizing the work of the Development Team, by extension, the Product Owner is responsible for the whole value stream. This holistic perspective implies that we're looking for someone who sees the big picture as well as the discrete elements that constitute the whole.

A VERY big responsibility

Recognizing that the Product Owner is responsible for maximizing the value of the product and the work of the Development Team leads us to the inescapable conclusion that the Product Owner is responsible for maximizing the product value in both time and space. The time extends over the life of the product. The space extends across the value stream. Little wonder the role is so difficult to fill and execute well.

Based on these implications, who do you believe is best suited to fill the Product Owner role on your Scrum Team? What can you do to help them be the best they can be?


† Schwaber, Ken and Sutherland, Jeff. "The Scrum Guide™". Scrum Guides. http://www.scrumguides.org. 22 March 2016, p.5

†† ibid. p.13