2013 and almost a decade has passed since I embraced agile development practices. Along the way, some of the fluff got dropped, some of it became lifestyle, some of it evolved into something better. “We” went through a lot. And those that made the decision back then to abandon established practices and try something new did it because “there had to be a better way” to releasing software. That was 10 years ago. Software release was messy. Bugs were expensive. Fast forward to today and production bugs are still expensive; if not more so.
What surprises most though is that after all this time, there still remain a number of projects (a collective term which includes startups, corporate teams, freelancers) where the methodology and practices are *still* 1990. If anything, members on some of those teams are even more resistant to change. And disturbingly, not all of them have even been coding for that long either. Oh, and the positions on the debates haven’t changed argument in 10 years. Time to move on…
I guess what has happened is that the experienced members of the team tried to adopt agile in some form or another at the wrong time in the wrong place with the wrong stakeholders. They got burnt. Juniors joined the team, maybe some of them eager to apply some agile practice, but the prevailing ethos was not going to let that evolve. If anything, the sentiment against any kind of agile practice was antagonistic (yes, not all decisions made by engineers are rational).
The nett effect; incumbent teams with a deep mistrust of change, still struggling to release software like it was 1999. Beyond that, unhappy programmers who complain about how dull software development is. And worse, a generation of developers unwilling to take ownership.Â Attitudes get in the way of releasing beautiful software.
Thankfully though, on the flip side of that are a bunch of shiny, happy people. They don’t need to be agile or follow an agile methodology to be great- they just are. They get on with the job and release beautiful software. Projects (which is to say, teams of developers from 1-n) need, more than ever these days, devs happy to embrace change and own the tech domain. Introducing agile (wether actually adopted or not) is just one way of gauging how resistant your team’s mindset is.
If you’re struggling with a team, or part of a team that’s struggling, the best thing you can do is make an effort to make it better- and the thing you’re looking for is not a messiah, a methodology, a bullet or a graile: it’s a thing which starts with a change insideÂ you.