This image was extracted from http://phandroid.com/2012/06/21/getting-acquired-how-to-transfer-ownership-of-your-android-app-or-game/
In the traditional approach (called Waterfall) most developers never feel the owner of the code.
Why did this situation happen?
Because they haven’t any opinion about the technical issues related with the requirements. Business Analysts think and write uses cases (or other form to specify the requirements) to document each requirement. Then architects move all this information to technical level such as model of database and so on. Even more, there were some company (or maybe there are still companies working in this old way) that provide a framework to developers in order to standardised the development.
In Scrum every team member can and have to contribute with his knowledge and experience during the Sprint Planning. During this ceremony each team member has to talk, discuss and argue with the Product Owner in order to help him to release the best value to the client. Furthermore, if developers realised about some issues with a legacy code (for instance) they have to speak up to the Product Owner to warn about it.
I used to work in a company where new developers have to deal with a huge technical debt and many of them feel sad about this situation because they never considered that code as own. Developers have to understand that working with a legacy code (or not) is the same that dealing with new project.
The code belongs to them!!
As soon as developers understand the ownership of the code they must do their best effort to clean the code. One of the best way to clean the code is every time they work in a piece of code they have to refactor this piece of code to remove redundant and illegible code.
To wrap it up, if you are working in a new project or updating (and fixing bugs) legacy code it’s your code and you (as developer or tester) have to worry about the quality of it!!
About the author
Freelance Agile / Lean Coach & Change Agent
You can reach him on twitter: @metlucero