I worked as a developer using Waterfall for exactly 9 months. I was 22 years old, and it was my first programmer job and first corporate environment.
This place was old school. Like suit-wearing, personal-cubicle-type old school. Our CEO would hold all-hands meetings where everyone was required to stand the whole time, and he would call people up to give speeches at random because he believed everyone should be good at public speaking.
At one offsite event, the CEO designated me as the company’s “Complaint Manager.” During the 4-day event, employees were directed to give me their complaints. Of course, my friends dropped anonymous, hilarious complaints because they knew that, at the end of each day, I was going to be called up to the stage to repeat back all of the complaints. What?!? Super old school.
One time, I was sent to work at a client’s office for a week, just so they could visibly see my team working on their project. And I mean that in the most literal sense. We didn’t have any meetings or recent project updates, they just wanted to make sure we were actually working.
I never saw a single line of my code in production during the 9 months I spent working there. I actually remember learning that my project was finally being sent to QA for testing the week I left. After 9 months. Old. School.
But I didn’t know any better at the time. I hadn’t heard of Agile development methodology yet, and no one told me we were using the Waterfall model. Luckily, I got out of there and found a job at Cloudlock where I learned about Agile and eventually worked my way up to VP of Engineering. But I’ll never forget my first year as a Waterfall programmer.
So does methodology matter? Absolutely. But…
We Do Agile, But…
If you ask a software developer what methodology they follow, 95% of us will say, “We do Agile, but…”, usually followed by some version of Scrum or Kanban. While this sounds like a worldwide consensus, the reality is that every dev team I’ve worked on or managed has had a different software development process.
During my time as VP of Engineering at Cloudlock, I looked after 75 developers across 5 teams. Each team had their own unique process. There were team leads who had been working in software development for 25+ years and others that had just gotten promoted. The younger leads liked having a more strict process to follow, whereas the more senior managers had a process they had customized over the years.
All of those teams built amazing software even though their methods differed per team. Why? Because software development is not a zero-sum game. Just because one team is successful using Agile Scrum doesn’t mean another team will be less successful using Agile Kanban. Or Scrumban. Or SAFe.
There’s a lot of options out there, so instead of focusing on methodology, I find it makes sense to start with what you’re trying to do and work backward.
A Bespoke Development Process – The GigSmart Dev Team
I caught up with my friend Chris Downard, VP of Engineering at GigSmart, to chat about dev methodology. I was completely taken aback when the first thing he said to me was that he just got rid of teams in his software engineering department.
“You got rid of teams?!?”
I’m not personally strict about following this or that development method, but getting rid of teams felt a little extreme.
Chris: “It naturally evolved that way. Because of this remote culture that we adopted very rapidly, we just found that the backend people tended to support each other on their backend tickets; whether or not it was on their direct team or a direct feature they were working on. They were helping each other, committing to each other’s code, etc. So we kept the team thing going up until last month, and we were measuring that way, so we just eliminated it because it didn’t make sense anymore.”
Getting rid of teams works for Chris for two reasons: 1) He runs a small-ish team of 14 developers; and 2) The team uses a Kanban-style framework. If there are 3 or 4 features in flight, each team member is assigned to one as their dominant project, but they’re all on one team.
Many of the classic Scrum ceremonies are still followed, but he’s working on making them more effective as well.
“We do one large standup and it takes us 15 minutes to get through. People give their standup updates in order based on their dominant feature. So the first set of people who go, are the ones who are working on Feature A, and the second group that goes are all working on Feature B.”
On top of no teams and restructuring their daily, Chris says they work in sprints but use a Kanban board to increase speed.
“The product team loves that because if they decide that something is suddenly really hot because sales has run into this or that, we can address it immediately.”
Listen to the full interview with Chris below.
Why Does GigSmart Work This Way?
Reason No. 1: Chris believes in continuous improvement based on team feedback.
When he runs sprint retros, anything that engineering brings up that isn’t working, they have a conversation about. He brings in the product owner, and they chat about ways to make it better, and then they test it. And if it doesn’t work, Chris readjusts and tries to fix it. Since he started at GigSmart, there hasn’t been a 4-week period where their process has stayed the same.
Reason No. 2: GigSmart’s most valuable outcome is speed.
The methodology, process, or ethos that drives your team needs to be purpose-built to achieve the outcome you want. At GigSmart their defined outcome was high quality and speed. As an on-demand staffing platform, they choose to prioritize hotfixes and bugs. Other companies might need to be more predictable, quality-driven, stable, consistent, etc. based on their business type and needed outcome.
Reason No. 3: GigSmart is culture-driven
“Build better, more engaged engineering teams… That’s probably what my actual official job description is. So culture really matters.”
Chris and GigSmart CTO, Jason Waldrip, modeled their team’s cultural values on the ancient samurai code of Bushido, eight values that they’ve written down and strive to live and work by every day.
Reason No. 4: GigSmart is data-driven
Measuring is not enough, you have to measure with a purpose. You get what you measure. Everyone is familiar with this saying. Chris takes it a step further and actually encourages the team to look at data about how they work in all of their day-to-day practices and ceremonies.
By defining his company’s most valuable outcome and listening to his developers, Chris has created a development process that is bespoke to his team today. Just like a custom-tailored suit, his development method cannot be easily used by another company. It had to be made up.
Make Up Your Own Dev Methodology: 4 Guiding Ideas
Sometimes I just like building my own thing from the ground up. It’s why I started LinearB. Do you need to create your own development method? Definitely not.
It’s much easier to start with Scrum or Kanban and adapt from there. But times, they are a changin’, and maybe this is a good year to go through the exercise of redefining how you work.
After we started full-time remote back in March 2020, my co-founder, Ori Keren, and I did just that. We created Asynchronous Development, a development methodology designed around async communication and purpose-built for hybrid remote teams. Here’s the recipe:
- A dash of Agile methods (only the best parts)
- A dash of Scrum
- A heaping cup of what Ori and I have learned really works for us
- A pound of where we think the future of software development teamwork is headed
Hundreds of teams started following the Async Development methodology, and we’ve evolved it in the last two years to bake in our Developer Workflow Optimization tooling to further improve workflow. If we can make up our own dev methodology, you can too!
Here are 4 guiding ideas that will help you make up your own dev methodology:
1. Know Your “Why”
What matters to you? If it’s aligning to your company’s most important business goals, do you know what they are? Startups tend to want lots of new features as quickly as possible. More mature companies like predictability and quality. Find out and work backward from there.
For Ori and I, it’s more than just visibility for senior leaders, but it’s helping developers deliver code every day.
2. Don’t Be Dogmatic
Forget about the rules and just ask yourself, “How do we really want to work?” Ask your people. Especially your out-of-the-box thinkers. The more crazy ideas you throw in the mix, the more discussion you’ll create, and the more you’ll end up with something that is really bespoke.
For example, the Agile Manifesto says face-to-face communication is the most efficient way to transfer information. Is that still true for your team?
3. Retro Your Current Process
Ask, “Why are we doing all of these things we do every day?” Do you really need a daily standup? Do you really need two-week sprints? Are you really getting value from them?
The answer may be yes. But I bet if your team will have a lot of ideas of how they could be more dev-friendly and more efficient.
4. Bring Data to the Conversation
After you’re done exploring all of the pain from step 3, see if you can prove or disprove any of the assumptions and anecdotes with actual data. This might be the hard part, actually. The type of data you need is not necessarily accessible in your Git or project management system.
If you need help, check out LinearB. Our free-forever plan provides tons of metrics and process visualizations to show you what’s working, bottlenecks and how you can improve efficiency, quality and teamwork.
What’s Your Made-up Methodology?
I know many of you have already customized your own dev methodology. I’d love to hear about it! What pieces of existing methods did you use? What new things did you invent? What is special about your approach?
