Going Rogue 😈

TL;DR

Devs should “go rogue” often and not feel bad about it.

What does “going rogue” mean?

Going rogue means you are working on something not tracked by Jira in the current sprint.

Isn’t going rogue bad?

It depends.

It’s bad if you’re missing deadlines or slacking off.

It’s good if you’re improving the DevEx, helping a teammate, learning new things, writing a blog post (like this one ), etc.

Why are devs scared to go rogue?

Speaking for myself, and maybe I’m a little too simple-minded here, but not having a Jira ticket in my in-progress column of our team’s sprint board makes me feel like I’m being viewed as slacking off. I’m worried my manager, TPM, PM, coworkers, etc. are silently judging me and thinking I’m not working hard. But the truth is: “I work hard every mother trucking daaaaayyyyeeeeaaaeeeaaaeeeaaa. I work hard I work haaaaaard!”

It’s a little scary because as an agile/scrum team we do a lot of sprint planning, refinement, prioritization, etc to ensure we’re working on the most important/urgent stuff in the current sprint. Going rogue is essentially bypassing all that planning work and saying “na, imma do my own thing.“

The benefits of going rogue

I’ve been a long-time advocate for documenting all dev processes. A clearly documented process reduces confusion and helps us improve the process over time. However, processes (like our traditional processes around scrum, agile, jira, etc) can often slow us down. Sometimes, instead of writing up a ticket, we should just go rogue and get sh** done.

Going rogue offers the following benefits:

1. Speed. No overhead costs, just go.
2. Autonomy. You control your own destiny and do it with as much creativity as you want.
3. Fun. You can do something that you enjoy doing (as long as it is at least semi-related to your job ).

Note: It’s possible for teams to systematize “going rogue“ into the development process itself. For example, I’ve seen some teams do “innovation days“ where they spent an entire day each sprint working on whatever they want .

How does this relate to tech debt?

FACT: No one fully understands the pain of a bad developer experience except the devs themselves.

Depending on where you work, most managers are non-technical –which means they will have a bias towards user-facing features and bug fixes when they determine what should be in the sprint. And those are important things! But tech debt causing poor DevEx often gets unwisely deprioritized because of this.

I’m not suggesting anarchy.

We should still work with our managers and create tickets that go through a prioritization process. Especially if it’s a big task, getting buy-in from management is important. And to do that you’ll need to clearly communicate the value-add of your proposed work up the chain of command. For example, you might say:

• “It will reduce the cycle-time of our frontend tickets by 2 days!”
• “It will speed up our client onboarding process by 3 weeks!“
• “It will increase the quality of our codebase and reduce the number of potential bugs by 25 percent!“

But coming up with a list of earnest business benefits takes a lot of effort and time.

If it’s a small thing, we should encourage ourselves to just go rogue and get er’ done.
If it will improve your life in terms of a better DevEx, just do it.

But what about our business goals?

Yep, those are important. Especially for a startup company still trying to achieve product-market fit. We can’t just pause all client work. But we can and should make space for developer-led initiatives as well.

To fix our tech debt and DevEx problems, we need both top-down initiatives (from traditional agile processes) AND grassroots initiatives (from devs going rogue).

Caveats

1. This only works if you and your team have already built a solid foundation of trust. If trust is lacking, then going rogue will only lead to more trust issues and a completely dysfunctional team.
2. If you’re new to your team, you should probably get familiar with the current processes before going off the rails.

Conclusion

Developers:
Go rogue more often. Use your creativity. Be your badass self.

Managers and C-suite:
Prioritize developer-led initiatives (like fixing tech debt and developer experience problems) and give space for devs to choose their own destiny.