How to get people on board with Scrum/agile?

Question

So I'm part of a Team with 12 members in which we have recently tried to adopt Scrum/agile processes. I am the Scrum Master of the Team and I am also very new to agile; I'm also an apprentice within the company so the rest of the Team and I are not very familiar with the process.

First of all, I apologize if there are more questions in here than just the title!

So my main issue is that we are a Team that perform a large number of operational roles within our day; we are a Development Team, however we don't get a lot of time for development. Within our Team, we have about 5 development members, 2 main managers, subject matter experts and then also people involved with demand. Our manager wanted us to include everything we do whether it was development or not, however we eventually agreed to just stick to development.

My main issue is that the non-developers really don't want to get on board with the agile process. We are on our 8th Sprint so 16 weeks of agile and even before it began they barely turn up to meetings, report new stories for the board or come to me for any support. How do I get people on board that are so against the process? They have no motivation to complete what's on the board so we are constantly rolling tasks over onto the next Sprint which drags the whole process down and they don't want to help make the process better. The development members are so keen for the process to work, they work well with the tasks, attend all meetings yet it's others that bring the process down it seems.

Another issue that I have is that could we even be running agile as a team due to the fact that we get little time to focus on development? We have so many operational tasks that we have so many tasks roll over onto the next Sprint that I am often wondering if we're just wasting time.

Apologies if it's confusing, it's very hard to explain the situation.

Answer 1

The below is predicated on the assumption that you work in a complex, adaptive environment where more is unknown than known when it comes to the value your work creates:

There are books and books on this kind of stuff, and companies that make millions consulting on agile enablement, but it really boils down to how willing people are to embrace the Scrum values. By people I mean both the team members and stakeholders in charge with empowering a cross-functional, self-organizing team.

At the end of the day, everyone must understand Scrum is simply a framework that unearths your issues; it doesn't solve them for you. The silver lining is Scrum gives your team the opportunity to feel empowered to tackle those problems and create solutions that deliver value in an incremental, iterative fashion. While Scrum builds in opportunities to do this, the team has to embody the values to make it work. It all starts with the values and empowerment to self-manage the work they perform.

In my experience, once a team is empowered to manage their own work, the fruits of Scrum really start to become apparent. It's a tough sell- mostly because it changes how work is done - but there are case studies that show the benefits. I recommend finding some of those and working with your team to understand your situation is not unique and can be transformed using the Scrum framework.

EDIT: it may also benefit your team to go through formal training with a certified trainer. Best results if they're all trained at the same time so they can discuss new-found knowledge, their understanding of the framework, and how their role fits into the wider picture.

Answer 2

Welcome!

Another issue that I have is that could we even be running agile as a team due to the fact that we get little time to focus on development? We have so many operational tasks that we have so many tasks roll over onto the next Sprint that I am often wondering if we're just wasting time

Perhaps this is why the management team suggested that your manager wanted you "to include everything we do whether it was development or not". It sounds to me like that was an appropriate recommendation. What was the basis for your team's decision to limit it only to development tasks?

So my main issue is that we are a Team that perform a large number of operational roles within our day

You may find Kanban is a better match for your situation than Scrum. It focuses on a steady flow of work, with WIP limits on the various stages, rather than focusing on sprints as Scrum does.

the non-developers really don't want to get on board with the agile process... How do I get people on board that are so against the process?

The answer to that depends on why they are against the process.

I think that if this has been going on for 4 months (and has it been this bad from the start? or was there initially more participation from the non-developers?), then it's time to stop and rethink, rather than keep doing the same thing that is not working.

It sounds like you could all benefit from training and/or coaching, not only in how (and why!) to "do" agile/scrum, but how to "be" agile and work together as a team.. or possibly as two teams, since the recommended size for a team is 5-7 people.

Good luck!

Answer 3

Since the Dev team is on board, I suggest you make the Dev team purely Scrum/Agile-centric.

Everything coming in and out of Dev goes through the Scrum.

• Want to know when something will be ready? Come to the Daily Standup. Or look at the Kanban board.
• Want to know if your pet-peeve/bug will be dealt with? Come to the Weekly backlog meeting.

Make sure to invite everybody to the daily standup, but start it on-time, every-time, without waiting for anybody. Why punish those that come on time? No calling, nudging or waiting around.

And make sure your board, tasks and information are up-to-date beforehand, and that all your props are available; waiting around for the Scrum Master to find a Magic Marker or a Sticky Note is a great way to self-destruct.

Don't bug people to come; simply ask them why they are not on top of their tasks:

Them: What task?
You: You didn't see your column/swimlane on the Kanban board?
Them: Oh, I don't get that stuff; give me a break.
You: Well, Dev is now running on Agile; if you want to interface with them you'd better get up to speed. Want me to give you a 10-minute tour of how it works?

We used to video the daily standup (put the camera on a tripod, so nobody needs to be distracted while recording). People who were off-site or late or slow could review it.

Sending a link to a video also serves as a reminder and a summary.