In the 2008 Summer Olympics in Beijing, there were 25 world records set in swimming competitions. If that sounds like a lot to be broken in a single year of events, it’s because it was at the time. Of those records set, 23 of them were broken wearing full-body tech suits according to Swimming World Magazine.
“With ultrasonically welded seams and a zipper, the suit compressed a swimmer’s body into a streamlined tube that sometimes trapped air, adding buoyancy and reducing drag. Through the use of polyurethane material, the suit was designed to also make swimmers more hydrodynamic.”
Lianne McCluskey, swimmingworldmagazine.com
Swimmers weren’t accomplishing these feats because they kicked harder or flapped their arms quicker. Performance-enhancing drugs weren’t in the picture by all accounts. Swimming times don’t go down because you move with more force. The true key to success is in the form of reducing friction in how you move through the water.
That’s the reason for all the records in that one Olympic event. The tech suits allowed drag to be reduced at such a large amount that times fell faster than they could be posted. The suits were banned a year later, and haven’t been allowed in the sport since.
I think you see where this is heading.
The notion of transformation has become very frustrating for me over the past few years, and I know I’m not the only one. The reason agile transformations struggle is no different in the 16th version of State of Agile than the first (for the most part). Leadership isn’t engaged or understands the benefits of the manifesto. Training isn’t utilized well, business and IT aren’t besties, and teams are disconnected from all the fun.
We keep trying to accentuate the benefits of small teams and organized backlogs of value. We encourage leaders to build psychologically safe environments, combine their backlogs into one, and get leadership in the room when we plan together if that will help. Invest in more training, because more learning equals better. Sometimes, if we are lucky, we include technology innovation to automate more of the process. With more orgs than we can admit, though, we just think better processes can fix it all.
It just doesn’t work as much as it should.
A recent podcast by Shankar Vedantam crystallized why many of us have been focused on the wrong thing with transformations. He interviewed organization psychologist Loran Nordgren about how obstacles are overcome. Many times, leaders will try to add a lot of good to the scale of the problems facing them. Perks in all forms tend to make things feel fun at the moment, but Nordgren states that adding more gunpowder to a bullet doesn’t make it fly farther.
Gravity and wind resistance are powerful forces. Yes, you can make bigger and more powerful engines to help planes fly. A supersonic aircraft can go infinitely faster than a hang glider. There’s a cost to add to the mix. In Top Gun: Maverick, Tom Cruise was able to pass Mach 10 in a plane. When he got out of the cockpit, though, he had no idea where he was in the world.
Most organizations act like the goal of any transformation is Mach 10, when all they needed was to get past rush hour traffic. This leads me to the conclusion that adding more fuel to a challenging situation may be another log in a fire. Just makes it bigger.
After a few dog walks, I came up with some scenarios where removing friction might be a better transformational tool than adding fuel.
The friction of uniformity
One of humanity’s greatest traits has become one of its supposed weaknesses. In group situations, we organize under a set of ideals. Some are more successful than others. Frederick Taylor still looms large over professional management, so we think all processes can be easily repeated. The successful teams are copied, and the less successful ones are put into the cloning machine.
Thought leaders have tried creating simple solutions for this. Stop me if you’ve heard these before:
- If we just tried this framework I’m able to train…
- With this set of principles, I learned in a webinar…
- From a software solution that I just got certified in…
It’s not unreasonable to think that successful things could be repeated across organizations. Ephemeral ideas like mutual respect and accountability can be repeated because leadership can easily enforce them. It’s not because those and many others are rigid practices. A sense of welcoming new ideas can be implemented in a multitude of ways, giving leaders room to create their own green fields.
The challenge in implementing rigid processes into teams is as simple as the idea is, there are always edge cases.
Creating a sense of uniformity in teams causes friction from the uniqueness of each person. It is rational to ask teams to gather for 15 minutes or less every working day except when you consider the times when it’s not optimal. Different team members may not benefit others if their work is specialized and doesn’t touch others’ code. Distributed teams of a large size might not be able to finish in that time box. Individual conflicts may make it difficult to agree on when to gather.
Frameworks of all kinds bring rigidity that loses the perspective of the situation. The more rules there are to follow, the more impossible the task of uniformity.
Most agile frameworks claim to get rid of meetings, yet when the practitioner arrives on site they don’t speak of removing meetings. We just add ours on top of the existing meetings in a person’s day. By trying to all work the same way, we are just adding extra boxes to check in your ways of working. Instead of all trying to be the same, how can we look at the excess in our programs to craft a unique process for each group?
Finding ways to embrace the unique aspects of humanity and our work might be the only uniform thing in every organization.
While there are group activities that many organizations can utilize in their processes, I tend to think of transformation as an individual activity. This is amazing because if you approach each individual as a clean slate, you can see how we become more of a collective group together.
The friction of involvement (or the lack thereof)
Trust me, I’ve been there before. Leader after leader has asked for playbooks. Checklists for how to make a date. Plans and calendars for how to improve. Most recently, I was criticized for not having a transformation roadmap quick enough.
People want improvements in easy, bite-sized chunks of work as if transformation is a conveyor belt. I get why that’s become the standard. With all of the challenges of running an organization, there is a struggle in where to focus.
Your org could be 150 or 15,000. The problems are no different with the exception of scale.
Yet we welcome transformation consultants into our orbit with the idea they will have the secret sauce. This one org that’s done it here, there, and everywhere. They have the slides and/or formula to fix us. If that were the case I would have changed the focus of my career to crafting the perfect sales decks.
The friction is thinking change comes when you decide for them. I’ve heard leaders say you can’t always have everyone in the room to make decisions. While I agree on that point, getting consent to follow the decisions isn’t as simple as just telling them what change is happening.
“You cannot reason a person out of a position he did not reason himself into in the first place.”
Jonathan Swift
Organizations improve when leaders make something special and unique with the outside experts they hire. They combine true expertise with their knowledge of how things work in their shop. They also value the voices of knowledge workers and involve them in the solution. The adage of co-creation still holds true even if Frederick Taylor didn’t include it in his original paper.
What do we say when leaders just want a simple checklist?
It can be as simple as asking for more clarity into what we are solving. If it’s the entire cornucopia of their issues, we can remind them that simple solutions are for simple problems. We can’t fit square, complex problems into a round-agile hole. Might be good to solve problems one at a time and when the solutions conflict with one another, we smile and say, “people, am I right?”
This stuff isn’t easy and we should stop treating it as such. Breaking things down and resolving dependencies aren’t just for software solutions. It works with people as well.
The friction of predictability (this will annoy some of you)
I’m just gonna rip the band-aid off. One of the biggest fallacies in teams is the notion we can become more predictable, especially when it comes to delivery. When you approach me at a conference to tell me what an idiot I am, please just be nice about it.
The number of advocates for estimation might tell you a different story. If you create solid teams, and give them room to learn better ways of working…they should become more predictable over time. Not only will their productivity increase, but they will become more adept at telling you more accurate estimates of how much can be done. I’ve taught this in more training and workshops than you could possibly imagine.
I guess my hypocrisy has just eaten me alive from the inside.
The larger the organization, the more predictability is desired from teams. Funding decisions are given with the understanding you will do your best to not go over budget and deliver them on time. I can still hear the words of a business leader (many, many clients ago) who once said, “I would trust IT more if they could just tell me how much what I want cost when it will be done, and never be wrong about it.”
They knew exactly how that sounded, for the record. My biggest issue was they didn’t care either.
Teams aren’t held together long enough to develop predictability, and the exceptions to that are rarer than you would think. They also don’t have work that’s so repetitive they can know precisely how long a task will take in the future. There are simply too many variables to consider for them. We will also never stop being optimistic about how much work can be done in an allotted timeframe.
The worst part is, the more predictability is emphasized by leaders, the more we will cover up our inability to do so with a myriad of games.
Story points are gamed to show improvements in delivery. Work isn’t always logged because the team didn’t want to appear to have a lot of backlog instability. Defects are cataloged in all manner of methods to either seem more stable or to show how out of sorts the software can be. The business could change priority so often that teams never get a chance to get into a rhythm. Technical solutions that would enable the smoother promotion of code are deprioritized because there’s a new feature someone wants more.
This friction is driven by solid business practices, yet ignores the human aspect of what we are building. There is nothing wrong with me wanting a team to be correct when they commit to delivering a number of user stories in a sprint. I can’t fund the headcount in my org if I can never tell the business when something might be delivered. Bonuses can’t be handed out if we don’t get enough done.
Leaders have to create healthy boundaries that will allow for teams to be their most predictable. By saying “not yet” to our partners when a new fire erupts. To see the larger picture in the system. If we can’t remove a large amount of the points of friction in delivery, then we shouldn’t emphasize how important it is for us to get more predictable.
We should just focus on getting as much done as possible, and add more fuel to our flexibility in expectations.
The next time, consider what you could be taking away from the situation instead of adding more fuel.
This is one of those topics that could span several happy hours. My entire week in Orlando this year could be devoted to discussing your points of friction and I still wouldn’t have enough time. I’m curious what’s been cropping up in your world recently?
What are your biggest points of friction?
Chris Murman 