If metrics like lines of code or code coverage are widely known by the software development community, measuring the joy of a software development team is certainly something more rarely discussed. In this article, Doc Norton proposes a simple way to asses the happiness of your software developers using the quality of your existing code. With this, you can lower your Scrum team turnover and get hints for refactoring needs. Author: Doc Norton, co-founder of OnBelay, https://onbelay.co/ A few years ago, I was working with a client who had started an initiative around Joy at work. They had devised a short survey which was sent to employees on regular intervals with the intent of measuring their levels of joy at work. The response rate was relatively low company wide, but it was abysmal in software engineering. From feeling disrupted, to thinking the questions were not relevant to work, to a sense that nobody was doing anything with the data anyway, there were numerous reasons given for why people were not responding to the surveys. Most of the metrics we were gathering from the software teams were relatively passive. They were measures of the flow of work such as lead time and cycle time or measures of the output itself through static analysis. Basically, developers went about their normal day and measures were taken without any disruption to their normal routines. Our team joy measures, however, were a disruption. They didn’t fit into the flow of a normal day. We thought [...]
↧