Keep it Fun #

Don't jump right in trying to redefine everything, and don't show up at retro one day ready to rock with "Hey team, I've redefined all of our words - isn't this great?". No, it's not great, not for your teammates. Make a suggestion - maybe start talking to one or two colleagues to start: "Wouldn't it be fun to rename this-or-that process to (insert word here)?"

You want to create an environment where everyone is looking forward to discussing words. When your team, probably jokingly, chooses a new word for a process - stick to it. Use it everywhere and, when appropriate, correct coworkers when they use the "wrong" word. This isn't something rigid I'm trying to prescribe, and in practice it's a natural way to have a bit of a laugh among colleagues.

You might have coworkers who wouldn't want a change in name - they might be too uptight, too set in their ways, or too anything else. More likely than anything, they might just not understand you or the idea. Go slow, keep it light, and emphasize the benefit of team cohesion. You'll win over even the most ardent colleagues.

Press the Advantage #

Expand that to other parts of the process, and engage everyone on your team. At the end of a retrospective, suggest a new thing to rename. Can your team take five minutes to brainstorm a new name for this or that meeting? Sure they can!

Engender a lively and friendly debate - which word is the more "agricultural" or "Star Trek" or whatever word for this concept? Which one does the whole team like? Remember that you don't need to like the words, the team does. Keep them happy.

Before too long, you'll have your own words for everything. Your team will own its own language, and language is everything. Anybody who will want to redirect your team and change its processes will need to understand your lingo now.

Entrench Your Position #

Everyone who deals with your team needs to know its lingo now. You want us to make a change to our microservice? You better say its name right! That's correct, the microservice is called "Khan" because engaging with it will entrench your team in a days-long battle deep in a dangerous nebula that will drain everyone's willpower until one of you can assert a week dominance over the other and finally destroy it (such is the world of microservice development).

Do not relent. Your language is your power. If only your team speaks this language, then you've got a special flavor and nothing else. If your team plus everyone interacting with your team speaks this language, then you've got a real power.

Inevitably, you'll have colleagues on other teams get confused or maybe frustrated at all your different words. Avoid confrontation and fall back to the old words if you need to in these contexts, but once again you'll bridge this gap if you keep it fun and take it slow. Don't create a glossary on your team's Confluence page, and even if you do don't refer folks from other teams there. Just use the new lingo in casual communication and laugh with yourself and your team when others find it strange. You'll win them all over too, with time and good nature.

Incorporate Ideas #

There will be a lot of ideas suggested. "'Circling the herd' should be X" or "A 'stampede' should be Y". Create a framework for trying ideas: agree to try ideas for a time, hold rigidly to them, then after that period of time reevaluate. Did the idea work? Keep it. Did it fail? Discard it. Something in-between? Adapt. Again: you don't need to like the ideas here. Rather, someone does, and that's the indicator of success.

When new ideas are incorporated, your process changes. Don't bill this as a process change. Instead, it's an update to a word that others don't fully understand anyway. After all, other teams are talking about your team in terms of "cattle drives" or whatever. They don't know what that is - you can tell them, and you can tell them different things months apart, just make sure you're approachable - you'll be surprised how far you can stretch your process, and somehow others will be able to work with you because humans tend to be rather adaptable. Don't worry here, just own your process. Whatever your words are, they're your team's words.

Some might yet object to new ideas because the almighty Scrum Guide doesn't contain it. You can jokingly assert that the Scrum Guide says nothing about your new word(s), but your team should be sufficiently motivated to make changes when they're considering them. If you lose a battle that's okay, you're in it for the long haul to win the war. Consensus and buying in is crucial to making fundamental changes.

Keep the Team in Control #

Inevitably, outsiders will try to push on you. They'll try to compare a Cattle Drive to a sprint or other lame things like that. Don't let them. Ensure everyone on your team is on the same page so they can answer uniformly: "A 'cattle drive' is a set time in which we can develop a small set of features that directly benefit the farmers.". They might say that that sounds like a sprint - insist it's not and redirect back to how it satisfies the customers or some corporate metric.

Always redirect to your team. Start from the position that your team owns its language; anything different is entirely foreign to you. Don't speak about Scrum, just speak from the position of your team. This is how we do things, this is the way. A random person can go pretty far in an office if they're wearing a tie and carrying a clipboard, right?

When in Doubt, Rip it Out #

Most teams, especially those coming from Scrum, have too much process. A lot of them also don't have enough communication - even teams that are mostly in-office with each other. When it comes time to reevaluate a practice that you and your team have, consider ripping it out - stop the practice. It might seem unintuitive, but a lot of things in our industry are. If a particular element of your process is getting in the way somehow, maybe just remove it and get it out of the way.

Can the problem be solved with more communication? If you're in office do you need to adopt a better culture of collaboration throughout the day? If you're distributed, do you need to encourage more ad hoc video calls? If you can reduce the barrier to communication and encourage as much communication as possible, surely you'll find no more need for meetings to "align stakeholders" or the like.

Sometimes it can be difficult to rip out a process even when it's clear it needs to go. You might have colleagues who are too familiar with this process, or maybe colleagues who think they don't want to communicate that often. This is a collaborative process, and they need to be comfortable and along for the ride too, but focus on the benefit and keep the conversations focused on what your team and its product need. You can always lead by being the change you wish to see - if more video calls are needed, start hashing your problems out over video call with your colleagues.

Drive Change From Product Quality #

We're in the industry of developing software products, so the working of the software that we deliver to our customers is always, invariably, the primary measure of our success. Our processes need to be honed to delivering valuable, functioning software, and so the primary impetus to change our processes should be from the metrics of our product's quality. You (probably) don't need two hundred different charts and graphs measuring every last metric you can think of, but your team does need to have agreed metrics and definitions of quality.

The greatest opportunity for change is when one of these metrics is underperforming. It's easy to orient the team around wanting to solve this issue, and often quality issues are largely - or at least in part - a fault of something in the process.

Involve the Customer #

The gold standard for a software engineering process is, in my experience and humble opinion, to have the customer right beside you as you develop your software. I spent the first several years of my career as a consultant developing LOB software, and I had the opportunity to develop software in this way. Not only does it eliminate a whole swath of processes just to get me customer feedback; I have the most reliable feedback and best customer experience as a result.

This is not realistically achievable for all teams though - I work in ecommerce right now and I can't imagine what it would look like to have actual customers next to me. Would they even care? Instead, we have a team that collects customer feedback and records interviews, and I can go and read or watch those whenever I need - we've developed a process that works for us and gets me as close to the customer as possible.

Always consider the customer as you develop your processes - where do they fit in and how do you and your colleagues know who they actually are? If you can realize efficiencies here, you can probably eliminate significant parts of your process.

You Won't Ever Finish #

The only constant, especially in our industry, is there are no constants. In a way this can be demoralizing; we can never create the one perfect bit of software or the one true process. But that's the environment we operate in, and we need to accommodate it. That's part of what makes Agile necessary to me, or at least that you and your team need to be empowered to develop and own their own processes.

Your process is never going to be set and it will constantly change. Keep it changing, and keep ownership over your process. To get back to my thesis here, keep the language yours. Don't let others impose their ideas or their own language on you, play uno reverse. When things need to change, this is a process to introduce new fun words or to recontextualize them to fit new problems. This process of using your own language makes it all the more fun and meaningful for teams, and will often lead to better - maybe, more agile - results.