So you wouldn’t pay a plumber in your home if (s)he didn’t predict the end result and budget, is that what you’ trying to say?
If yes, I fully agree. The reason why this anti-pattern exists is that something complex (software development) is modeled after something complicated or simple (like plumbing).
In case you‘re open to learning about that, check out the Cynefin model.
Your analogy highlights something else: software delivery - like plumbing- is often seen merely as an investment, while in today’s digital age, return on investment should be considered.
Finally, there are cars and fighter planes built with Scrum. So it’s possible to apply agile practices to engineering as well.
My point was - you should be able to estimate efforts. And customer should be aware that any scope change basically returns you back to the beginning of the entire process - more or less. I am fully aware, that one can't predict everything and like a plumber who first needs to break the wall to see where exactly the pipe is broken, and how bad the problem is, then tell you what you have to do next and what your options are. This is the agile part precisely, but nevertheless we are professionals and we should be able to estimate how long it will take to do something.
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.
So you wouldn’t pay a plumber in your home if (s)he didn’t predict the end result and budget, is that what you’ trying to say?
If yes, I fully agree. The reason why this anti-pattern exists is that something complex (software development) is modeled after something complicated or simple (like plumbing).
In case you‘re open to learning about that, check out the Cynefin model.
Your analogy highlights something else: software delivery - like plumbing- is often seen merely as an investment, while in today’s digital age, return on investment should be considered.
Finally, there are cars and fighter planes built with Scrum. So it’s possible to apply agile practices to engineering as well.
My point was - you should be able to estimate efforts. And customer should be aware that any scope change basically returns you back to the beginning of the entire process - more or less. I am fully aware, that one can't predict everything and like a plumber who first needs to break the wall to see where exactly the pipe is broken, and how bad the problem is, then tell you what you have to do next and what your options are. This is the agile part precisely, but nevertheless we are professionals and we should be able to estimate how long it will take to do something.