There are many challenges facing self-organising teams which can be grouped into the following categories:

Organisational inertia.  In organisations that have been around for some time, the way that things are done have become habits; many supervisor and management personnel are reluctant to change from fear of their job changing significantly or disappearing altogether

Individual Team members’ inertia.  Individual Team members may have fears about:

• having to learn new techniques
• accepting greater responsibility
• learning to cooperate with other team members more
• taking on activities outside of their specialist skills

A Scrum Master must be aware of these potential challenges to self-organisation, look for signs of them and help both the organisation and Teams to overcome them.

Below are 3 typical challenges faced by teams and the possible help that a Scrum Master can give:

• Bad Forecast:  In the early stages of an Agile transformation, the Teams may be asked to estimate using Story Points, relative estimating, instead of the conventional task estimates that they have been used to.  This technique requires practice to become proficient and early attempts may result in the forecast at Sprint Planning for Product Backlog Items (PBI) to be attempted being significantly in error, generally, Teams tend to under-estimate.  This may demotivate some Team members and make them question the use of the new technique.
• Solution: During the early SPRINTS, at the daily Scrums, the Team will realise that their progress toward the agreed Sprint Goal is slower than they would LIKE.  As a Scrum Master, you should ask the Team if there is anything they can do to improve progress; some changes could improve progress.  

However, the time to address the UNDERLYING problem to do with estimating is during the Sprint Retrospective when the estimates for each Sprint Plan PBI should be compared to ‘actuals’ to see if there was any common reason for the estimates being inaccurate or if there were one or two ‘one-off’ estimating mistakes.

If there was a common or systemic reason for inadequate estimates, the Team must re-estimate the Product Backlog in the light of the new evidence; if the errors were due to ‘one-off’ inaccuracies, the Team should re-estimate similar User Stories in the Product Backlog.

Emphasise with the Team that nobody is expecting ‘perfection’ straight away; the importance is that they take time to learn from their experience and apply that learning going forward.

• Technical Debt:  We build products incrementally; ‘only do today what you need to do today’.  It is probable in later increments that some code that worked for a previous increment no longer works for the current increment so the code is changed.  Over time a single method in the code may have had SEVERAL ‘patches’ applied to it so that becomes difficult to read and restructure when further ‘patches are needed; this may cause de-motivation in some Team Members and even cause arguments between them about the state of the code.

The programmers aim is for ‘clean’ and simple code but the temptation is to produce something that works now without considering future maintenance needs.  The fact that the resulting code may not be ‘clean’ and simple is known as Technical Debt.

• Solution:  Resolving Technical Debt costs time and money; the longer you leave the resolution, the more time and money it costs to resolve.

There are 3 suggested solutions that a Scrum Master can encourage the Team to adopt to address potential Technical Debt problems:

• Definition of Done (DoD):  Ask the Team to add an item to the DoD to ensure all new or changed code is peer reviewed to ensure that the structure is ‘clean’ and any potentially reusable code fragments are refactored to their own method.

Do not let the Team wait until the end of the Sprint to do the code reviews, have them do it once the programmer believes that he/she has finished.  In this way, there is the shortest time between ‘finished’ and any refactoring that may be needed.

• Pair-Programming:  The idea of two programmers working side-by-side to develop one function may seem counter-intuitive; it would cost twice as much to produce the code.  However, in the medium to long-term, Technical Debt may be reduced or even eliminated when one programmer is looking on and offering advice to the programmer at the keyboard.
• Test-Driven Development (TDD): 

With TDD, no line of production code is written before a test has been written to test it, the test is run and is expected to fail.  Only enough production code is written to pass the test. See Test-Driven Development.

Practicing TDD does require an Integrated Development Environment that supports it and to be successful, all programmers must have the discipline to use it.

Initially, some programmers may be reluctant to use it because of the perceived extra work; however, when they see that the maintenance effort is reduced by more than the extra initial work, they come to accept the practice.

Team Member Leaves:  Each Team member has a list of responsibilities and capabilities including their own specialisation, DoD checking and contributing to work outside of their specialisation.

The Scrum Master should keep a list of all these responsibilities and capabilities so that when a Team member leaves the Team for some reason, the REMAINING members can distribute the leavers responsibilities and capabilities amongst themselves.

If it is not possible for any of the remaining Team members to take on any required responsibility or a required capability is not available, the Scrum Master must raise this as an issue with the Product Owner and management; a Team member training may be the resolution to the issue or an additional Team member may be introduced to the Team.  In the latter case, the Scrum Master should monitor how the ‘new’ Team are managing their self-organisation.
See also Self-organizing teams – Challenges and Strategies.