What are the challenges of introducing Agile Scrum to a team?

Introducing a whole new methodology to a team presents many challenges, particularly an Agile one such as Scrum. Some of the challenges are practical ones, such as which tools to use, but many are emotional ones.

As soon as you begin to introduce change to a group it provokes very diverse responses. Some people embrace it and see it as a step forward. Others are happy to go with the flow and wait to see what happens. However some are completely resistant to bringing in a new way of working.

Difficult to grasp

When we first introduced scrum in our team some developers just couldn’t grasp how an Agile methodology would work. How you could develop software without a fully worked out plan of the final product, or at the very least the detail of the full functionality of each feature?

Planning work for each sprint was very difficult at first. Some developers found it difficult to leave behind our disorganised, waterfall-by-accident way of working. It was disorganised, but they knew exactly what they had to build over the next 3, 4 or 6 months.

The very idea of only doing the small iteration of work that was described in each of the current tickets led to lots of questions about “what happens when…?”, “how do we plan for…?”, “What do we do about…?”.

Adjusting to new ideas

The learning curve was steep. At times it was difficult to stick to our guns and not think about the issues of functionality further down the line. Sometimes there were raised voices and stern words. We are a passionate and professional team, so there was never any malice or falling out, just some misunderstanding and confusion.

For some, the idea of developing without answering those bigger picture questions was just too hard to adjust to at first.

Did it work?

Looking back now, it’s the best thing we ever did. All the staff understand and have bought into the methods we use.

We do still get questions about functionality that is out of scope of the current ticket from time to time. However, it’s now much easier to tell a developer that they shouldn’t worry about it until we get there.

They understand the benefits of only needing to have the current criteria in their minds. Not having to remember and understand three or more months worth of requirements makes their working life so much easier.

If you want to find out about Agile there are lots of resources on the web. The best place to start is by reading the Agile Manifesto.

Leave a Reply

Your email address will not be published. Required fields are marked *