3 ms·

There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way t

There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should". Yes, the usual tools (JIRA, yuck!) and methodologies (SCRUM, SAFe...) tend to be the problem as they are too prescriptive and too cumbersome and verbose. But they are simply a set of tools to have in one's belt once you hit some common themes, but yes, some take them to heart. I think true agility is only achievable with a switch to proper outcome-oriented goals which give a lot of liberty to engineering teams. Otherwise, the decision makers on what gets built and how are too far removed from those doing the building. But that means a mindset shift for engineers (and everybody else!), in that they need to stop thinking about projects, and start thinking about results they achieve. I do agree that the fact that most get this wrong (I remember a new TL writing down a 30 page document on teams' "agile processes") means that something has been lost in translation, and "Agile" really isn't. I think it's fair to say that agile method is something to strive for, but never fully realise. But, what would you propose we call the type of process we strive for, and is there a methodology/strategy you do like? What are the principles of building software and building high quality software that worked for you in a team?

bartread 2y ago
> There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should". Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for. "Let engineers build software the way they think they should," is an alien concept to all the businesses I've experienced. Now, as it happens, I don't necessarily think engineers should have the last word either, because I've seen too many people disappear down too many rabbit holes and not deliver anything valuable, but clearly agile is broken.
- necovek 2y ago
  I am sorry that was your experience, and not because of "agile" — businesses which leave expertise to experts usually excel IME. The one gotcha is that you want to have good questions asked along the way (by PMs, business people...), and not necessarily have the "last word", when smart engineers will realize sooner when they are on the wrong path. This combination of talent is rarely achieved without specifically recruiting for it. To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.

bartread 2y ago

> There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should". Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for. "Let engineers build software the way they think they should," is an alien concept to all the businesses I've experienced. Now, as it happens, I don't necessarily think engineers should have the last word either, because I've seen too many people disappear down too many rabbit holes and not deliver anything valuable, but clearly agile is broken.

necovek 2y ago
I am sorry that was your experience, and not because of "agile" — businesses which leave expertise to experts usually excel IME. The one gotcha is that you want to have good questions asked along the way (by PMs, business people...), and not necessarily have the "last word", when smart engineers will realize sooner when they are on the wrong path. This combination of talent is rarely achieved without specifically recruiting for it. To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.