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.

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.

Scenario:

• 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.