This article is part of our project management methodology series.

You will find Scrum to be lightweight and simple in its setting, providing you with basic rules and practices to get started. However, mastering it is not so simple, and it will certainly take time and effort.

As soon as you start applying it, real life challenges may jump up and punch you in the face! Even though Scrum was developed to meet such complexities, at the end of the day it remains just a framework where most of the “hows” are not specified.

It’s a means of transport rather than the destination.

Scrum can’t fix every problem, but it will help bring them out into the open. The real mastery of implementing Scrum comes from understanding the fundamentals, facing different challenges and overcoming them as you go.

One thing is certain – Scrum will not fail you. It is designed to work for you, but it’s up to YOU to make sure it actually does.

So, now that we’ve learned the basic Scrum roles, ceremonies and artifacts in our previous article, let’s address the most common challenges that organizations and teams are faced with during implementation.

Let’s start off with some challenges in “mindset shifting”.

#1 Resistance to change

Some of the very first roadblocks on your way to the ever so idyllic “Agile Land” are ingrained deep down in the inability to change organizational culture, or a company philosophy that is in contrast with core agile values.

There’s also the possible issue of trying to fit agile elements into a non-agile framework.

Closely related to the organizational culture is the general resistance to change. Change is inherently difficult and uncomfortable, people fear it and shrink away from it.

It’s fair to say that many employees tend to be rigid when it comes to disrupting their comfortable routines! And who can blame them really?!

This can be a really significant challenge, especially for team members who have a long history of success with the traditional approach. In this case you might face a “this is how we’ve always done it” attitude.

For established organizations, Scrum may prove challenging to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. It can be easy to end up with egg on your face!

Switching your organization to start using Scrum requires a fundamental mindset shift which will shake-up old habits and transform them into more effective ones.

Ultimately in today’s rapidly changing market, business stagnation means extinction.You wouldn’t be considering Scrum if change wasn’t needed. In order to improve, you must be willing to change.

From this perspective, it’s clear that change is inevitable, although our human nature is to resist it. As a change agent, you will need to be smart when deciding how to be proactive in dealing with the resistance to change within your team.

You will certainly need to lead by example.

Great things never came from comfort zones

The first step is to understand exactly why individuals are resistant to change and what their true feelings are about adopting Scrum. You can do that by digging down to the root cause of people’s resistance, learning from it and finding ways to help them overcome it.

With that in mind, you might like the story about “Boiling a live frog”.

How do you boil a live frog? Well, if you throw a live frog into hot, boiling water, what do you expect will happen? The frog will jump out of the pot…so the story goes. A better way is to first determine the level of temperature the frog is acclimatized to. Then make the first small increase from there. After a while, the frog acclimatizes to this slightly higher temperature. Then we raise the temperature again, doing this in small increments each time. We do this until the frog gets cooked without even realizing it.

Poor frog. The point is, rather than going with the “Big Bang” approach when adopting Scrum in your organization, you should consider doing it at an incremental pace. That means you should start small, involving one of the teams (preferably consisting of enthusiastic individuals) in the pilot project, and then showcase the results of the initiative and let “word of mouth” induce others.

To ensure everybody gets enlightened in the proper way, consider hiring experts who can help you with specific practices through training and coaching, especially in the early days.

It is also good to have open-minded individuals in senior executive seats, preferably good communicators, who are able to set the right organizational attitude for embracing the change.

Following on to the next challenges, you will find more regarding people issues. At the end of a day it’s all about people.

#2 Distributed team

There is a common perception that the co-located Scrum team is better suited to ensure good communication and deliver better output than the distributed team. Technically, Scrum allows team members to be in different places, yet it is important to point out the certain challenges that distributed Scrum teams are faced with.

Communication is the core issue among distributed teams. Different time zones and conflicting working hours may impair overall effectiveness, and collaboration may be difficult in some cases.

There can be delays caused by lack of communication, meaning parties may need to wait before proceeding with the next stage of their assignment. Often, people are interacting at unsociable hours due to time zone issues, which can lead to poor quality communication and sustainability, which ultimately affects productivity.

With distributed teams in different locations, inevitably cultural differences and language barriers can also create misunderstanding and in some cases confusion. This may result in unnecessary errors or again, slow down progress.

In addition, team members in different regions generally have varying degrees of skill and technological expertise. This can create a class system between different remote teams and also hinder collaboration efforts. Team members may also have divergent preferences about technologies.

On the other hand, there are obvious advantages to keep in mind. A distributed team can be more cost-effective, and can also provide access to higher skills. They can also reach the market quicker in some instances with a “follow the sun” model.

Make sure everyone’s on the same page

When it comes to assembling a distributed team the key focus should be on building trust and having mutual respect for each other. A common focus on communication is essential.

Giving team members ownership over their own work is a sure fire way to increase commitment and motivation levels.

In distributed teams of differing nationalities, it is inevitable that there will be different traditions present from one location to another, therefore it’s essential to be considerate of these.

Regardless of such traditions and cultural differences, the basic expectations of trust and co-operation need to be apparent to all across the board.

Some practical solutions to improve work output across distributed teams may include:

Boot camps

Why not get the whole gang together in one location (where possible) and get to know one another? Maybe even blow off a little steam with some fun team building exercise once the working day is done!

There are many benefits of a kick off session; a clear understanding of customer goals, expectations and a shared enthusiasm. Tooling, architecture design and standards may also be discussed and agreed.

Rotating local team members

A great way to collate lessons learnt and share experience across the board is to have a designated member rotate around different locations, working alongside each resident team on a temporary basis.

Bridging time differences

For members working in different time zones, overlapping hours may be required. In such situations, each member will require video conferencing facilities, desktop sharing abilities and instant messaging software.

This also ensures team members can teach each other swear words in their native languages! Not that important, but it’s a hell of a lot of fun.

Remote pairing

If a critical issue arises, it is essential to have teams paired across different locations. When one member is clocking off for the evening, the corresponding team member who may be starting their work day across the globe can take over and run with it.

Remote pairing needs to be disciplined, and carried out frequently on a fixed schedule to avoid work conflict.

Technology alignment

It is essential that coding standards, frameworks, tools and engineering best practices are agreed and adhered to. It’s just common sense, and professional.

#3 Changing team membership

Some agile organizations still have the tendency to tackle resourcing problems by changing the team membership due to the constant effort to provide maximum business value for the stakeholders. No hard feelings but, giving that motive the resource change happens to be a necessary evil.

Though Agile teams are designed to face the change, ironically most of them are not comfortable when the change affects the team.

What happens is that this breaks the Team’s rhythm and may disrupt the Team Velocity.

The essential effort in Scrum is to keep the team focused full time on their success. Along the way, the Team will go through the stages of Forming, Storming, Norming and Performing. In order to reach the Performing stage, there needs to be stability.

Team membership changes, task switching and other such fluctuations harm the team stability, making it more difficult for a team to “gel” over time.

Elimination of a team member has its consequences. Sometimes people simply leave. Other times, action is taken to remove an ineffective member of the team who is dragging everyone else down.

The addition of a new team member who doesn’t understand the basic process may also have the same hindering effect. Not only is there a settling in period for the new member,but other team members must also re-adjust to the new team dynamics.

In the unlikely case where a team is not able to support the requested work, then, the problem needs to be bridged by adding a specific skill set to a team.

It is important not to assume that when you make a change to the team that you’ll see an immediate improvement. In some ways this is validation of Brooke’s Law.

Ensuring everybody speaks the same language

Even if every team has different work ethics, different cultural backgrounds or different processes, basic Scrum practice remains constant and allows for easier assimilation.

Making sure that every person in the organization has gone through Scrum training will help staff retention. It also means that it’s easy for people to move around teams as they have a common set of Scrum practices.

It’s the Scrum Master’s call

It is the Scrum Master’s responsibility to manage the team through the change. After the change has occurred, the Scrum Master should make note of what team members found to work in their previous team, and what they would like to continue or change, with the current team going forward.

So, who’s responsible for making these changes?

Voting someone off the island so to speak, or removing a team member is not up to the Team members to decide. However, open discussions may take place and one on one meetings should encourage any potential concerns to be addressed.

Ultimately, it’s the call of the senior leadership of the organization. It is their responsibility to ensure that the right team members are on the board while monitoring team dynamics.

Moving on to the hands on challenges…

#4 Wasteful daily Stand Up meetings

Scrum considers an efficient daily stand-up meeting to be 15 minutes maximum. Is that possible? Well yes. Is it likely? I think you know the answer to that!

How many times have you experienced a meeting that just goes on and on….and then on some more? Imagine being stuck in a daily Stand Up meeting with a Scrum team of 9 people each having their 5 minutes of fame (at least). You end up standing there for 45 minutes or more getting tired legs, about to fall over listening to issues you’re not involved in. We’ve all been there.

Honestly, you’d think the team are trying to hatch plans to take over the world, rather than discuss the daily issues. Then, just when you think you’re almost done, old Joe there from QA pipes up for 10 minutes about how he had to take his pet hamster to the vet last night after the cat jumped out from behind the sofa and gave it a heart attack!

Really? Just get on with it. You think they’d realize that the coffee back at your desk is getting cold. How inconsiderate!

You’re smiling because it’s true. Admit it.

All joking aside though, this is actually a very common pain Scrum teams are faced with. Time equals money, and this is an unnecessary expense. Standing around talking about pets that is.

Aside from the fact that your team is probably too large, you are also letting everyone in the Team do ‘deep dives’ of their current work, having time consuming discussions around problem solving. And then some individual issues arise:

Let’s say one team member doesn’t know what to do next. That may lead into a full blown discussion then and there, with colleagues each adding their opinions. Before you know it, the whole project is being re-planned!

Another issue is the realization that the Daily Scrum shouldn’t actually be daily because it’s taking so long. It’s important to remember though that it’s not Scrum anymore if your team doesn’t meet together daily.

Play it by the rule

To have an effective daily scrum, team members must understand it’s purpose first and foremost. It’s each member’s responsibility to adhere to the necessary discipline to keep the conversation focused.

Daily Stand Ups provide a mechanism to ensure that each team member has an understanding of what work has been done and what work remains. Daily Stand Ups are not status meetings and they are not meant to inspire discussion or problem solving.

Issues and other discussions can and should be deferred until later, after the daily scrum is closed and involve only the necessary parties.

With a planning board (Kanban), a Daily Scrum can often be done in less time. If you want to know what someone did yesterday, and what they are going to do next, you will be able to see it on the board, where it should be recorded.

Any issues may also be recorded on the board. This way daily meeting discussions can focus only on current work in progress any potential issues or roadblocks.

#5 Handling bugs and urgent on-demand tasks

So your team started a Sprint which assumes there are no changes expected during that time, but what are you supposed to do with those unexpected, urgent requests that customers and technical support is throwing at you?

And what about a bug that came out of the blue or from emerging from something the team wrote months ago?

Not all of these issues can wait for the next Sprint. Some of them can be filed in the Backlog and wait for their turn, but some have to be handled as soon as they arise, potentially even “in real time” as per clients’ demands.

This is far from the peaceful environment that the Scrum Master’s are trying to provide to their team, while protecting them from different interruptions during the Sprint.

Remember, the basic idea of Scrum is to create a secluded environment that enables a team to focus solely on the planned development tasks. Iterative product development asks for consistent priorities to reach the success.

Before we proceed with the solutions it’s important to use some common sense as well. For example, things might change within a Sprint if there is good reason for them to change and it can be justified.

Ultimately, the goal is to build the right product. Blindly following a process probably will not make us as Agile as it takes to deliver value for the customer.

To the Batmobile!

Get your tights on and don’t forget your cape! Perhaps this week you’ll get to be Batman. That’s right, within Scrum there is a new “Batman” every week. No it doesn’t mean you get to roam the streets of Gotham City after midnight and save a damsel in distress. You do get to fix bugs though!

Each week, the Batman of the group abstains from partaking in any scrum tasks, and instead focuses all their attention on the ‘stuff that just crops up’. Bug fixes, urgent requests and general support. It’s the stuff of Superheroes!

Of course, Batman wouldn’t be Batman without Robin. As Batman’s “right hand man”, Robin is there to help out when Batman can’t handle the pace. Teams should certainly also consider assigning a Robin who can be called into action by Batman when emergency strikes.

Allow time for bug fixes along the way

Inevitably as the project moves forward, bugs will appear out of the woodwork. Perhaps not so many in the early stages of development, but certainly as the project is nearing a production release. Therefore, it’s a good idea to increase the time allocated for fixes as development progresses.

It’s advisable to consider dividing your Sprint into two separate components:

• Work outside the normal product backlog or the Bug Backlog
• Product Backlog Work

It’s essential to allocate time and resources accordingly to Bug Backlog work. (e.g 20%)

Then calculate this capacity of work per Sprint in hours.

#6 Integrating testing in Sprint

How can QA engage effectively during a sprint before anything has been built and what are the developers expected to do when QA is taking place?

One of the most common problems facing Scrum teams is when developers finish their job on the last day of the Sprint and then hand over it to Testers, putting them under pressure to finish testing in such a short time.

Similarly, testers on such teams struggle to figure out what are they suppose to do earlier in the Sprint, while there are still no work items to be tested.

Many teams find it challenging to create an increment of software and make it releasable. Releasable means it includes writing code, performing functional and regression tests, and gaining the approval of the Product Owner.

This becomes especially challenging when it is set to be realized in a relatively short two week iteration.

What usually happens is they deliver incomplete items containing a workaround of the agile approach, which contradicts the purpose of Agile in itself.

Development and testing tasks should be integrated

Testers should be included in the early stages of design with developers to agree on testable features and a test criteria.

The QA team need to run continuous integration every day, and leave their hamster issues at home to concentrate fully on development and testing. This ensures there is a solid feedback loop with developers and everyone feels like part of the same family.

On the same note, developers need to be more sensitive to the needs of QA and work with them during testing tasks. Fair is fair. It’s for the team’s greater benefit that different departments work closer together, rather than pass things along and wipe their hands of it.

Saved testing and bug fixing cycles occur when developers consult with QA over acceptance behavior of any functionality, from the user’s perspective.

Encourage developers to handover smaller chunks of work to testers as they go along, as opposed to dropping a bomb on them at the end of the sprint! While developers are working on code, testers can simultaneously prepare tests and write automation scripts.

Once this smaller section of work passes testing, then both the developer and tester may decide on what to tackle next based on high level acceptance tests defined by QA.

Once all User Stories are complete and have been Accepted then the sprint is over. Then, repeat and begin the next one. Simple.

…

So there you have it!

Now it’s up to you and your team to put the theory to work and become experts. We’d love to hear from you in the discussion section at the bottom of the page if you have any experience of the above issues, and how you overcame them.

As always, we’ll be providing you with more solid articles to help you in the coming days and weeks. Simply leave us your e-mail address here and we’ll keep you posted when our next article is published.