One of the things that are high on my list of priorities is the agile development process. Successful software development depends on many things, one of the most important is a strategy. Regardless of if it is bugs or features, you need a plan of attack, and driving and refining that process, be it scrum, kanban or variations, is not quite, but almost, a religious thing to me.
During the last couple of years, I have worked as a scrum team member and I have introduced Scrum to new teams, and that is something that I wouldn’t mind investigating further.
As part of the Scrum methodology, I like to incorporate rules and guidelines for the actual process of developing software. If Scrum or any other project methodology is the framework keeping all the larger bits and pieces working nicely together, these rules and guidelines – or code care as I like to call it – aim to assist the developer and the development team to produce good, maintainable, bugfree code.
If the Scrum process starts with a stakeholder writing a user story and ends with that story delivered as free of bugs as possible, the code care process starts with that user story getting test cases, solution suggestions, new shiny code, code reviews and finally a release and/or successful acceptance test.
By reducing the scope of the tasks at hand, all involved can focus on each specific task that needs to be addressed. And using the guidelines of the code care process there is no question how each coding item should be implemented.
Writing code and creating software systems is a handcraft, and rules of the craft should be applied. And there actually are rules out there that can be applied. It is just a matter of deciding to use them.
