Reclaim Your Agile: The One Clever Trick Agile Coaches Don't Want You to Know
What if I told you there's one trick to being able to reshape your team's development process without your company knowing it? What if I told you that you can achieve actual Agile even though you work in a Scrum firm?
This is the one clever trick that Agile coaches don't want you to know: you can actually become an Agile team. There is actually a light at the end of this tunnel. Okay, maybe I'm being a bit fanciful. However, there is one thing that I've done on several teams now that has led them to be able to reclaim their development process and become more Agile. With this one clever trick your team can create and dictate its own process. Again, perhaps a bit fanciful, but like I said this has worked for me and it might be beneficial to you too in some way.
I've heard a lot of my colleagues say that they are skeptical of, or even dislike, Agile. In almost every single case, I think they were actually talking about Scrum. It's a forgiveable mistake, these two words are largely used interchangeably these days. However, I encourage you to read the Agile Principles and any piece of the Scrum Guide and tell me that they're the same thing. They're not. Scrum is almost entirely antithetical to Agile ("almost" in this case being around the 99.99% range), designed to satisfy corporations who aren't quite ready to give up their waterfall yet. Agile is the emphasis on early and continuous delivery of value to the customer, whose experience is the first and foremost concern, and the prescription that each engineering team must create, own, and direct its own process.
I do think that the Agile principles are the best set of principles we've come up with so far to try to understand how to best develop software, and I want to tell you about this way I've found that's helped a team or two become more truly Agile.
It started by accident actually, many years ago. I had just been hired by Dalex Livestock Solutions, a small agricultural firm, to my first properly employed position (I was an independent consultant before that). They were a full 5 people strong, and we had a meeting in Minneapolis the week I was hired to chart the future course - they wanted to invest in developing new products (that's why I was brought on). Being a 4-person company up to that point, they had never thought of their development process. However, it was clear to them that if they wanted to scale, they'd need some process. They said they wanted Scrum, and I obliged them and went along with it. There was one hiccup though - none of the non-engineers there understood a single thing that the engineers were saying about scrum. The vocabulary was a stumbling block - terms like "scrum meeting" and "sprint" were more puzzling than helpful. And funnily enough, having a former rugby captain on the team didn’t make translating these terms any easier!
In a stroke of creativity (though I can't recall exactly whose), we decided to give a fresh spin to these scrum terms. Being in the agriculture domain, we thought of using old rancher terms to describe the concepts. This caught their attention, and we ended up using these words the entire five years I was there. We didn't have "sprints", we had "cattle drives". No "sprint planning", that was a "saddle up"; "retrospectives" were "circling the herd"; instead of a "backlog" we had a "haystack"; and so on. Not one of the words we used are in the scrum guide. Over the years, when we felt we needed to make a change, we would never be bogged down with questions like "What does the Scrum guide recommend?", but instead we'd ask "Well, what actually is a 'Cattle Drive'?". After just a couple of years we had drifted away from Scrum entirely and into something of our own - something actually Agile.
My takeaway was that by redefining and taking control over our language, we were able to expand on that to take control of our process, and I think this works - in different ways - for teams of any size. Maybe this approach will work for you, maybe it won't, but it seems to me like it's a chance for many teams to be able to fight against their Scrums and make it something actually Agile, so I want to share some ideas for how you can actually do this.
Just Start With Words #
Some industries are better suited to this than others, but the central, most important, idea is to use your own words for each part of your process. I gave you some agriculture examples, but you can find examples in your own industry. Or suppose you work in insurance or banking where the domain is very dry. Do you all enjoy superheroes or Star Trek? Use Star Trek words! Find something that unites your team.
At the agricultural firm, I started with all of the words but you certainly don't have to. Start with one element or ritual and make a simple change. Given the "backlog" was the "haystack" to us, I just renamed a list on the kanban board. "Isn't that funny!" they'd exclaim. Reinforce this change with the way you speak, custom Slack emojis, or anything else to give your team a special color. When someone calls it the "backlog" errantly, call them out: "Don't you mean the 'haystack'?"
Everyone - even business - will be on board with you if you pick your first target right. They'll be impressed how your team is taking ownership over its work. If you work at a place that's too corporatish, brag about how the name change helps align the synergy of your deliveries or something of the sort.
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.
Start Changing Things #
Now that you have real power, use it. At retrospectives, stop asking what the right name for something is - you've already named everything. Start asking "What actually is a 'Cattle Drive'?".
At first, your teammates will be confused - there's no longer a Scrum guide to fall back on! Nobody knows what a 'Cattle Drive' is - it's not in the Scrum guide, it's not in any guide! This is when the real thinking comes out. I guarantee, buried deep in your team is a wealth of knowledge, and by removing the onerous cap of the Scrum guide you'll discover it.
The hope at this point is that by having divorced your team from the language of Scrum, you can change the process by talking about your new words instead of talking about process. This is another area that can't be rushed, and you might be surprised by what the first candidate is. Before too long, you'll surely have a sprint (or, perhaps a cattle drive) where everyone on the team has been impeded by a particular process. Motivate a conversation here about this process, but use your new word and avoid talking about process.
Keeping your team entrenched in the new language keeps the team away from considering "what does the Scrum Guide say about this process?" because the Scrum Guide says nothing about haystacks or saddle ups. Make the first process change on a process that everyone agrees needs to be changed when they are all agreeing that it needs to be. After the first change, others will be easier.
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?
Become Agile #
You now own your own processes, and your team has a regular way of changing its process to respond to the environment it's in. You're now Agile, but remember it, keep it up, and don't relent.
When your process needs to change, change it but stick to your team's vocabulary. Deliver customer value early and often, and find ways to get your team as close to the customer as you can. If your engineers can regularly interact directly with the customer, that's the best. You can always fall back on the Agile manifesto and principles to give some guidance on how you might approach sharpening your process, but remember that these are only a guide and your team needs to discover, implement, and own its own process and methodologies for its own environment.
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.
Conclusion #
There are no silver bullets, but this process has worked incredibly well for me, and it might for you as well. At the heart of it, the idea is to get your team to own its own language and exploit that as an advantage to have its own process. Confuse your superiors with funny words and slip your own process in below that.
You might also think that you don't actually want your team to be 'Agile'. If you feel that way, are you actually talking about Scrum? Agile and Scrum are very different. Read the Agile Manifesto then the Scrum Guide. Do these seem like they're saying the same thing? They're not - Scrum is a completely disingenuous bastardization of Agile for the benefit of corporate environments. Agile, on the other hand, is a loose set of guides that don't prescribe a specific system - they want to empower your team to develop its own system.
That's what I want to get at with this article. I want to give you one way, doubtlessly among many ways, to reclaim your process. Reclaim your 'Agile' and form something that works for you. I do think that the Agile principles must be followed: deliver value early and often, stay close to your customers, and always reevaluate.
On top of all of this, keep learning and keep your mind open to new ideas in process. There's many different ideas - some good, many iffy - about how to develop software. Ultimately, the best process for your team isn't written anywhere. Only by trying new things out can your team find a process that works the best.
I hope all of your future cattle drives - or whatever word you settle on - are filled with productive enhancements for the users' benefit.