While it's very frustrating to work on something that then doesn't get completed, in some ways it's probably better to fail in planning/documentation stage than have half-built application.
Would be interesting to see what other here consider "minimum viable documentation" to progress with project - being agile by definition means you won't have all the docs and designs, but there surely needs to be something solid in place before coders could start writing actual code.
Yeah I agree. I think a big problem was that when the client got cold feet about agile, they felt the fixed cost design helped them throw “everything but the kitchen sink” into the product.
No agile process seems to help people be more humble about their ideas - it’s more a mindset thing IMHO.
Have to admit the companies I've worked for never fully implemented "proper official" process, it's always been selftought and implemented in patches.
Even with not going the whole way it's made massive improvements to dev side, however you can imagine my face when I relatively recently discovered management/client/stakeholders need to be actively part of agile process as well.
mind blown
Do you think in general it's more about people not happy anyone "mess" with their ideas than lets say any proven/measurable financial benefits?
Absolutely. This is why I tell people the resistance to being an agile team (and not just another team that uses agile processes like scrum but doesn’t change direction) usually comes from people not wanting to be humble enough to admit there are other sources of good ideas than themselves.
I do wonder if non-techies could be scared of being "more involved" in development, or they might not care, because just implementing dev-specific processes improved raw code efficiency and they get what they want out of it - therefore, why change it?
On project level, would you still need some sort of set mission statements that don't change?
Or is it better to not enforce any and go "with the flow" so to speak?
I mean, it's kind of unlikely that you start with building CMS system and end up with open world PS4 game, so it might waste of time to even worry about it.
On other hand I could see how it could end up exactly like you described in your story, where it seems company lost the concentration and went crazy with including features.
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.
While it's very frustrating to work on something that then doesn't get completed, in some ways it's probably better to fail in planning/documentation stage than have half-built application.
Would be interesting to see what other here consider "minimum viable documentation" to progress with project - being agile by definition means you won't have all the docs and designs, but there surely needs to be something solid in place before coders could start writing actual code.
Yeah I agree. I think a big problem was that when the client got cold feet about agile, they felt the fixed cost design helped them throw “everything but the kitchen sink” into the product.
No agile process seems to help people be more humble about their ideas - it’s more a mindset thing IMHO.
Have to admit the companies I've worked for never fully implemented "proper official" process, it's always been selftought and implemented in patches.
Even with not going the whole way it's made massive improvements to dev side, however you can imagine my face when I relatively recently discovered management/client/stakeholders need to be actively part of agile process as well.
mind blown
Do you think in general it's more about people not happy anyone "mess" with their ideas than lets say any proven/measurable financial benefits?
Absolutely. This is why I tell people the resistance to being an agile team (and not just another team that uses agile processes like scrum but doesn’t change direction) usually comes from people not wanting to be humble enough to admit there are other sources of good ideas than themselves.
I do wonder if non-techies could be scared of being "more involved" in development, or they might not care, because just implementing dev-specific processes improved raw code efficiency and they get what they want out of it - therefore, why change it?
On project level, would you still need some sort of set mission statements that don't change?
Or is it better to not enforce any and go "with the flow" so to speak?
I mean, it's kind of unlikely that you start with building CMS system and end up with open world PS4 game, so it might waste of time to even worry about it.
On other hand I could see how it could end up exactly like you described in your story, where it seems company lost the concentration and went crazy with including features.