Breaking the cycle, prioritize quality. One way is with rewards but they are typically short live. Unless you continuously increase the prize, they get use to it and our developpers always tend to use the shortest and easiest path.
With carrot and stick, yes the carrot can "work" but the stick is required.
But we need to be carefull. If the stick comes from management, you demotivate the team and create fear and lose creativity (plus many other stuff).
The benefit of the sticks works if it is sefl-imposed. In your chocolat example, you need to add some bad taste in the Hershey for them to learn that free is not always good.
We have some teams working in pure DevOps with multiple pushes in production per days (some per hours). Any major issues found in production goes to opsgenie and Developpers (or anyone in the team) get called, anytime of the day. That hurts!! After some experience, the teams learn and are much more carefull before pushing in prod. They increase automated coverage, start implemeting pre-prods system in Rings and much more observability in prod.
This is the best way I have ever seen in breaking the cycle.
Unfortunately we haven't found anything similar for the team working in a more traditional release of software for On-Premise systems (3- 4 months release cycles). Bugs found in pre-prod are quickly resolved and just pushed to testers or support and the Dev just goes back to work on features for the next release cycle. Showing report or dashboards on poor quality to upper management haven't made any real difference, or maybe some teams will make more effort but it's not generalize.
We have forced teams to do regular bug bashes, but Dev hates this activity and we get a "management using the stick" situation and have lost some Dev this way.
If anyone have a way to create self-impose stick, please let me know!
Breaking the cycle, prioritize quality. One way is with rewards but they are typically short live. Unless you continuously increase the prize, they get use to it and our developpers always tend to use the shortest and easiest path.
With carrot and stick, yes the carrot can "work" but the stick is required.
But we need to be carefull. If the stick comes from management, you demotivate the team and create fear and lose creativity (plus many other stuff).
The benefit of the sticks works if it is sefl-imposed. In your chocolat example, you need to add some bad taste in the Hershey for them to learn that free is not always good.
We have some teams working in pure DevOps with multiple pushes in production per days (some per hours). Any major issues found in production goes to opsgenie and Developpers (or anyone in the team) get called, anytime of the day. That hurts!! After some experience, the teams learn and are much more carefull before pushing in prod. They increase automated coverage, start implemeting pre-prods system in Rings and much more observability in prod.
This is the best way I have ever seen in breaking the cycle.
Unfortunately we haven't found anything similar for the team working in a more traditional release of software for On-Premise systems (3- 4 months release cycles). Bugs found in pre-prod are quickly resolved and just pushed to testers or support and the Dev just goes back to work on features for the next release cycle. Showing report or dashboards on poor quality to upper management haven't made any real difference, or maybe some teams will make more effort but it's not generalize.
We have forced teams to do regular bug bashes, but Dev hates this activity and we get a "management using the stick" situation and have lost some Dev this way.
If anyone have a way to create self-impose stick, please let me know!
Thanks