Nit-picking here, but your agile team example sounds like you are dealing with a feature factory. If team members biggest priority is making the burn down chart look nice then what is happening is that the managers suck.
Absolutely CORRECT! And I totally appreciate you pointing this out. Like so many of my posts, this one was already long - without getting into all the vagaries of "correct" and "incorrect" attempts to run Agile development. That alone is easily its own post - or a series of posts.
I wasn't being facetious when I said that I really have no problem with Agile. It's been the dominant paradigm in nearly all of my jobs over the last 10+ years. And almost all of my "complaints" about Agile are really complaints about jacked-up, faux-Agile processes that are mislabeled by teams that wanna claim that they're somehow "Agile".
(I kinda hinted at this in the original post when I said that claims of being an "agile workplace" can mean almost anything - or nothing.)
For those of us who've done a "deep dive" on what it truly means to be "Agile", the vague complaints I outlined above don't even apply to a shop that's adhering to a true Agile process, right??? One of my pet peeves about Agile (again... this is fodder for a completely separate post), is that it's become, in far too many places, a generic buzzword that often has no similarity to a REAL Agile process.
I agree. The majority of my jobs have been feature factories that use scrum as a surveillance tool. Unfortunately, it just seems like unless you are spending half of your time explaining agile to management for the duration of your tenure things will stop being agile.
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.
Nit-picking here, but your agile team example sounds like you are dealing with a feature factory. If team members biggest priority is making the burn down chart look nice then what is happening is that the managers suck.
Absolutely CORRECT! And I totally appreciate you pointing this out. Like so many of my posts, this one was already long - without getting into all the vagaries of "correct" and "incorrect" attempts to run Agile development. That alone is easily its own post - or a series of posts.
I wasn't being facetious when I said that I really have no problem with Agile. It's been the dominant paradigm in nearly all of my jobs over the last 10+ years. And almost all of my "complaints" about Agile are really complaints about jacked-up, faux-Agile processes that are mislabeled by teams that wanna claim that they're somehow "Agile".
(I kinda hinted at this in the original post when I said that claims of being an "agile workplace" can mean almost anything - or nothing.)
For those of us who've done a "deep dive" on what it truly means to be "Agile", the vague complaints I outlined above don't even apply to a shop that's adhering to a true Agile process, right??? One of my pet peeves about Agile (again... this is fodder for a completely separate post), is that it's become, in far too many places, a generic buzzword that often has no similarity to a REAL Agile process.
I agree. The majority of my jobs have been feature factories that use scrum as a surveillance tool. Unfortunately, it just seems like unless you are spending half of your time explaining agile to management for the duration of your tenure things will stop being agile.