No Rules Agility: How to Operate in the Ri

Let’s talk about Shu Ha Ri.

For any unfamiliar, it’s a term borrowed from martial arts, and it’s meant to describe the stages of learning to achieve mastery. First, we must learn and apply the rules without deviation (Shu). As we progress, we break the rules or perhaps innovate on the rules to improve ourselves (Ha). Finally, in Ri we transcend the rules, create our own, or potentially blaze a trail no other has before travelled.

The concept is solid, but I don’t much care of it. Why? Many believe they’ve achieved Ha or RI before they’ve truly mastered the fundamentals. With no sensei and given that Shu Ha Ri is mostly ethereal, who can say otherwise? But I digress. I’m not here to talk about the validity of Shu Ha Ri. Instead, I wanted to talk specifically about Ri in the context of supporting agile teams.

If many have transcended the rules, we can assume they’re less interested in implementing Scrum. Or LeSS. Or [insert agile framework here]. They’re more interested in solving important problems in collaboration with their teams. And if that’s true, how? What are they asking and what steps are they taking to determine a course of action?

As a self-proclaimed Ri, let’s dig into how I navigate through no rules agility.

Get Obsessively Curious.

Ever since I was a child, I was wildly curious how things are connected together. With people, this is doubly true and doubly challenging. So the first step is simple. Get curious.

Ask tons of questions to understand the situation, and don’t just ask the obvious people. Talk with the naysayers, the disagreeables, and the quiet ones. Ask the Scrum zealots. Speak with product managers, with team members, project managers, and anyone else with an opinion and a perspective.

And when we think we’ve run out of questions, pause and be silent. The person we’re speaking to will likely provide more context and color that then leads to even more questions. For example, let’s say a team wants to talk about their backlog, here’s a small sample of questions that come to mind:

• When team members are trying to understand a piece of work, what kinds of questions do they typically ask?
• Where are the edges of the why, what, and how in the backlog?
• When the team gets stuck while talking about a piece of work, what do they do?
• How much of the backlog is ready for team consumption? If they stopped curating it today, how far would they get before running out of work?
• How much uncertainty is the team willing to bear before saying an item is ready to be worked?
• On average, how long does it take to size a single item?
• Have they tried models where they don’t size the work at all? How did that play out?
• How often does the backlog get reprioritized?
• On average, how old is an item in the backlog?
• What do they do with items that sit on the backlog for several months?
• Are product managers/owners providing teams solutions or problems in their backlog?

Calculate the Economics.

In every organization, there’s always an overabundance of problems to solve. While this (mostly) helps us remain gainfully employed, it’s important for us to determine where to invest. It starts with a cost-benefit analysis, and what consultant doesn’t like a 2 by 2 matrix so here’s mine.

Let’s highlight a few things from the matrix above:

• Where possible, eliminate things that have little to no benefit. However, eliminating things is often met with resistance. John Cutler sums it up well in his article Subtractive and Additive Change.
• Evangelize the bright spots of high benefit/low cost items. Borrow knowledge from here and apply to where we’re investing and give the org a pat on the back. Providing sincere praise garners trust, collaboration, and transparency.
• As much as possible, invest in the high benefit/high cost items, whether it be to lower the cost or heighten the benefit. Or both.
• Why the “Ignore (Probably)?” There may be some low-hanging fruit here worth pruning. If an easy win will generate confidence in our skills or yield good will, it may be worth a small investment.

However, that’s not enough. We should also ask one more question. For the high cost items, what’s the opportunity cost? What are the things that we’re not making time for because we’re making time for other things?

For example, I find product managers are often over tasked. Ask one or two to draft all the activities they’re responsible for, ask them to stack rank it, then ask them to draw a line showing all the things they rarely or never find time for. What makes the items at the top of the list so valuable to them? What activities aren’t listed that potentially should be?

Adjust What’s Optimized.

Until now, we’ve been focused exclusively on the problem space, but now it’s time to pivot into solutioning. Know though that we’re not doing this in isolation but in concert with our teams and leaders.

The below comes from a piece I put together a piece several years ago that I often refer back to. In it is a single image that strips away all the buzz words and sums up what I believe is the heart of agility. It’s framed similar to the manifesto saying that while there is value to the things on the right, there’s more value to the things on the left. Said another way, if I can get both, I’ll take both. If I have to choose, I’ll optimize for the left side of the equation.

So how do we typically do this math? We talk with the team. What is it that our current way of working is optimizing for? Is this what we want or would be like to optimize differently? In the long-term, what do we want to be thinking and doing that’s different from today? Also, it’s not that we weigh all these variables with every decisions. Pick a few that matter and that fit the context.

Let’s imagine we’re looking at their backlog again. It could look something like this:

• If a team is quickly estimating stories with little conversation, they may be valuing getting the meeting over quickly (efficiency) instead of making the implicit explicit (effectiveness), which in my opinion is the true value of estimation.
• If a team has months of backlog curated or the priorities in their backlog rarely change, they may not be embracing a mindset of experimentation by validating their work with their users. Instead they may be assuming their theories are correct, validation be damned.
• If a product managers/owners are giving solutions to implement rather than problems to solve, perhaps they value task completion (just get it done!) over knowledge creation (let’s talk about the pain our users are feeling).

We do this optimization to set a direction and to shift mindsets.

Experimentation over Theorycraft.

Here we take that directionality we created above and find a few small tasks to help us validate our thinking. As a team, let’s think up some small and immediately actionable experiments that might get us one tiny step closer to where we want to be. We’ll then pick one (or two) of those ideas, try them on, and use what we learn to course correct. For more information on how this looks and feels, check out this post.

Change is a process, not an event.

Revisiting the backlog example, here’s a two hypothetical examples:

• The team wants to be more involved in solving the problems so for this one epic and for two sprints, Bill (team member) will meet with Ann (product owner) to help shape stories differently. If it’s working, we’ll try it with more epics. If it sucks, we’ll talk about why and figure out what to try next.
• We’ve worked together for a long time, and we’ve seen that the number of stories in a sprint is a better predictor to how much we can get done than the number of story points. For the next three sprints, we’re not estimating the work and instead determining how much we can complete by number of stories instead of story points. On other side, we’ll talk about what we learned.

This four step process has served me well for no rules agility. Give it a try. If it works well for you, let me know. But if it doesn’t, let me know that too. I’ll be curious where it falls over for you.

That’s it for today. See you all again soon. And if you’re curious, that is me in the featured image. Years ago, I used to train and teach several martial arts, and I was demonstrating to my class that with the proper technique a 160 pound person (me) could throw someone more than 100 pounds heavier. I may or may not–but definitely did–have pulled a muscle that night. Good times.

---