Part IV. Coaching for Improvement

Trim Tabs – What They Are And How To Use Them

Buckminster Fuller, author of the ground-breaking book “Critical Path” inspired many people. He was the person who created the term “Spaceship Earth” and invented the geodesic dome, among many other things. One of his most potent concepts was when he reflected on trim tabs. Airplanes and ships use trim tabs to help move their control surfaces (flaps and rudders). They are attached to a large control surface which would otherwise be difficult to move. They look like flaps on the flaps of airplanes.

Bucky once said:

Something hit me very hard once, thinking about what one little man could do. Think of the Queen Mary. The whole ship goes by and then comes the rudder. And there’s a tiny thing at the edge of the rudder called a trim tab.

It’s a miniature rudder. Just moving the little trim tab builds a low pressure that pulls the rudder around. Takes almost no effort at all. So I said that the little individual can be a trim tab. Society thinks it’s going right by you, that it’s left you altogether. But if you’re doing dynamic things mentally, the fact is that you can just put your foot out like that and the whole big ship of state is going to go.

So I said, “call me Trim Tab.”

Bucky suggests that trim tabs are not just highly leverageable things. Instead, they work by changing the environment where a highly leverage-able thing works. This change to the environment is why trim tabs are so important. In the rudder example, the trim tab enables the rudder to work much better by changing the rudder’s environment.

Trim Tabs and coaching

Coaching is not simply going after low-hanging fruit, improving what is evident and easy; you must attend to how one thing sets up another. As people learn some practices, it sets them up to understand others. It is also essential to pay attention to the leverage a practice can exert on the environment. A simple technique can massively improve how people work. In software development, Acceptance Test-Driven Development is a relatively simple example that dramatically impacts the way people work.

Coaching simple things that set up more lessons, teaching them “what they almost already know,” and focusing on practices that can improve the environment – can significantly improve how you coach a transition.

Some Trim Tabs In Knowledge Work

The following are trimtabs in knowledge work:

MBIs are trimtabs since they provide alignment across an organization
Creating visibility of work and workflow is a trimtab since everyone can align around the work and better collaborate.
Managing work in process is a trimtab since it makes the environment better by not overloading people
Attending to testability when code is developed solves all sorts of problems and has people collaborate better
Having a development intake process is a trimtab because it lets everyone see what’s about to be worked on
Asking “how will I know I’ve done that?” when a requirement is presented improves the collaboration between devs and product owners.

Finding the Middle Ground

Years ago, Don Reinertsen and I were at a conference and watching from the back of the room at a conference. We’d sometimes make private comments about the presentations. At one point it was clear that there was a pattern of “this or that” – mostly relating to flow or iterations. Don made a funny observation “these folks have been around 1s and 0s too long.” I chuckled at this since I had had the same feeling.

This attitude is very pervasive everywhere. Notice how many times someone says something and a person hearing it will respond as if the only alternative is going to the extreme of what was mentioned. For example, if someone says “there is a degree of predictability” in development someone else may say “you can’t predict everything.”

We have choices between the extremes. A well-known bit of life coaching advice is never to make a decision when you only have two alternatives. “Decide” means to “kill off” options. But what you want to do is to take the two points and understand the dimension in which you are looking at things. Always have a third alternative, even if it seems to be worse than either of the first two you have. This third space can be in between the two you see or on a different dimension altogether.

In the Agile space, most seem to be making binary decisions. We look at Scrum as a thing and Kanban as a thing. Scrum has the cross-functional team be sacrosanct and David Anderson says “visualization not reorganization.” There is value in both. Both are proxies for what we need to do. And there is always something in the middle.

Don’t immediately go to extremes. Consider the issues being dealt with. Create options. Go a step deeper than most people do.

If someone suggests something, pause a moment before responding. Consider if there is a middle ground between what was said and what you were going to say. A small amount of thinking before responding can save a lot of time in debating. Focus on exploring, discovery, and learning.

Scott Fitzgerald once said: “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.”

Using Imposter Syndrome to Move Things Forward

A personal account by Al Shalloway

I don’t get imposter syndrome as much as I used to, but I remember when I did. And sometimes, it was pretty traumatic. Over the years, I’ve learned a few techniques that take the negative feeling of being an imposter and turns it into a positive technique. Let me explain what I learned.

Imposter syndrome is doubting your abilities and feeling like a fraud. When this happens, it’s essential to take a quick retrospection of what’s happening. Usually, imposter syndrome comes along with an internal conversation: “there’s something I need to know how to do, but I don’t know how and don’t want anyone to know.”

Consider these possibilities. What is it I don’t know? Is it something:

I can discover this by asking the client?
the client and I can discover together?
no one could know at this point, and we have to investigate?
is it something I should know now? (i.e., I am an imposter)

When one considers the first three possibilities, it’s often clear you’re not an imposter, you just need help. Remember that we are experts only in domains. You’re not an expert in the company you’re assisting. They are. I always let clients know:

I have experience and knowledge in improving organizations
They know their org better than I ever will
We need to work together to find the best solution

When you start with these agreements, imposter syndrome mostly tells you what you need to learn from the client or what you and the client need to learn together.

Managing possibility #3 above, which is very common, is more tenable when you do this. It also makes it OK that you don’t have all the answers. You provide safety for them as well for not knowing the answer.

It’s always good to have someone to confide in, especially when #4 seems true. Don’t look to see if you know it all, look to see if you’re capable of helping. Let them know that. It takes courage but builds trust. Focus on them, not you. Move forward together. If they expect you to know it all, you are doomed anyway. 🙂

The Source of Our Problems Are Not Always Where They Show Up

Many Agilists work on symptoms and not root causes. There are several ways to avoid this. The first is to understand First Principles and Mindsets/Values.

You must also find the source of the problem. It may be that the problem itself is not the source. See Using the Value Stream to Get to Root Cause With ‘Five-Whys’

It is also useful to mentally run through a checklist of common root causes. Here are a few of those:

violating universal principles such as overloading people with work
non-linear events that create waste but could have been caught with quick feedback
coupling of events that cascade
forcing people to figure things out themselves instead of teaching well-known practices/principles
the attitude that complexity means we can’t figure out what’s happening

Common challenges

There are a number of common challenges. It’s worth considering these to see how we often put our attention on the wrong thing. Here are a few to consider:

The challenge is not that we’re not done with our stories at the end of the sprint the challenge is that we’re putting too many stories into the sprint
The challenge is not that we need longer sprints so we can finish the stories in the sprint the challenge is that we need shorter sprints so we can more accurately tell how many stories will fit into the sprint.
The challenge is not that we close too many stories out at the end of the sprint the challenge is that we open too many stories at the start of the sprint.
The challenge is not that we have siloes the challenge is that siloes aren’t working together.
The challenge is not that people aren’t following the Scrum values the challenge is Scrum won’t work if people need to change their values before Scrum will work.
The challenge is not that people won’t “just do Scrum” the challenge is that “just doing Scrum” is not what people should be doing
The challenge isn’t that people “weren’t following Scrum” the challenge is expecting people to follow anything
The challenge isn’t that you don’t have time to write tests the challenge is that if you don’t write the tests before you write the code you won’t know what the code is supposed to do until after you’ve written it.
The challenge isn’t that product development is complex, the challenge is that people think they have to understand the complexity
The challenge isn’t that too many principles are confusing, the challenge is fearing that too many rules are confusing results in presenting too few.

How to Improve or Change a Practice

The Scrum Guide tells us that its roles, events, artifacts, and rules are immutable. This is fine if you want to ensure you are doing Scrum. But this can force you to use practices that aren’t appropriate for you as well. Scrum is based on the philosophy that following its roles, events, artifacts, and rules will facilitate Agile. While this is often true, doing so sometimes either cannot be done economically or at all. Cross-functional teams and being able to plan is not something that can always be accomplished. Just as important, sometimes Scrum’s roles, events, artifacts, or rules are not appropriate for a particular situation.

Amplio Development avoids this problem not by specifying practices, but by specifying objectives to be met. When a particular practice doesn’t seem appropriate or is too hard to implement, you don’t abandon it, instead, you find another one that can meet the objective, and which is both more appropriate and likely easier to implement. There is a reason (objective) for the roles, events, artifacts, and rules. While it may be advisable to change one, the new practice must achieve the original intended objective.

Making a change can be accomplished with this four-step process:

Are you having challenges with the practice because it is being done poorly? If yes, then inspect and adapt and see if you can do it better. If no, continue.
Is there something else in the organization that is causing us this problem? If yes, then see how to fix that or at least influence the fixing of it. If no, then continue.
Is the ecosystem that the team finds itself in causing the problem? That is, are people not collocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If no, continue to see if another practice that works within this ecosystem will work better (see next step).
What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

There is no definitive set of alternative practices to Scrum. You can find several in any number of places. Or you can make up your own as long as they align with first principles.

How to tell if a change is better

There is a set of underlying principles that can provide an indication if a change will improve things. This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We therefore must always be diligent and validate any change we make.

The measure to use is the Factors for effective value streams. In a nutshell, the factors for effective value streams indicate how well our value streams are working. It is based on what improves the total value manifested. Lowering this resistance usually results in more value manifested.

What if you are not sure

The factors for effective value streams will almost always give you insights on how to improve a practice. But if it doesn’t, you can always run a safe-to-fail experiment. In this case, you will try something that may or may not work, but if it doesn’t, it won’t cause many problems and can be undone easily.

But these experiments do not need to be chosen at random. It is very likely that improvements will occur by improving some factor in the factors for effective value streams. So first take a look at what you can do for any of these factors, try it, and see what happens.

So, What If It’s Not Scrum?

Of course, following the procedures may take you out of the arena of what Scrum defines. But you should be more concerned about being effective than if you’re doing Scrum.

Seeing What People Are Focusing On

It’s important to know what is motivating teams. Are they working for their own benefit or for the benefit of the organization? When working within an organization, it is not uncommon to find some teams working in a way that appears to be counterproductive to overall performance. It’s useful to discover why they are working this way. When you come across this, it’s useful to discover the reasons they are working this way. If it’s there for their own benefit instead of the benefit of the organization, it’s useful to know this. In this way, we can present them with the opportunity of doing the right thing.

An example can make this clear.

I have often gone into organizations where most teams are working with two-week sprints. Several times they have one or more teams doing three-week sprints. This causes a challenge with integration since sprints are completed at different times.

Almost without exception when I go to the teams doing three-week sprints and ask them why they are out of sync with everyone else. While I am looking for their reason, I really looking at who the reason is for. Usually, they’ll say something like “we (meaning the team) can’t finish the sprints in two weeks.” The point is when they say they are doing something that is causing other teams a problem, they are doing it for their benefit instead of for the organization.

At this point, you can start a conversation about if the savings they are achieving is costing the organization more. If it is, perhaps they need to change the way they work. It’s important to notice when teams are working towards local optimization at the cost of overall value.

<< Part III: Useful Concepts for a Professional Coach to Know

Part V: Consultant’s Corner >>