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.

  • If you want to extract yourself from the minutia, don't worry about making a life-time assignment of a feature to a specific developer.
    – JeffO
    Commented Feb 11, 2013 at 18:53
  • "people somewhat arbitrarily get assigned new little features" sounds like your problem, that isn't agile. Typical Agile processes should let you select your own work. Try reading a book about Agile - I recommend succeedingwithagile.com for everyone. Commented Feb 11, 2013 at 20:04

6 Answers 6


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.

  • Great answer and good quotes! I would say that in a perfect world with the perfect team that Strong Code Ownership makes perfect sense. A lot of companies carry dead-weight developers though and when they are given ownership of a task, then everybody suffers and software quality is brought down to the lowest possible level as a result. Extreme programming and collective ownership is better in this case because ineffective developers can be worked around.
    – maple_shaft
    Commented Feb 11, 2013 at 17:08
  • 3
    @maple_shaft: I would say that in a perfect world with the perfect team that Collective Code Ownership makes perfect sense. All the developers would fully understand all the code and be competent to make changes anywhere. Any developer could do all the work needed for any user story. There would be no bottlenecks as one owner or another became overloaded. Commented Feb 11, 2013 at 17:13
  • @kevincline Good point and a perspective I didn't consider
    – maple_shaft
    Commented Feb 11, 2013 at 17:33
  • Great answer. I think what makes me uncomfortable with Agile is the large difference between my former and new team's practices. In my former team, everybody had Master and PhD degrees in an engineering field. They were first an expert in an area who would then implement specialized code in their domain of expertise. So shared code ownership would be practically impossible. Whereas in my current team, everybody is essentially a computer science major with similar backgrounds and experience, which seems to make shared ownership more feasible.
    – Kavka
    Commented Feb 11, 2013 at 22:44
  • @Kavka: I'm guessing your former team was relying on domain expertise as a substitute for explicit unit-level requirements (i.e. unit tests). Domain expertise is needed to define requirements. It is not needed to implement requirements once defined. In my experience code written by domain experts tends to be difficult to maintain because the domain experts are rarely also expert programmers. Commented Feb 11, 2013 at 23:08

In order to answer your question I will try and give a description of how we handle the situations mentioned in your question:

We use the Scrum framework in Agile. Sprint Planning and backlog grooming sessions assist our team to have broken down, relatively-properly defined stories.

All in all a team as a whole is responsible for the outcome of commitments for a sprint (all the stories). They succeeds or fail as a team. Thus the team as a whole would influence how work must be managed to get the job done in the sprint.

Story cards taken by a developer (in the standups) becomes that developer's responsibility to get it done and signed-off, ready for release at the end of the sprint. However the team should use the daily standups to see if anyone seems to be struggling with they story and then proceed to assist the dev to complete his outstanding tasks.

In our case, with Scrum, if anything is given to us which was not part of the original sprint commitment we add it as 'unplanned work' and our product owners know that unplanned effort added may result in our original commitments not being met. We also have a flat structure in the team, so that no one person should play a managing role and everyone is then motivated to not let the team fail as everyone is equally responsible for the work.


Product owner owns the what part. He is in charge of deciding what items of Product Backlog are more prior to other items, and he is responsible to deliver the product based on the overall available resources on time.

Scrum team (including product owner, and scrum master) are responsible for how part. They should decide how to manage the team, share knowledge, be self-organized, meet daily (daily stand-up), revise themselves (retrospective meeting), have cross-functional resources, etc.

This idea is far from owning a feature, as stakeholders own those features, not me and you bro.


The way I do it, with a low level of pain, is to have each developer be responsible for a card on the board, from when it is picked up from the TODO list until it has moved to DONE. The owner of the feature, as far as what functionality goes into the feature are the Team Lead, SME, and BA. Each team has a Team Lead (the technical expert and advocate), a Subject Matter Expert, and a Business Analyst.

Typically the BA is the guy/gal that fields the questions from the developer currently working on a card. We all work in the same room, so if either the Team Lead (me), the BA, or the SME hear something that we disagree with, we jump in and take the developer into a breakout room to discuss further. Typically the three of us will bring the members of the other three in if we feel they can be of value to the discussion.

Admittedly it sometimes leads to some time wasting while we discuss a problem, but generally we get to a good solution quickly.

Ultimately it is the Team Lead that signs off backlog items as being ready for development and it is the team lead that has the final say when a decisions needs to be made and is responsible if the implementation is "wrong". (Don't ask about the "wrong" blame game :/).

Any other developers hearing the conversation are encouraged to offer input and all team members have input during the showcase at the end of the sprint, when new features are demoed.

tl;dr (for us): The Team Lead owns the features and an individual developer works on a feature card (or bug, improvement, technical debt etc) from start to acceptance by the test team).


The first problem I see is that the estimation process is going a bit wide. Yes, developers should have a say in how much work they should be expected to take on. No, that does not mean that adding a single button to a web form is now a two-developer-week story (however many points that equates to in your business's estimation process). If that's the current state of affairs, then you as the project manager should be doing some second-guessing.

Second, I hear "from start (design) to finish (implementation and unit testing)" and the first thought that comes to mind is "you're doing it wrong". Your unit tests are a part of your design work as a developer/development team, and should happen first; you take the basic requirements, distill them into a simple "checklist" of "If... When... Then..."-type sentences, and then convert those sentences into a series of basic tests that assert the program meets those assertions and therefore the requirements. That happens before you write a line of the production code that will meet the assertions of the tests. If your unit tests come last, after you've already implemented the software, you lose several key aspects of unit testing; in general, your developers can't "program to green", thus providing a minimalist definition of "done" that encourages lighter (yet maintainable) implementations that do what the client wants without wasting work doing more things that the client doesn't want yet (and may in the extreme be unwilling to pay T&M for, because it's not what he asked you to do).

As far as developers "owning" their features, there's a yes and no to it. First off, a pretty common shakeout from "self-organizing teams" is a tendency for developers to go off in pairs or threes and work on things they know best. Assuming you have a good all-around set of developer expertise such that the team can cover all of the work to be done in each iteration this way, you can simply let this happen; it's a good thing for velocity, as developers stay focused on and familiar with the areas of the codebase they've been working in from iteration to iteration.

However, one developer owning one feature for life is a dangerous mindset, because it lowers the "truck number" of your team (defined very frankly as "how many people could be hit by a truck before the team couldn't function, given the worst case scenario of specific people hit and resulting knowledge lost). If the one guy whom you have assigned the "File Import" feature of your software and has owned it for 2 years goes on vacation for three weeks, takes extended FMLA leave, changes jobs, or in the extreme, really does get hit by a truck and dies, now you don't have anyone else who knows that feature because that area of the codebase has been that one guy's exclusive purview for years. While someone else familiarizes themselves with this particular piece of the codebase, you are going to lose significant velocity, and you will also open yourself up to additional problems with defects, as the new guy who's just barely familiar with how the codebase works now may remain woefully ignorant of things he can and can't change within it.

Instead, you should look to cultivate a division of labor that keeps your truck number at least 2 or above, and in a larger team (a dozen or more) closer to 3 or 4. That way if one guy can't do the job, for any reason, there are several other people who can jump in. Sometimes, teams just naturally shake out this way, especially if you bring in a few XP techniques like pair or dojo-style programming (one guy writes in a new assertion based on requirements that the code doesn't meet; the next guy then codes to pass that test, then adds another requirement assertion that fails and passes it on). By definition in these situations, you have multiple eyes looking at the code, developing it, becoming familiar with it.

Overall, the idea of Agile is to promote "lightweight" development. Your team seems to be getting bogged down in minutiae of processes and documentation, when the primary focus, as per the Agile Manifesto, should be on the team members and their interactions, and of course on working, functional code. The processes inherent in Agile are a means to an end, and there isn't any one way to follow Agile; even the primary Agile frameworks like SCRUM are malleable based on your needs as a company, a team, and even from day to day (just make sure to keep the basic ideas of the values provided by these processes at heart when making such changes).


The Agile process is defined by the team for the team following guidelines and it can differ from team to team. In most cases it does, I haven't seen two different teams that mirror the same process in my professional experience. Basically the idea is to have the most efficient development, which in some cases means that different people work on features in the same code base and in other cases one person is the feature owner from beginning until the feature is complete.

Basically larger features (let's call them user stories) can be broken down in smaller user stories and still one and the same person can be the owner of the feature spreading those user stories across several sprints. Also accordingly the person can be a feature owner and not do all the work for the feature. E.g.


  • Large feature estimated to take 6 weeks (3 sprints).
  • The feature is broken down into several user stories each taking up to two days.
  • The user stories include feature development, unit tests, interaction tests, integration (with other features), and integration testing

The team is technically the feature owner but a developer can act like one.

  • The dev writes the functionality
  • The dev writes the unit tests
  • A quality engineer writes the automation
  • Another dev ensures the integration

In this scenario there are at least 3 people (we may have more than one QE on duty) responsible for the feature delivery but the developer is owning and in a sense driving the feature. This, of course, requires more dedication to this specific feature on the part of the developer but it is in no sense out of the Agile scope and at the same time we have single feature owner.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.