12

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?

Christian Neverdal
  • 355
  • 3
  • 14
Brian Mains
  • 479
  • 1
  • 4
  • 11
  • Maybe they would rather be owner of a different piece of code? Of course, if the code in question is so odourous that NO one wants to own it, that's a bigger problem... and SOME one will just have to suck it up and own that code. – FrustratedWithFormsDesigner Feb 27 '12 at 21:22
  • 2
    It would be good to look first for the reason behind the lack of motivation. There is a tendency to overlook human factors ranging from personality conflicts within the team to corporate HR policies that lay blame more than giving credit (ex: "rank and yank"). – jfrankcarr Feb 27 '12 at 21:35
  • 1
    Nothing in the article talks about motivating people to own the code. In fact Scrum discourages code-ownership. Why are you trying to motivate them to own the code rather than the work-load? – pdr Feb 27 '12 at 22:33

3 Answers3

15

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.
DXM
  • 19,932
  • 4
  • 55
  • 85
4

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
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

Community
  • 1
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • I would argue to make sure these are vertical functional areas not horizontal infrastructural areas. I.e the worst thing you can do is have the UI Guy, the Backend Guy, and the Database Guy because for every piece of functionality you will require those three to collaborate. – Michael Brown Feb 27 '12 at 21:30
  • 1
    A rare downvote from me. All this does is lead to the exact opposite of Scrum - n developers working on n different workstreams. Developers lose their cross-project knowledge and when workstream A becomes very high priority, it becomes very difficult to pull people in from elsewhere. Extra pressure gets put on the individual who owns that area of the code, he quits and you're left with a failed project. – pdr Feb 27 '12 at 22:29
  • @pdr: You raise an interesting point. I think I could learn a lot if you and Robert Harvey debated this point further. – Jim G. Feb 28 '12 at 04:30
  • @JimG. See DXM's answer for a more nuanced and comprehensive view (which I happen to agree with). – Robert Harvey Feb 28 '12 at 04:48
  • Yes. I upvoted your post and DXM's. But I like @pdr's point of view too. I don't have a horse in this race. You've all given me things to think about. – Jim G. Feb 28 '12 at 05:00
  • 1
    @JimG. It's a shame, sometimes, that we don't have a forum (chat is too immediate, I don't have that kind of time to dedicate to a discussion) where a handful of experienced and interested developers, who have faced different problems, can head off, debate something and come back with a combined answer. I'm particularly interested in this one though, cause I rarely disagree with Robert's answers here and (perhaps more interestingly) we have both agreed with DXM's answer. – pdr Feb 28 '12 at 13:41