When exploring a word, I often use the definition according to Merriam-Webster. It’s nice to start at the original intent of a word and step forward.

And for the first time in forever, I couldn’t locate a word.

I found refactoring on Wikipedia when referencing its combination with software. Developers know how to use the word on a daily basis, but outside of that the word doesn’t have much utility.

“Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.”

At this year’s Agile Coach Camp, the word refactor got in my head like a freaking earworm by soon-to-be father Amitai. Leave it to an escaped developer to infect you with the idea. That’s meant with all the love and affection in the world.

I’ve never written a line of code in my life other than a few “Hello Worlds.” I understand the concept of refactoring things from time to time though. Words are written with the best of intentions at the time. With as up-to-date information available.

We write, and magic happens.

That’s what most of us have thought about the Manifesto and Principles for 16 years. It works because it’s simple and basic, and by all accounts still holds up today. I’ve even blogged about why it’s so important to memorize as much of it as you can.

Of course, writing often doesn’t sit alone in perpetuity. Things added, like new features. Amazing minds have riffed on the Manifesto and Principles almost immediately. Frameworks created. Certs multiplied like rabbits. Warring factions emerged inside our community wanting their voice to be louder.

It’s a lot for me to process, and I can’t be the only one.

With all this legacy “code” in the community, it’s time to consider a targeted refactor of capital-A Agile. This activity includes many many things. We can revisit the original intent of Snowbird. Find fresh takes. Even remove pieces altogether.

We could all try something as a community. What if we made a list of things about Agile we strongly believe and challenge them? Not confirm in a book, video, or blog post and move on.

Challenge it. Find ways where it might not apply.

This does a few things. First, it helps us keep a healthy sense of humor about beliefs. It doesn’t matter who’s right. Second, it encourages us to reach out and pair more on topics. We can’t get better in vacuums. Finally, realize Agile isn’t a competition. There isn’t a high score in Agile, so let’s stop keeping it.

Without further ado, here are a few ideas I chose to challenge.

Doing things “by the book” doesn’t work.

I had a great conversation about Scrum with Stephanie (Stacy) Ockerman at Agile and Beyond. As a trainer, she’s not only coached teams in the application of Scrum. She’s taught it many times. I don’t doubt her ability to convey the material. I’ll be a product owner on her team any day if the opportunity arises.

She bemoaned some of the challenges with scaling frameworks and Scrum evangelism. “If you do Scrum right, I’ve never seen it not work,” she said.

While I didn’t admit it, in my head I disagreed because I had seen it not work before. Granted, I could have not been “doing it right” by her estimations. She’s also open to other frameworks, but if you’re going to call it Scrum there’s an easy guide to follow.

Conversations often cause a crisis of conscience with me. I have often followed the guide verbatim, but if I challenge that notion I didn’t. A healthy streak of rebellion exists in me, so I like deviating from “the book”. After all, one of my mentors once said to “make recommendations, not rules.”

I shouldn’t thumb my nose in the face of authority. We should all calm down for once and try things as its taught or written some. We can always inspect and adapt later.

The business of certifications will ruin our industry.

You either love certs or don’t. Certification training and the organizations responsible for them always stir a debate. Something is deep rooted in us about the need for more and more letters after our names on LinkedIn.

I always get a little sad about where our industry sits with more and more certs rolling out every year. We don’t have just Scrum Masters and Product Owners anymore. There are many types of them, and many levels. Certifications to teach certifications to others. On leadership. The countless scaling organizations. Scaling organizations now compete with regular certifying bodies, which has started a war.

Writing that paragraph made me nauseous.

It’s high-school bickering and will turn our industry into a house of cards. That brings me great trepidation.

Yet, I know that if we didn’t have certifying bodies there’s no way we wouldn’t unify the proper fundamentals. How will I even know if I’m doing things well or making them up as I go? Would I want teams led by others with that attitude?

It’s important to have a healthy sense of humor about our industry and all the money made off training. That said, I wouldn’t be here without the three I have and more certifications are coming. It’s okay to keep going after them.

Coaching is as relative as “being Agile”.

There was a discussion at Coach Camp about coaches needing some supervision. When I brought up pairing as a better model than mentor-mentee, it met resistance. The look on my face was visible to many and I left dejected.

Checking my LinkedIn profile reveals I have not been coaching that long. I don’t have decades of leading teams like colleagues. That leads to a decent inferiority complex.

The idea of being “supervised” angers me. It suggests someone is more of an expert in Agile or coaching than me. I’m slightly competitive. Or just competitive.

Honest reflection reveals I am never a finished product, though. We all bring our own flavor to the practice. That means we should teach each other a thing or two. Might mean an agile practice I’m needing to polish, or a coaching stance I’ve not practiced.

The difference between supervision and pairing is not as vast as I am willing to admit at times. I can learn from the experience of others. Who cares if I call it supervision or pairing?

Now it’s your turn.

As my friend Bob Galen says, “let’s stop yakking, and start doing.” Rather than sticking to our assumptions, I’d like to ask us all to do this exercise. Move outside echo chambers for the greater good.

Ask this. Can we enable the right people to make the right things, the way that makes the most sense in that moment? Closer we get to that ideal, the more we’re heading in the right direction.

We can’t make Agile better if we can’t look inward and challenge things we hold most dear.