Waterfall, Scrum, Agile, BDD, Kanban, Shape Up, RAD, SAFE, Sprints, Innovative Accounting, Spotify Squad Model, Lean-Startup…The list of so called ‘Revolutionary Methodologies’ never ends.
PS: To my ex-colleagues from ThoughtWorks who take offence on classifying Agile as a methodology — unfortunately in day-to-day work, most people in IT, including many ThoughtWorks employees, treat Agile as a methodology or a set of processes and practices rather than a philosophy.
Every few months, you’ll encounter a new “Methodology™” that promises to ‘change the way you work’, ‘fix everything wrong with the other methodologies’, and ‘increase your quality of work and productivity’. And those who don’t follow this new “Methodology™” are called ‘dinosaurs who will soon be extinct’.
Here are some of these buzzwords that I know of — Waterfall, Scrum, BDD, Lean Startup, A/B Testing, Continuous Innovation, Validated Learning, MVP, MDP, Build-Measure-Learn, ShapeUp.
What’s wrong with all of these?
What the inventors of these methodologies don’t explain is — what is the context and journey that made them choose the set of practices that make up the methodology, and how does their team and work differs from yours.
What the experts of these methodologies don’t explain is — what are their own incentives, and are they aligned with yours? Maybe it is in their benefit that the methodology becomes rigid, complex and bureaucratic, so that they remain employed forever?
If you try to adopt a particular Methodology™ in your team, and try to follow it perfectly, you’re doing it wrong. The people who invented the methodology do not know your team’s culture, working style, and complexities. Rigidly adopting something which was meant for a different context will be a painful experience
What to do instead?
The only right way to arrive at the right set of philosophies and practices for your team is to examine each process (technical and non-technical), and change it or remove it to suit your needs.
Start by picking methodologies (including technical ones like TDD, CI/CD) and processes that resonate the best with your team. Evaluate if it works for you. Discard, modify, or introduce something new if it doesn’t. There is no one right way of doing things.
Team working style is like Product Idea Fit. You will know when you get it.
How to evaluate processes?
Each process is designed to achieve 2 things -
- Organisation: A balance between chaos and bureaucracy.
- Feedback Loops: Give information on whether things are going well.
For example, Pull Request Review gives feedback on the quality of work done, and allows addition of features in an organised manner. Many organisations find Trunk Based Development faster and prefer relying on a quality test suite, CI/CD, and/or pair programming for feedback. Don’t adopt either process blindly, instead experiment with both and arrive at what’s best suited for your team.
Second Example — you might adopt Scrum/Kanban, but then keep the general structure, but drop practices that don’t work for you such as the ‘Given-When-Then’ acceptance criteria requirement for each story. Or maybe adopt something different like visual acceptance criteria.
Another example — If you face constant back and forth between Dev and QA despite having a decent test suite and CI, there’s a clear gap in Feedback Loops. Maybe adding a process like desk-checks that helps you shift-left on the feedback and bring Dev and QA on the same page can help.
Ultimately, the process should make the art of developing software more effective. If it feels like decisions are too slow, lighten on processes. If there’s utter chaos, think of what process would add enough organisation to remove the pain.
At the same time, your process has to be tuned to give high quality feedback. If you’re not getting that, it’s not working.
Finally, it should also make work a reasonably pleasant experience. Don’t adopt a practice that makes a majority of people start hating work.
Naming Convention
After multiple rounds of tweaking, your team will actually come up with something that ‘fixes everything wrong with the other methodologies’, and ‘increases your quality of work and productivity’, at-least for your team.
When you achieve this, make sure you discuss it, name it, and document it.
This signals to anyone new joining your team that your way of working is distinct, and good enough that you have actually documented it. It also allows you to get rid of the baggage of always arguing about the right way of doing an existing Methodology.
A great example of this is the Spotify ‘squad model’, which is just an adaptation of modular vertical teams with some specific modifications and different terminology. But naming and publishing it allows them to set their own tune and evolve in a direction that suits their own company.
At the same time, don’t stop tweaking and experimenting because you’ve achieved a sweet spot. Work keeps evolving and so should processes.
