An Agile Coach is a talented professional developer who is brought in to a team to help them raise their bar of excellence. This person is a servant-leader, an advocate, a teacher, a helper, and a technical resource as well.

A coach is there to guide the team, help them to do their best. This should be true of a coach on any team. An Agile Coach is someone who is well versed in the practices of an agile developer - XP, SCRUM, LEAN, etc. They have been around a few blocks and have some experience in various teams in various circumstances.

This person is sought out for their experience and their ability to convey their knowledge in a positive way. They are an active and participating member of the team - not someone on the outside. The Agile Coach should be developing code right along with the rest of the team. Sometimes the coach can be the team's representative to outside meetings also, where a developer is needed rather than a scrum master.

The coach should work directly with the scrum master, and be aligned in being able to protect the team from outside influence, as well as randomizations from meetings and questions from other groups. The Agile Coach should show leadership in how code should be written, and the behavior expected from the development team when it comes to coding both main-line and tests.

The coach should encourage continuous learning and growth, facilitating this wherever and whenever possible. He should encourage the team members strive to improve, while being there to assist and support them while they do, and ensure their success. The coach should set the tone for the team in modeling the attitude that will best serve the client, customers, and users.

COACH: Champion, Observer, Advocate, Cheerleader, Helper

If a story has some defects logged against its implementation, does this mean it's not done? What does your [DoD] Definition of Done say about this? If a defect is severe or blocking other teams or other testing, then I would agree that the story really isn't done. In that case the team should probably postpone other feature work and focus on fixing the defects. However, if the major business value is still delivered and the main functionality is not adversely affected by a defect, then I would support the story being called Done (all other done criteria being met of course).

The product owner of course will want perfection... this is to be expected. There is a line however, somewhere, that separates a story from done to not done. However "no bugs" is probably not it... minor defects that do not block the major functionality, other teams, or other testing / features should be logged as defect stories on the product backlog, prioritized highest (even above other high-demand features) unless they are so minor that the story could ship to production even with the existing defect uncorrected.

Perfection is not in the Agile Manifesto the last time I checked... however the defect vs. done issue continues to remain a gray area.

The recommendation is this: classify defects based on a priority.

Pri-0 - blocking bug, drop everything and fix NOW.
Pri-1 - non-blocking but serious bug, broken functionality. Fix ASAP.
Pri-2 - non-blocking with work-around. Fix when possible.
Pri-3 - non-blocking minor issue, does not block functional testing. Fix if possible.

I support the in-sprint fixing of Pri-0 and Pri-1 defects, but any else should be deferred to another sprint. DoD should include this as a working agreement, and any reasonable [practical] product owner should approve.

So, what's in your Definition of Done?