There are many opinions as to what the ‘typical’ impediments that Scrum Teams face are; the following list is not exhaustive but covers the impediments that Scrum Teams may probably face:

• Old Habits – During the early stages of an Agile Transformation, when many parts of the organisation are not conversant with the implications of Agile, some business and technical managers expect the Scrum Team to deliver documentation and reports that they are used to.  This can be either impossible or time-wasting.

Also, when DEVELOPMENT Team Members, new to Scrum, are under ‘pressure’, it is natural for them to revert to old work practices because they know them and having to think about and use the new work practices takes more time and increases the pressure.

Solution:

During the early stages of an Agile Transformation, the role of a Scrum Master as the Risks and Issues Manager, is key.

During the daily Scrum, he/she must listen to what the Development Team members have been working on and what they plan to be working on; note any item that does not seem to be adding to achievement of the Sprint Goal and discuss with the relevant developer after the Scrum has finished.  If the item is a ‘hang-over’ from the old ways of working, the Scrum Master must identify the person who asked for the item and engage them in a ‘Scrum Mentoring’ session to explain why their request is inappropriate.

Similarly, the Scrum Master should question any developer that does not seem to be following the Agile and Scrum practices; for example, the developer may be building the user interface for a User Story from his/her own knowledge, because it is quicker, without collaborating with a relevant business person to get the correct information.

• Distractions – 

In ORGANISATIONS that are used to using Matrix Management for resource allocation, it is usual for one person to be working on MULTIPLE product developments or other work.  This causes the individual to become distracted from the necessary work for any one of their assignments which results in reduced quality of their work and more time overall to complete the work.

Solution:

Scrum requires that the Development Team is made up of all the skills necessary for the development and that the relevant resources are dedicated to the product development.

The Scrum Master must work with the matrix managers to assign resources to one product development at a time for the long-term and not assign people based on short-term expediency.

There may be occasions when a particular Development Team member is considered to be the only person who can solve a problem outside of their immediate product development responsibilities; as long as this is to be a short-term (1 to 3 days) commitment, it is allowable but their reduced development capacity must be reflected in the Team’s expected velocity.  If this situation is a common occurrence, it is a significant impediment to the Team’s progress and the Scrum Master must escalate the impediment to the Product Owner.

• Lack of cross functional teams – In the waterfall model of product development, the ‘team’ is not constant throughout the development:

The team member skills are different for each ‘phase’ of the waterfall development process, whereas with Scrum we require all necessary skills to be available at all times throughout the development:

Solution:

As in Distractions above, the Scrum Master must work with the organisation resource allocators to ensure that Scrum Development Teams are composed of members with all the necessary skills for the development all of the time.

• Old HR SYSTEMS – The traditional HR system for compensating employees is based on the individual; their skills, their seniority, their responsibilities.  This is particularly true of ‘Performance Related Pay’; it is a competitive system.

We expect Scrum Development Teams to be self-organising, cross-functional and work in a collaborative manner; traditional HR systems are an impediment to this goal.

Solution:

The Scrum Master must work with the HR department to make them more Agile.  There is a good article from the Agile Alliance, Practicing Agility in Human Resources, to help with this HR coaching.

• ScrumBut – 

The ‘mechanics’ of Scrum are relatively easy to implement but it is implementing the Agile values from the Agile Manifesto, the Agile Principles and the Scrum values from the Scrum Guide that make Scrum work; these values are principles are the hardest part of Scrum to implement because they require an organisational culture change.  Many organisations implement the Scrum ‘mechanics’ and ignore the values and principles and then wonder why this ‘Agile thing’ is not working.

Solution:

It is not possible to change an organisations whole culture overnight!

It is recommended that the Scrum Master, during the early stages of an organisational transformation, focus their ‘culture changing’ efforts on the stakeholders directly involved with a single product development.

Some may be sceptical so the Scrum Master may have to spend a significant amount of mentoring time with them.

Even though the Scrum Master may explain the implications of Scrum to sceptical stakeholders (and developers in some cases), some people do not believe until they see the results.  Be prepared to answer all the sceptical people’s questions but do not let them introduce non-Agile practices.

• Late Attendance in Meetings – 

In ‘traditional’ organisations where there are many meetings, many required meeting attendees get bored and turn up late because they know that the early Agenda items probably have nothing to do with them.

Solution:

• Do not hold meetings!
• Do not have Agendas!

When more than two people are required to discuss a topic or make decisions, hold a facilitated workshop.  Although some say that a facilitated workshop should have an Agenda, the word ‘Agenda’ still indicates to some that a facilitated workshop is just another name for a meeting.  Instead, have clear workshop objectives which are tightly focused around a single topic so that all workshop invitees are motivated to attend on time.

For those people who still consistently turn up late, the Scrum Master must individually mentor the person as to why it is important for them to be on time:

• They may miss something of importance to themselves.
• They may miss something that their input to the discussion would be vital
• Asking to recap what has been discussed in their absence wastes other peoples’ time
• Blocked Work – The development Team will rely on people who are non-team members for information or reviewing of work before they can move on.  Sometimes these people consider their primary responsibilities to be more important than their product development contribution or their supervisors do not allow them the necessary time.
• This results in ‘blocked work’ and will probably be ‘reported’ during the daily Scrum.

Solution:

The Scrum Master, as the Risks and Issues manager, must work with the affected developer to RESOLVE the problem and if the resolution is not successful, he/she must escalate the problem to the Product Owner (PO) who may have to use their seniority and company politics to resolve the problem themselves.

Remember that the PO is solely responsible for ensuring the best business value emanates from the product development; blocked work reduces business value.

• Supplier Issues – Similar to Blocked Work above, the Development Team may have to rely on parts of the product development solution that they have to integrate with being supplied by other teams; these teams may be internal or external to the organisation.
• The suppliers may or may not be using Agile or specifically Scrum for their development work.
• The other teams may deliver their parts late with respect to the plans or the delivered part may not be of suitable quality.

Solution:

The process for dealing with Supplier Issues will probably be different between ‘internal’ and ‘external’ suppliers.

• For ‘internal’ suppliers, the first action would be for the Scrum Master to discuss the problem the Project Manager or Scrum Master of the ‘internal’ team
• For ‘external’ suppliers, the first action would be for the Scrum Master to approach that part of the organisation that let the contract to discover the dispute process and to follow that 

In both cases, if resolution is not possible and given that there is Programme Management in place, the Scrum Master should escalate the problem to the PO and facilitate the problem resolution with the Programme Management.

A longer-term solution to minimise Supplier Issues is for the organisation to have all ‘internal’ suppliers using Agile techniques and only use Agile Contracts for engaging ‘external’ suppliers; you can find more information about Agile Contracts at Agile Contracts or Agile Statement of Work - Must-Haves and Agile Contracts - The Foundation of Successful Partnering.