Some development teams in my company are switching to Agile development practices and their developers' work seem to be diminishing to discuss and program minutia about trivial software features because of two week iteration cycles. And also because of "any developer can fix any bug" mentality. I have recently joined one of those team, transferring from another team in the same company…
I feel strongly that developers should own their software features from start (design) to finish (implementation and unit testing). Agile seems to be going counter to this thinking. Is there any truth to my perception or am I just living a bad implementation of Agile?
During our two week iterations, people somewhat arbitrarily get assigned new little features and bug fixes, depending on their workload during that cycle. Nobody seems to be owning responsibility of major features of the software. We spend stupid amount of times on trivial things, like adding a single button to a dialog during a two week iteration, complete with a story, daily scrums, code review, etc.
So in Agile projects, how does one manage larger features? Who own the responsibility: individual developers or the whole team? How does one extract him/herself from minutia and focus on longer term goals? Any feedback would be valuable.
Best Answer
If you think that it would help the team's efforts, you should not hesitate to soften the "any developer can fix any bug" mentality which you see as creating issues.
The practice of
Collective Code Ownership
, sometimes also calledShared Code
, is a fundamental principle in many flavors of Agile development, and it's probably what you're experiencing:From extremeprogramming.org:
From c2.com:
There's some definite benefits to
Collective Code Ownership
. However, you are not the first person to note deficiencies in that approach. None other than Martin Fowler describes an approach that lies in-between the extremes ofStrong Code Ownership
(where individuals "own" their modules) andCollective Code Ownership
. He describes this as Weak Code Ownership:In the same article, he goes on to say:
The bottom line is that to truly adhere to Agile principles, the team should do what leads to good-quality, working code. If that means loosening the grip on
Collective Code Ownership
, then there's nothing wrong (or anti-Agile) about that.