A waterfall of old-schoolness
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 Complaint Manager. During the 4-day event employees were directed to give me their complaints. Of course my friends dropped anonymous and 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 visibility 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 my 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 yet, and no one told me we were doing Waterfall. 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 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 backwards.
A bespoke development process – The Gigsmart dev team
“You got rid of teams?!?”
I recently caught up with my friend Chris Downard, VP of Engineering at Gigsmart, to chat about dev methodology changes in light of current events. I was completely taken aback when the first thing he said to me was that he just got rid of teams in his engineering department.
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 back end 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. He runs a small-ish team of 14 developers and 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.”
Why does Gigsmart work this way?
- 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 product and they chat about ways to make it better, and then they test it. And if it doesn’t work, he 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.
- 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 they’re 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.
- 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 cultural values on the ancient samurai code of Bushido. 8 values that they’ve written down and strive to live and work by every day.
- 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 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, 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. It’s our favorite parts of Agile. A little bit of Scrum. A lot of what Ori and I learned over the years that really works for us. And a big dose of where we think the future of software development teamwork is headed.
Hundreds of teams are now following the Async Dev methodology. If we can make up our own dev methodology, you can too!
Here’s 4 guiding ideas that will help you make up your own dev methodology
- 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? Start-ups tend to want lots of new features as quickly as possible. More mature companies like predictability and quality. Find out and work backwards from there.
- 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?
- Retro your current process
Ask… “Why are we doing all of these things we do every day?” Do you really need a daily stand-up? Do you really need two week sprints? Are you realy 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.
- 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. Click here to sign up with your Git account.
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? Please post in the comments section or hit me up directly on Linkedin. I would love to include you in my next blog or in an upcoming episode of my podcast Dev Interrupted.
Top comments (0)