We use Scrum and have weekly sprints. I had someone asking me about a piece of the application that had been developed in a sprint a couple weeks prior. The developer asking the question had not worked on that piece during that previous sprint and was now working on something that involved refactoring a portion of that code. During the discussion, when asked about how certain pieces of it worked, the developer brought up the fact that the piece of code was not written by him, as if to say, "Well, that's not MY piece of code". I was more than a little surprised by this comment and not only because in Agile development there is collective code ownership but also because it shows a lack of investment in the project. These obviously go hand in hand. The more invested a developer feels in a project the greater his sense of ownership.
Even so, the concept of collective code ownership means that all team members are responsible for the code that is developed. That doesn't mean that you have to know every detail about the application or about what your team members are working on but it does mean that you should at least know what they are working on and how it impacts the rest of the application. If they are applying a new technology you should at the very least have an idea of some of the issues that can come up while doing so simply from the daily stand up meetings. The point of collective code ownership is that any member of the team can work on any piece of it. A single piece of the code is not dependant on a single developer. This is also a benefit of occasional pair programming and having other team members test your code/tasks because it allows for another pair of eyes to look at the problem even if it is done as more of an overview.
So if a developer comes across a task that requires them to work on a piece of the code that they haven't worked on before they should be doing all they can to learn what they can about this piece of code. Whether they turn around and talk to the developer who first wrote it, read through the code (which would probably be my first step) or start researching on their own by looking online, in books or other documentation, they should be invested enough that the fact that they did not write it in the first place should never even come up.
No comments:
Post a Comment