Drag - A little Physics with your Agile Transformation

Drag, it’s what naturally keeps everything from going faster. You can call it friction. You can call it resistance. You can call it a force (sometimes to be reckoned with). All of these are correct. But, I like using Drag. I think it puts the appropriate negative connotation on the thing that keeps us from freely increasing speed in any direction.

Now saying “You’re a real drag.” takes on a whole new meaning.

Since Drag is a natural occurrence, and we’re always looking for parallels in nature for what we are experiencing in business, we can deal with drag in similar ways to overcome similar obstacles.

Look, I’m not going to dive into explaining the analogy here. Drag, or resistance, we see it in our efforts to introduce and promote Agility. Everywhere. All the time. Every situation is unique. Thanks for understanding.

OK, now for the cool stuff.

When we are trying to get physical objects to perform or move faster, we look for ways to reduce the drag and increase the speed. Notice I didn’t say efficiency (in truth I originally wrote “and efficiency” here, but removed it later), because increasing efficiency is a different goal, and often enough, efficiency increases are side effects of getting things to move faster with fewer impediments.

How do we reduce drag? Sleeker, more aerodynamic versions of our vehicles tend to push less air and move faster. Low resistance wheel bearings tend to allow wheels to spin faster. Reinforced tires that resist shape warping at high speeds will allow land vehicles to move faster. There’s a ton of solutions to improve speed.

Where we typically see problems is that when we try to improve speed with one solution, we end up creating more drag in a different area. In doing so, we significantly increase the cost for a minimal increase in speed (or even just staying at the same speed, because so much drag was created in another area).

For instance, we can replace standard tires for reinforced tires (to reduce that shape warping thing that actually slows the tires from turning). These tires are heavier. That forces us to push the vehicle’s engine harder just to get it up to the original speed (in theory). So, we elect for a bigger engine. This makes the vehicle heavier. Which requires more work to continue pushing it down the road. We could keep doing laps on the bigger-engine-to-overcome-object-weight loop, or we could investigate this part of the analogy.

So, a colleague stopped by and reminded me that I don’t know as much about physics as I might be making myself sound. (I’ll admit, I never took a physics course - ever. But, I’m pretty darn adept.) My friend said that what I’m really talking about here is the relationship between Mass, Acceleration, Force, Work and Power. I agree with his statements, mainly because they are defined by Science and Mathematics, but also because they serve my analogy.

Here’s the straight skinny. It takes a lot of Work to get an organization (of any size) to produce faster than their current average. Physics tells us that the bigger (size and weight) the object, the more Work is needed to move it. Further, Physics will tell us that the faster we want to make that same change, the more help we are going to need to get it done.

(Literally, Force = Mass * Acceleration; Work = Force * Displacement * cos(theta); Power = Work/Time)

So, guess why so many Agile transformations have failed. Go on, try to use the concepts we know are difficult to adopt, and the laws of Physics to ‘guess’ why Agile transformations are hard. Guess?! You don’t have to guess! It’s right there.

I think I’ve been pretty easy on the reader so far. I’ll put it in words that make it over-simplistic.

Change is hard. Widespread change is really hard. Not knowing what direction to change in leads to failure. Not using the right amount of energy leads to failure. Not using the right number of change agents leads to failure. Not changing the tools we use leads to failure. Not applying the tools we have leads to failure. Not learning how to use tools leads to failure. Not learning what we are changing into leads to failure. Not changing the environment (culture) leads to failure.

I could keep going on and on here folks. But I believe if you are still reading at this point, I’m pretty much preaching to choir.

Good. So, it’s just the 2 of us now. What do we do with this information? We change.

We change our message. We change our goals. We change our direction. We change our momentum. We change.

Our message, as Business Agility/Agile Transformation/Enterprise Transformation coaches/leaders/disruptors has been pretty linear for a while. “We can help you reach your core market faster, with a higher quality product, and boost employee experience. Therefore increasing profits, market recognition and employee retention blah blah blah” Right?

Change your message. Be honest. “This ain’t gonna be easy. In fact, you probably aren’t going to give us the proper authority to create a better employee experience, which will not increase your time to market, which will not increase brand recognition or market penetration. And while you aren’t giving us that authority to help you make the changes that we would like to prove have worked elsewhere, you are going to spend literally millions of dollars paying for us consultants, changes to your facilities, and tools that you will not train your employees on. So, like I said, this ain’t gonna be easy. But, at least you might be able to sponsor an Agile event and get a reporter to write a fluff article about the company’s success with Agile.”

Change your goals. While in Lean we have the relentless pursuit for reduction of waste, we should be relentlessly seeking Agile behaviors at all levels. I’m a firm believer that if you do the mechanics of a process long enough, the process becomes part of the culture. A large part of it. If our goals are to have all levels exhibit Agile behaviors, cultural change is inevitable. That cultural change is the foundation of Agile transformation success.

Change your direction. Too many times I’ve seen the prescribed direction of Agile transformations be solely from the ground up. Meaning, we’ll try to make Scrum teams out of the people working on projects for similar or the same product right now. When we have enough Scrum teams, we’ll make a few Scrum of Scrums teams. Then there are some lofty ideas about spreading Agility throughout the organization as a whole. But, in truth nothing ever escapes that level just barely higher than teams. Why? Because we are using a model of Agile Transformation that hasn’t worked and probably never will. We need to change that barely functional transformation model at its core to encompass entire business units, entire products, entire companies. Acceptance of this change needs to be unanimous at all levels, not just at levels where your employees are pissed off that they are never listened to, and their complaints about leadership failures and inadequate or absent product visions are never heard.

Change your momentum. Where our momentum has always been “We’ve successfully converted/transformed 57 Scrum teams, and 5 full programs. Our progress over the last two quarters suggests that we will be able to transform all product development teams 2 months ahead of schedule… Blah blah blah” This isn’t true Agility. This is applying the same thinking that created enormous organizational problems with not truthfully reporting impediments in the first place. This is indicative that we are all still susceptible to hiding behind a murky veil in the name of truthful Transparency. We need to accept that we don’t know what the future holds. No one does. We need to plan for the unexpected to surprise us. We need to be able to handle the curve balls that the future throws at us, and knock them out of the park. How do we do this?

Ladies and Gentlemen! Aghast and Offended! Please assume my best of intentions by writing these things. I’m simply trying to help. I may not have easy solutions to your company’s or client’s problems. But I’ll tell you what I’ve found this year that speaks volumes to helping you find solutions to these problems (and you certainly have these problems).

Enterprise Scrum. From the guy who suggested we all use the word ‘Agile’ in the first place, Mike Beedle, please explore Enterprise Scrum. I realize ‘Scrum’ is in the name. It goes WAY beyond Scrum. It’s true Business Agility, and it holds answers to the problems you are currently having with your Agile Transformation efforts.