I have been practicing Agile and SCRUM for the better part of my career, I have seen it done in many ways as well as abused from time to time. Although there are clear guidelines on how SCRUM should be done, in each company it was done differently.
Many SCRUM practitioners believe that “all team members are create equal” and as such it should be beneficial to the project if every single developer could take any task. This approach has many benefits:
Making sure that every single developer on the team has a good understanding of the project is a challenge – which can be addressed by pair programming and doing code reviews. But with best of intensions it’s impossible to guarantee that all of the developer understand all of the code all of the time.
Using the practice described above has one important implication – the team owns the code, meaning that no single developer owns the code – meaning that a developer will only be responsible for as task until it finished, afterwards it shall become part of the “team’s responsibility”.
Most of the time this is not an issue – But what if the problem you’re trying to solve isn’t contained in the development team realm of control?
Let’s say that the team need to add a dialog that would open a web page on the company site so that the user shall write his feedback on the new product. One of the team members implement the required functionality (i.e. code that opens a specific URL) and then sends an email to the guy responsible for the website and pass the task to done.
As far as the developer concerned he has finished the task, unfortunately no one checks with the web admin to make sure that the web page has been added and that the data is actually being stored according to spec – big problem.
I’ve seen these tasks that requires integration with other teams or a contractor tend to fall between the cracks because of lack of ownership.
On the other side what happens if each developer of your team owns a part of the teams code – in that case you know that the developer that responsible for the feature will make sure that the integration actually works. You loose the ability to swap tasks between team members but gain responsibility that is hard to artificially create when “everybody (read: nobody) owns the feature.
Code ownership doesn’t come free it – when someone “owns” code it means that he is the only person that can change it but there are ways to make sure that no developer shall become the project’s bottleneck – namely code review and pair programming, the only difference is that there is a clear owner of that code.