How to Fix Problems on an Agile team - Examining the Evidence
In this article, I discuss how we can look at the artifacts produced by an agile team, to assess the fundamental health of the team and the business value the team can produce. Then, I offer a means to fix the underlying issues that we discover as symptoms of the problem. Here is one example of a practical approach at looking at some specific assets and artifacts, tracing back to a possible root cause, and an idea on how to fix it.

Artifact                       Cause                                  Fix

Engineering Debt                   Not refactoring design iteratively        Train developers in refactoring
Developers need to understand what it means to refactor a piece of code. It isn't enough to explain what refactoring means without giving some good examples. Many times I have seen what I call "superficial refactoring" where only a few things are touched, so as to minimize changing the code that's already there. I have heard developers say "well, I don't want to touch that code because [it is currently working | I don't have time to fix it | I don't understand how it works]" so, they leave it alone and just add their blob of new code, which now sticks out like a wart. It was not part of the initial design, and now that the initial design is obsolete (in some form), we now have engineering debt in that the design of the old code was not updated to reflect the now new "whole" image including the new functionality. Watch out for superficial refactoring, and if it happens - be sure to train on how to do a complete refactoring. Note: this might cause developers to estimate stories higher, since they will be thinking more of the actual work needed to be done...

Lots of Bugs                           Not enough tests                                 Unit test, use TDD, train developers in testing techniques (use QA to help)
Test Driven Development is a good mechanism for reducing bug count. But, sometimes it is a hard-sell to developers who have been "traditionally" trained. Also, sometimes it is a hard-sell to management who will only see that it is taking longer (at first) to get main line code written. Over a few weeks, lights will come on for developers, and they will begin to see the benefits of testing the code first, and letting the code evolve as a response to the tests. Bugs will be much fewer, because the developers will need to consider more things when they write tests. Having a QA person assist the developers in writing these tests can be very beneficial as well, as they will be able to give guidance in testing appropriate areas of the code such that bugs will not be written into the software in the first place.

Failure to Complete Stories      Stories Too Big / Too vague               Focus on DONE criteria, swarm on stories, better task breakdown in planning
I see not completing stories is a process smell. There are a variety of reasons this might be the case. Perhaps the team does not have enough clarity on what actually needs to be accomplished in the story. This is usually evident if the planning for a story goes very quickly and no/few tasks are broken out. Also if stories are too large ("epic" stories) we should break them out into separate smaller stories that are easier to estimate. Many times during a sprint, I have to add tasks to a story because I hadn't thought enough through the component pieces that needed to be modified until I actually got into the work of the story. Sometimes this is unavoidable, but mostly I consider that I should have spent a bit more time in planning for the story so that I had a better grasp of the work involved. If I get my team to help me work on tasks on a story rather than starting a new story ("swarming"), this can be an effective means to get stories done. This is not always practical, as some stories have tasks that are very interdependent, and it's difficult to get a lot of people to be able to work these effectively. However, if the team has enough discipline, focusing on stories that aren't completed before starting new ones is a great way to have stories finished at the end of the sprint.

Customer Dissatisfaction          Customer is not the Priority                PO focus on customer value, get customer in the room
The customer (or stakeholder) doesn't like what the team produced. It can be a variety of issues that causes this problem. Perhaps the PO didn't get the right idea from the customer. Perhaps the ideas did not get properly communicated to the team. Perhaps the team is more interested in some technology than giving the customer working software... Sometimes relevant stakeholders (Operations or Management, for example) were not involved or represented by the PO adequately. The team needs to make sure they understand what the customer's priorities are, and why. Satisfying the customer also must be the primary focus of the team. This information should be given to the team during planning, by the PO. The team then has the opportunity to ask all the questions they need, to be able to understand the customer's needs fully. The PO and the customer should be accessible by the team during the sprint, so that if there are questions that come up during the work, they can have answers in very short order.

Use these strategies as a starting point for assessing issues. These aren't the only things that can be analyzed, but in my experience I have seen all of these come to light on one team or another. These are only starting points, ideas to get an analysis moving. Please respond with comments if you have some different specific experiences that could help other readers as well.