It's often that Scrum teams fail to appreciate the effect of adopting agile. They can't see an increase in productivity, an enhanced level of trust with the customer, or improved quality of the end product, all of which happen to be key objectives of agile. Teams are left pondering as to what is going wrong with their adoption of agile and Scrum. They plan before starting the sprint, have standups on time, have frequent communication with the customer, yet a lack of the wow factor makes one think, "why am I doing it." Most often these problems arise when we abide by all the Scrum practices but forget about doing programming in an agile manner.
Agile is recognized as a system-software development approach used to get quick feedback to keep the customer involved at every stage, building a disciplined team, and having working software at any given point in time. Extreme Programming (XP) is vital and necessary part of agile product development. These goals would impossible to achieve if the programming part is lacking agile. Let's see how things start falling out of place when agility on the programming side is ignored.
It all starts here
We always talk about agile being a mindset, not a methodology. This could only be true if we start contributing every single thing the agile way, including programming. As we expect to get feedback from the customer promptly, we should also strive to get the feedback from the code itself. For example, if we are not doing test driven development (TDD), we are not focused on defining what the code needs to do before writing the code itself. This is a differentiating feature of TDD versus writing tests after the code is written. It makes the developer focus on the requirements before writing the code, a subtle but important difference. Instead, programmers write the test cases as per the code written already. In this situation, the test cases become compliant to the implementation instead of the requirement. This is one evidence of breaking the trust. A team that doesn't have confidence in the code written by themselves, can't really expect the customer to put faith in them.
Writing the test cases as per the code written already, as discussed above, leads to code with more bugs, I won't say that doing TDD is going to get rid of defects completely, but it definitely keeps them at a manageable level. Having more bugs in the code would require an extra effort over the estimated time from the programmer to fix. This time would come from the effort estimated to complete other stories. This puts extra pressure on the developer, which would eventually increase the probability of him/her making more mistakes. More bugs with the next story, that will need more time to fix, and finally the programmer gets caught in this vicious circle.
A way out?
In the retrospectives the blame would be put on the sprint estimation (which still might be true!). But even if the estimates were conservative and correct, the above situation would still occur at some point sooner or later. This might lead the team to re-estimate and reduce the sprint velocity, which is only going to harm the team with loss in the productivity, or maybe bring in a test engineer, which would increase the cost (something that the customer is certainly going to hate). If this is the way the team is going to react, we have another problem to deal with: a failed sprint retrospective.