Most people, when thinking about Scrum, consider stand-ups backlogs and user stories. All too often the actual code base is overlooked. In my opinion, it is a mistake not to take engineering into account.
The code matters in an agile environment because you need the software to be easy to maintain and extend, allowing the pace of development to be sustainable and make scoring more accurate.
Let’s say we have a story that we have scored at 5 points, but when we get into the code, it is complicated and hard to understand. Although the story might not be that large, it takes longer to deliver, so our velocity is negatively affected.
If stories often take longer to deliver because of excessively complicated code, then developers will start to doubt the validity of the scores they are giving to the tasks. In some circumstances they may want to see parts of the system before they can score the story, thereby losing the purity of the score. Instead of being scored on the size of the work, the complexity of that particular piece of code becomes the motivator for the score.
How do we address this problem?
There are many techniques that we can use to keep our code simple. However, they all require commitment and effort from the developers. Mark Twain summed this up in his quote “I didn’t have time to write a short letter, so I wrote a long one instead.” Writing simple, elegant code requires far more effort than creating a tangled mess that somehow works.
Developers need to be proud of the code they write and to put in the extra effort to ensure the simplicity of the work that they do. This pride and willingness of your team to put in more effort than the minimum required to make something work is key to having an elegant codebase.
There are, of course, many techniques you can use to help guide a development team to producing maintainable code. Test-driven development, pair programming and peer review all have their proponents. Personally, I have used all of these at some point and found that they are helpful. However, nothing beats having developers that care about their work in the first place!
Leave a comment