Most developers “own” portions of the applications they work on. Also known as “Strong Code Ownership”, or simply “Code Ownership”, this is often seen as a good practice. How come it’s also one of the most counterproductive project management techniques in an agile team?
For a new music player project, a company gathers a team of 3 web developers:
For the first sprint, three user stories sit on top of the backlog:
The optimal choice is pretty obvious:
So far, so good. For the following sprint, the product owner prioritizes three new user stories:
From a skills and experience point of view, it makes perfect sense to let each developer work on what they already know the best.
Consequently, each team member starts developing a strong sense of ownership on certain portions of the code. This will undoubtedly lead to a better productivity, right?
After a careful review of Key Performance Indicators, the product owner decides to prioritize the three following stories for the third sprint:
Alice can work on the UI controls of all three user stories. Bob can also develop the API for all three new models. As for Charles, he never worked either on the frontend app or on the API, so he can’t really develop any of the stories.
Even though these user stories bring the most business value at that point of the project, the development team is already too specialized to develop them in this order. This forces the product owner to adjust priorities and push a nice to have feature instead of a must have feature.
So the product owner rearranges the backlog, and proposes the following instead:
Now Charles has an obvious choice: he’ll work on the playback data aggregation for the top 100 (#9). As for Alice and Bob, they will work together on the album art and lyrics stories (#7 and #8), Alice in the frontend part, and Bob in the backend part.
When she starts the album art GUI, Alice is blocked because the corresponding API is not yet ready. She can’t switch to the lyrics GUI either, because Bob works on both APIs. So Alice ends up redeveloping part of the Album Art API logic inside the frontend application.
At the end of the sprint, neither story 7 or story 8 are finished. Bob and Alice couldn’t handle a single user story on their own, and their dependence on each other’s work slowed down the overall development.
For the following sprint, an unpleasant event happens: Alice catches the flu. She’s seriously sick, and she’s also seriously contagious. Her doctor puts her on medical leave for two weeks.
Unfortunately, the product owner had prioritized user stories with a GUI part. So Bob and Charles end up looking at the frontend code for the first time. It takes them a few days to understand how Alice organized her code. They don’t understand it all (because they didn’t follow Alice’s work before), but with a few copy and paste they manage to somehow implement the frontend features - in twice the time it would take Alice to do it.
Had they worked on that part of the code before, Bob and Charles would be able to handle frontend development tasks much faster, and meet the product owner expectations on schedule.
When Alice comes back, Bob goes on holidays. After all, it’s Christmas time, and Bob has been working for the company long enough to take a well-deserved two weeks holidays. He flies to the French Alps for a joyful skiing session.
This time, the product owner decides to push a user story concerning genres. This obviously requires an update to the JSON API, so Alice and Charles dive in Bob’s code. They soon realize that Bob forgot to document some methods, and left certain use cases untested. Since nobody ever reviewed his code before (after all, he’s the API expert), nobody realized that he also took dreadful shortcuts.
Charles could have given Bob advice if he had reviewed his code from the beginning. But it’s already too late. At that point, it is clear that strong code ownership has lead to an increase in technical debt.
Bob comes back from holidays with a nice tan. He’s surprised that his colleagues feel much less relaxed than him.
The team is complete again, and the product owner decides that it’s time for the first deployment to production. The first real users discover new bugs that weeks of Q&A never revealed. The backlog quickly fills up with urgent issues.
Alice, Bob and Charles review the issues and try to determine who’s responsible for each bug. More often than not, nobody feels entirely responsible for a given bug - maybe because the bug results from an edge case of the communication between the frontend and the backend, or because it’s triggered by the analytics script, which is neither frontend, or backend, or Big data.
The product owner gets nervous about some bugs not being resolved. He asks again the team to collectively fix them quickly. Alice thinks Bob and Charles should fix them - it’s not her domain. She doesn’t understand why they don’t volunteer, and she despises them for not helping the product owner. She takes the initiative to fix a bug with implications all around the codebase. At one point, Charles asks Alice to stop breaking his code.
After an entire sprint dedicated to fixing bugs, the mood of the team is quite dark. Each developer feels abandoned by the others, and is determined to stop helping them in the future. Collaboration is dead - if it ever existed.
The rest of this project story doesn’t need to be told. Suffice to say that it ends badly.
This project went wrong right at the beginning of sprint 2. Alice should have worked on story #5, Bob on story #6, and Charles on #4. Or another rotation. But they should have gained in expertise on another part of the application instead of increasing the fences around their own code.
This is called “Collective Code Ownership”, and it’s simple to put in place:
If it’s impossible to promote collective code ownership because the application is too big, or because the technologies are too far from each other (for instance, a native iOS app interacting with a Clojure API), there are solutions, too. Break the team into smaller teams, dedicated to sub-apps; forbid strong code ownership in a single team.
And if you think that it’s a waste of time to ask a frontend dev to learn backend techniques (or vice-versa), we don’t see the job of web developer the same way. Learning a new language or framework will always make developers more productive in general, including in their language of choice.
In an agile context, the drawbacks of strong code ownership outweigh the benefits. This is a controversial point of view (see other opinions on the matter), but my experience leads me to think that Collective Code Ownership is the solution. Every developer should feel responsible for the entire application developed by their team. The entire team should be proud of the work accomplished. It makes the developers, and the product owner, happy in the long run.
Published on 27 Feb 2014