The following are misinterpretations or breaking of the Agile Principles and suggested ways to fix the problem(s):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   Some people focus on the ‘happy customer’ aspect of this Principle and will do whatever the customer asks.  This may make the customer happy in the short-term but the real value to the customer is delivering valuable increments of the product as early and continuously as possible.
   The fix – ensure the development team and customer agree on a regular Sprint and Release Schedule and ensure that they keep to it.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
   Some Agile teams understand the word "welcome" here as permission to forget about any requirements management at all. What is the easiest way to welcome change? Obviously, just get rid of any required documents!  However, this Principle does not mean abandoning any requirements management process.
   The fix – Ensure that the Product Owner maintains an ordered Product Backlog and that all change requests are handled by the Product Owner; the PO will decide if the change is justified and if it is whether the request is important enough to interrupt the current Sprint or whether it is placed on the Product Backlog in the appropriate business value position.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
   There may be some Development Team members that think this Principle applies at the Development Team level but does not apply to themselves individually.  It is difficult to imagine how these people think that the team will deliver without their individual contribution!
   The fix – Ensure that all Development Team members attend Release and Sprint Planning workshops and contribute effectively.  Additionally, ensure that all Development Team members attend the daily Scrum; it will soon become obvious if an individual’s progress on their chosen activities is less than ‘optimal’.
   The Scrum Master should engage any ‘miscreant’ Development Team member in individual mentoring to discover what the underlying problem is that is causing the problem and help the person to improve.
4. Business people and developers must work together daily throughout the project
   Working together doesn't mean working without clearly defined rules and processes. Some teams interpret this Principle as the legalization of chaos; they think that, since we work together, we do not need to define roles, we should not document requirements and we should not care about responsibilities.
   This is clearly nonsense; Agile requires that all the responsibilities necessary for successful product development must be identified and an individual or group of individuals take on one or more of those responsibilities.
   The fix – As a Scrum Master, for new Scrum Teams, ensure that a workshop is held with the Scrum Team and key stakeholders to define all the necessary responsibilities and ensure that all the responsibilities have been accepted by one or more people appropriately.
   Do not allow individuals to ‘quote’ their named role job specification in an attempt to avoid responsibilities; if they have the knowledge and capacity to fulfill a responsibility outside of their job specification, then they could accept that responsibility.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done
   It may be difficult for some ‘managers’ and ‘supervisors’ in the early stages of an Agile transition to ‘let go of the reins’; they are used to assigning low-level tasks to individuals and monitoring their work closely; their implies a lack of trust on their part in the ability of individuals and teams.  Agile teams should be self-organising and self-managing.
   The fix – As a Scrum Master, you must closely monitor the activities of ‘managers’ and ‘supervisors’ and if these activities are disruptive to the Development Team, then you must mentor the individual ‘miscreants’ to explain the Agile philosophy and Principles to them how their ‘interruptions’ are causing delays in development progress.
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation
   Face to face does not necessarily mean that all people contributing to the conversation being in the same room; some people believe it does and use this to avoid Agile when all people cannot be in the same room.
   However, technology has moved on since the Agile Principles were written; today, communicating by video-conference and desktop sharing facilities is commonplace.
   Video-conferencing is preferred over teleconferencing because with the latter, you lose the ability to observe ‘body-language’, an important part of any communication.
   The fix – As a Scrum Master, if communication with remote people is needed, whether within the Development Team or with stakeholders, encourage the use of video-conferencing at a time that is suitable to all the people in different time-zones.
7. Working software is the primary measure of progress
   This Principle states that working software is the primary measure of progress; it is not the only METRIC we can use to analyze product development.
   The Development Team measure and use their Velocity to help them plan; the business (product Owner) measures the benefit achieved from released increments.
   The fix – As a Scrum Master, you need to ensure that the Development Team and Product Owner agree the metrics that are to be used.  You must help to ensure that the metrics are measurable, relevant and are of value.
   You need to make sure that collecting any metric may have the effect of changing peoples’ behaviour; for example, if the number of lines of CODE per day was to be measured, developers may use verbose coding practices thus reducing progress and technical quality.
   The focus of any metric chosen must be its contribution toward the overall business value accruable from the product increments being delivered.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   This Principle focuses on the wellbeing of all involved with product development but it must not be forgotten that the prime focus of product development is to deliver value to the ‘customer’; the Development Team cannot just keep working at a comfortable pace if they are not meeting the ‘value deadlines’ set by the ‘customer.
   The fix – As the Scrum Master, you need to ensure that the Development team estimate the Product Backlog Items and agree with the Product Owner what is possible in a fixed time and what is included in the Product Backlog MVP; ensure that the Product Owner is aware of his/her responsibility to measure the rate of delivery of business benefit.
9. Continuous attention to technical excellence and good design enhances agility
   This Principle means that there must be technical ‘rules’ in place that must be checked for in each developed requirement source code before it can be considered “Done” and allowed to be reviewed by stakeholders.  If these rules are not in place or they are not checked for, then the quality level will decrease resulting in an unhappy ‘customer’ and reduced progress as required REWORK is done.
   The fix – As the Scrum Master, encourage the Development Team, Product Owner and technical advisors to agree what the technical and design quality criteria are and how they will be checked for; the agreement forms the “Definition of Done” (DoD) that each requirement and increment will be checked against before it is reviewed by stakeholders.
10. Simplicity--the art of maximizing the amount of work not done--is essential
    To some developers, it is tempting to ‘future proof’ their work, adding functionality that may be or known to be needed later.
    This results in slowed progress and potential work when the perceived later need does not transpire.
    The fix – Ensure that there are some DoD criteria that check for future-proofing in the required source code.  This will encourage developers to:
    ‘Only do today what is essential to do today’
11. The best architectures, requirements, and designs emerge from self-organizing teams
    We say that the Development Team should be self-organising for the work that they do during Sprints but they are subject to constraints such as:
    • The overall technical architecture to work within; set by corporate tech architects.  The Development Team can ASK for amendments to the technical architecture but they have no control over it.
    • The requirements – Requirements are the Product Owner’s responsibility; the Development Team can suggest changes to the Product Backlog but they only have control of how the agreed requirements are implanted.
    • The design – There may be corporate design standards in place; again, the Development Team can suggest design changes but only have control over how the agreed designs are implemented.
      This Principle not just about the Development Team; the self-organizing concept applies to the wider group of business and technical stakeholders that must work closely together so that the product can provide the best business value.
      The fix – As the Scrum Master, you must analyze any constraints that the Development Team have to work with and ensure that adequate processes are in place whereby requested changes are speedily analyzed and accepted or not.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
    This Principle is embodied in the Scrum ‘Inspect and Adapt’ Pillar and is enacted through the Sprint Retrospective event.
    The Sprint Retrospective is not just about discussing what is wrong but also what is good and maybe the team should do more of.
    At the start of an Agile Transformation, the team may ‘find’ many things that are ‘wrong’; the long list may be seen by some to be time wasting and others as demotivating; ‘how are we going to address all these problems?’.
    Because of this, many teams give up on the Retrospective!
    The fix – The discovery of good and bad things during a Retrospective should be time-boxed to maybe 15 minutes when the major points will be discovered.  There are many Retrospective Games that can be played by the team members to make the discovery more enjoyable.
    An important part of the Retrospective is that the team prioritize the issues and plan how to resolve the top 1 or 2 issues in the coming Sprint.
    Progress on issue resolution can be done during the daily Sprint and the overall success of the improvement plans checked at the start of the NEXT Sprint retrospective.