Scrum: Handling lack of motivation

Question

According to this, "Scrum highly relies on a highly motivated, closely collaborating, cross-functional and self-organized teams." So how do you handle co-workers who may not be as motivated to take ownership of the code? How do you get someone interested in taking ownership?

Answer 1

I don't know if this is your team's issue but it definitely was for us when we first introduced scrum. Our management came to us one day and said, from now on you will not be working in individual silos. Instead, you will be working as a scrum. Here's a bunch of new processes you must all follow and follow them you will.

The key is that they never came to us, the developers, and asked, how do you guys want to work? what will make you happier? more efficient?. So what I heard was, "you no longer own any code. Anything you write, will get trampled on (you know, team ownership). You will not move or lift a finger because we will now manage your time by the hour". Oh and now you have a boring 15-min stand up everyday where people will discuss things you don't care about and it will usually take 30 minutes and then every two weeks will have an uber boring 4 hour planning meeting that is sure to suck all life out of you.

In reality this is not Agile or Scrum, this is just moving from one style of management to a different style, where everything is still centrally controlled, and not only did this suck all life out of me, but it also gave me lots of free time to update my resume.

In the last twelve months, after I lobbied numerous times for our team manager to try something different, he actually took me up on my suggestions, and I think we've had a very successful year.

I believe the key change for us was to give developers much more voice and freedom in choosing how we want to work. Few things we did:

1. Break large "agile" development team into 3 small ones so that each one only has 3-4 developers. This makes everyone engaged and individuals are not drowned out.
2. Make sure everyone in the same team works around the same functional area so that people care what others are talking about in stand ups and iteration plannings.
3. Instead of management simply picking who works on what and assigning stories/tasks, we came up with a backlog and the team itself had a lot of say in how the work is divided.
4. Because we had many new members, we've started with somewhat of a silo system where each person owns a primary area of responsibility. This allowed new people to focus on smaller area of an unknown product and also get a faster sense that they are not playing in someone else's sandbox. But 6-8 months into the program, those areas started to morph as the boundaries became more gray. Now the guys, on the teams I'm on, are fairly comfortable stepping into other's code or having other developers work in theirs.
5. Code reviews of all submissions were key (and this was the first thing that was skimped on when we first did Scrum):
   • Knowledge transfer in terms of programming techniques/methods
   • Was great for others to learn code they wouldn't have seen otherwise
   • Your team gets a chance to communicate and socialize which improves team dynamics
   • And I guess, code reviews will catch a bug or two, but I see their value mostly in the above aspects.
6. Management has to listen to the team. If the team says something doesn't work or needs to be changed, and they simply ignore that, than the team members will simply check out and let the management deal with the project. If you want people motivated, they need to be vested and they will only be vested if they are doing what they believe is right, not what they are told to do from up top.

Answer 2

There are a lot of reasons for a lack of motivation, but probably the most common is not feeling like you have a say. When our team started doing scrum I noticed that the least motivated people about scrum turned around after they saw their suggestions from the retrospectives get implemented.

A bunch of minor issues can add up to be demotivating. For example, one thing that came up last week was a team member who didn't like 4:00 meetings. That's easily fixed.

In other words, the best way to find out what is demotivating your team is to ask them.

Answer 3

By giving them individual ownership over the code.

Many shops work on a "team ownership" model. This is great for cross-collaboration and reducing risk, but not so great for motivating individuals to be personally responsible. Team ownership can result in average code, because there's no individual ownership incentive.

Solution: Assign individuals to each section of the code to be stewards of that part of the code, but allow full team access to the entire code base.

See also: https://softwareengineering.stackexchange.com/a/33464/1204