These are some great realizations here. I love seeing stuff like this. I like your four questions to recruiters. Developer empowerment is a very valuable thing, but can be tricky to get insight into without actually working, or knowing people, at a company.
Most of what you moved to would more traditionally be described as Agile. The emphasis on collaboration is key (e.g. including dev team at all levels of the process, swarming, getting critical feedback as early as possible). The "Agile" scenario you described initially did not sound Agile in the slightest. I am lucky to never have worked for a company with such a process that had the audacity to call it "Agile". Not including the dev team in writing stories, and at least enumerating the possible code tasks is a woeful mistake.
The Dev Design idea is pretty cool. It's a very developer centered twist on something I've seen a lot in practice, which is to collaborate in writing all user acceptance tests before any coding begins. Both strategies can work well, because they have the goal of gaining a shared understand of the work before any time is wasted implementing the wrong thing.
I've heard a few people with similar "that's not Agile" responses to the scenario I describe, and while I fully agree, I think perhaps the downfall of Agile is its vagueness. It's too easy for a traditionally-structured company to say "of course we value individuals and interactions over processes and tools, etc.", tell everyone to do standups and sprints, and call themselves Agile. And it doesn't help that a lot of "Agile coaches" and "Agile product managers" don't understand Agile either.
The worst part is that a naive, bandwagon implementation of Agile is significantly worse than no Agile at all. One of the first places I worked as a developer, the implementation of Agile was unbelievably bad (and yes, they called it "Agile" without batting an eye, because there were sprints). They kept trying to solve their problems by reorganizing -- there was a complete restructuring of the development teams every 2-3 weeks -- and turnover was through the roof. I constantly felt like I wasn't allowed to be productive. I didn't last long there.
As good as the Agile manifesto is, there ought to be a sister document describing what Agile is not. I'd love to see some of my former managers' faces when they read "Agile is not about daily standups! Surprise!" I guess that's my next project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
These are some great realizations here. I love seeing stuff like this. I like your four questions to recruiters. Developer empowerment is a very valuable thing, but can be tricky to get insight into without actually working, or knowing people, at a company.
Most of what you moved to would more traditionally be described as Agile. The emphasis on collaboration is key (e.g. including dev team at all levels of the process, swarming, getting critical feedback as early as possible). The "Agile" scenario you described initially did not sound Agile in the slightest. I am lucky to never have worked for a company with such a process that had the audacity to call it "Agile". Not including the dev team in writing stories, and at least enumerating the possible code tasks is a woeful mistake.
The Dev Design idea is pretty cool. It's a very developer centered twist on something I've seen a lot in practice, which is to collaborate in writing all user acceptance tests before any coding begins. Both strategies can work well, because they have the goal of gaining a shared understand of the work before any time is wasted implementing the wrong thing.
I've heard a few people with similar "that's not Agile" responses to the scenario I describe, and while I fully agree, I think perhaps the downfall of Agile is its vagueness. It's too easy for a traditionally-structured company to say "of course we value individuals and interactions over processes and tools, etc.", tell everyone to do standups and sprints, and call themselves Agile. And it doesn't help that a lot of "Agile coaches" and "Agile product managers" don't understand Agile either.
The worst part is that a naive, bandwagon implementation of Agile is significantly worse than no Agile at all. One of the first places I worked as a developer, the implementation of Agile was unbelievably bad (and yes, they called it "Agile" without batting an eye, because there were sprints). They kept trying to solve their problems by reorganizing -- there was a complete restructuring of the development teams every 2-3 weeks -- and turnover was through the roof. I constantly felt like I wasn't allowed to be productive. I didn't last long there.
As good as the Agile manifesto is, there ought to be a sister document describing what Agile is not. I'd love to see some of my former managers' faces when they read "Agile is not about daily standups! Surprise!" I guess that's my next project.