Agile Development – Managing Software Features and Ownership

agilecode-ownershipproduct-featuresproject-management

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 called Shared Code, is a fundamental principle in many flavors of Agile development, and it's probably what you're experiencing:

From extremeprogramming.org:

Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes.

From c2.com:

ExtremeProgramming considers code to belong to the project, not to an individual engineer. As engineers develop required functionality, they may browse into and modify any class. They are responsible for keeping all the UnitTests running (and writing new ones for new functionality). They take on the same integrity-preserving duties as the class owner in a CodeOwnership situation.

Working in this mode lets a responsible team move quickly to add new functionality while keeping responsibility in the right objects. CodeOwnership creates dependencies and bottlenecks when implementing UserStories. We avoid code ownership, because it conflicts with commitment from the PlanningGame. ("Code is nothing, stories are everything!")

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 of Strong Code Ownership (where individuals "own" their modules) and Collective Code Ownership. He describes this as Weak Code Ownership:

Weak code ownership is similar [to Strong Code Ownership] in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people. If you want to make a substantial change to someone else's module it's polite to talk it over with the module owner first.

In the same article, he goes on to say:

The choice between weak and collective ownership has more to do with the social dynamics of the team. Both seem to work, and fail, equally well. Personally I prefer the dynamics of a collective code ownership team - particularly in the context of Extreme Programming.

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.

Related Topic