When I was 22, I stayed at my first job for exactly nine months. It was nine months as a new developer and nine months of learning the ins and outs of an old-school corporate environment. From being required to wear a tie on Wednesdays to working at a client’s office for a week so they could physically see we were prioritizing their project — it was your quintessential corporate gig for a lowly junior dev.
Daily operations moved at a glacial pace, creeping along so slowly that it took six months for my code to reach QA. From there, the QA process consumed the rest of my tenure; ultimately, I left before my code went live. That was nine months of work just sitting there. Why? Nobody told me we were using Waterfall and I didn’t have the experience to know about agile development.
Over the next seven years, I worked my way from a dev at a successful startup to VPE of 100+ devs and eventually a co-founder and CPO — I’d become well-versed in agile development. Yet, each of my roles also taught me that everyone puts their own twist on the methodology. In reality, no two development teams’ processes are identical. Sure, teams may use Scrum or Kanban, but you better believe they’re going to adjust those methods to their liking.
So, how can development teams using all different types of methods simultaneously be successful? It’s simple: Development methodology doesn’t matter that much.
How to Revamp Your Development Methodology
There is absolutely nothing wrong with using Scrum or Kanban — but inevitably, you’ll need to adapt your method to fit your development team’s unique needs. For example, when our team went remote in 2020, we created a methodology we called asynchronous development to support how our teams worked during that time. It was a little bit of Scrum and a whole lot of our personal preferences and best practices. Since then, we’ve made changes to our own approach, building upon the concept to develop a framework and industry benchmarks for successful software delivery management.
If revamping typical development methodologies and creating one that better fits your individual needs sounds appealing, here are four steps to begin:
Step 1: Map to Your Motive.
Building software for NASA is different from building software for the average consumer. Before completely uprooting your current development methodology, determine what you want your work to achieve based on your business goals, product vision and user personas. It’s always easiest to work backward when creating your unique development method. And don’t forget to shift your approach as your business goals and user personas inevitably shift.
Step 2: Remove the Rules.
We humans love rules. But now is the time to forget all the rules you’ve ever learned about development. Once you give your team permission to stop thinking about how they should work, you’ll hear some creative, off–the–wall ideas about how they could work — and that’s when your team can build something really beautiful.
For example, agile methodology says, “Working software is the primary measure of progress.” Is this your team’s primary measure of progress, or do you have other unconventional metrics that take priority? Don’t fear disrupting what you’ve always held as the gold standard.
Step 3: Be Critical Of Your Current Processes.
Do you actually know why you’re doing what you do each day? Determine if your two-week sprints or daily standups serve your team’s best interests. If they don’t, cut them from your workflow immediately. You need to ensure your team is actually delivering software in a timely manner — not holding onto old processes that are slowing them down.
Step 4: Dig into Data.
Once you have an idea of how your new methodology should look, verify its utility by digging into the data. DORA metrics and complementary metrics like project predictability or cycle time are a great place to start. Are you more accurately mapping back to your motive while improving the efficiency and effectiveness of your team? Use data to prove it — and benchmark your success against industry standards.
Making a Better Method
Whether you’ve already put a unique spin on your development method, want to spruce it up, or you’re currently executing under a strict, non-productive development methodology, these steps provide the perfect starting place for creating a method that works for your team. As you make targeted changes and look to data for confirmation of their success, you can move the needle on your software delivery goals.
Take it from me: Revamping your current development methodology may sound scary, but you know what’s even scarier? Being stuck in development practices that keep you from reaching elite status.