Advantages of Scrum for the developers themselves?

Question

Scrum being a project management methodology, how would you 'sell' it to the developers in a team that is reasonably happy with its current situation?

It seems easy to me to explain to our Product Manager how Scrum will allow him to get regular releases, to amend requirements, and get the team to focus on the high-priority stories first. I found it easy to explain what TDD or Continuous Integration bring in a developer's day-to-day life.

But how can developers be convinced to embrace Scrum? How would Scrum make their life easier?

Answer 1

Scrum will provide much more visibility on what is going on. Bad management, last minute changes, pressures, and all kind of stuff a developer usually face.

However, it will also bring a lot of visibility on procrastinators, bad faith developers, insane individualists, ... in other words, bad developers.

Scrum is a double edged sword

Scrum will bring you with opportunities to solve those problems. That's why it's so powerful.

Answer 2

Breaking the big goal ("get the software done") into smaller pieces - stories - and deciding which of them to do at the current sprint improves productivity and reduces stress. When you know specifically what you're supposed to be doing now, there's little to stress about, and you can focus on doing the little piece instead of feeling overwhelmed by the large whole.

Answer 3

Stack Ranks / Backlog keeps milestone ends from being death-marches

As a developer, the 'destructive pattern' I see most in software development is when some 'external controller' (e.g. project management, executive management) gets very excited over the fact that 'favorite feature' isn't going to make it on 'calendar date' and orders a death-march.

Scrum, because it ranks 'important features' high in a backlog list helps developers manage this tension proactively in two ways. First, you can rank 'favorite feature' high in the backlog so that s/he is most likely to be happy. Second, it gives a very visual and concrete answer to "since we moved 'blinking widgets' to rank 1, it's very likely that we're not going to get to 'bouncing bunnies' in this sprint since it is now rank 7. Are you comfortable with this trade-off?"

I've also found that with short sprints, 'external controllers' are less upset about postponing work. If 'blinking widgets' doesn't make it into 'milestone 1' and 'milestone 2' doesn't end until 9 months from now, the sponsor of 'blinking widgets' gets very upset. But if 'blinking widgets' is stack ranked 7 instead of 1 because there really are 6 more important things that have to get done first, this means that we'll probably get to it in sprint + 1 or at worst sprint + 2 which means it will show up 12 or 18 weeks from now (using 6 week sprints). In my experience, waiting 3 months is 'acceptable' to the impatient -- besides, back in the 'waterfall' model of 3+ month milestones, waiting until the next two sprints end is the same calendar time as waiting until the current milestone ends.

Finally, if we're reaching the end of the sprint and things took longer than expected, it's very nice to be able to push backlog items 5-6-7 to the next sprint and make sure we've completed 1-2-3-4 with high quality and without 70 hr weeks. After all, we'll be sure to get to 5-6-7 next sprint. Again, given the shorter timeframes involved in the postpone, 'external controllers' are generally more comfortable with this and don't insist that we slip the milestone two weeks and order dinners each night 'to just push through it'.

Answer 4

People in a Scrum team get to decide many things by themselves: what will be done during the next sprint, how do we break this story in tasks, who works on what, etc. This empowers them, and is almost the exact contrary to micro-management.

Answer 5

The fact that requirements will change is taken into account right from start. Developers don't need to create detailed specs with precise estimates and then spend weeks developing a feature only to realize that the customer changes his mind as soon as he sees the result...

Answer 6

For me, you get to self assign tasks from the backlog is the biggest selling point from a developer point of view. Also, the intimacy with the customer / product owner helps understand the larger scheme of things.

Answer 7

A couple of things:

• Building on Xavier's point about requirements changing right from the start - a less political atmosphere develops when everyone accepts from the start that some things will not be as the client expects. Quick delivery and review will mean that the cost of mis-communications is low, and instead of playing the blame game, the developers can just change things so that they do work as the client expects.

• Story points! What developer doesn't like getting points for doing stuff!!?! Seriously, it's better than getting badges in SC2 or Stack Overflow.

Answer 8

There are several things that I as a developer like about scrum.

The developers tend to be given more information upfront. The product owner needs to explain all the work that is going to be done during the next sprint in sufficient detail to allow for good estimates.

Just in time estimating means that that estimates are reasonably accurate. Everyone usually has a reasonably good idea of what will be finished in a sprint. This gives programmers and project managers the tools to push back against unreasonable demands.

It is nice to step back every three to four weeks and take a breath and at least have a change of pace.

Self organizing teams, seem to give a bit more variety in the work.

In theory at least, during the sprint there are fewer interruptions and 'emergencies'.

The daily stand up meeting forces programmers to say several words every day.

It is easier to see the progress being made as stories are explicitly finished and reviewed at the end of each sprint.

The burn down charts are a pretty effective light weight means of tracking progress.

Answer 9

Advantage for developer is early feedback (from client, tester, Product owner etc).

Also as a developer, i am always interested in doing things step-by-step without distraction. Scrum provides this.

PS: scrum is not a methodology it is a framework.