Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

9 Answers 9

up vote 15 down vote accepted

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.

share|improve this answer
2  
What is a "bad faith developer"? –  smp7d Apr 11 '12 at 18:15
3  
Developers than spend the work they are paid for, for something different, such as working on their private projects or surfing internet aggressively. –  user2567 Apr 11 '12 at 18:19

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.

share|improve this answer
    
While true, Scrum isn't a pre-requisite for user stories and prioritization. So how does Scrum make life easier? –  Steve Evers Oct 20 '10 at 17:33
1  
While not a pre-requisite, Scrum is one way to do it. So to be exact, the question should be something like how does Scrum make life easier compared to X? –  Joonas Pulakka Oct 21 '10 at 6:02
    
... compared to waterfall. We already have automated builds and continuous integration. I try to introduce TDD. But we have up-front detailed requirements and estimates, long development cycles (several months), weekly status meetings... –  Xavier Nodet Oct 21 '10 at 7:17
    
@SnOrfus as no stories can be added during sprint so Scrum makes life easier by reducing stress. Developer knows that this is what he will be doing and no one will change the priority during the sprint. –  Asim Ghaffar Jul 23 '11 at 7:38

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'.

share|improve this answer

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.

share|improve this answer
    
I think that is a bit unintentionally overselling it! "What will be done during the next sprint" has to be decided with reference to the product backlog and the priority of the items on it. Of course, "how much will be done during the next sprint" is definitely decided by the team. –  Robin Green Jan 5 at 13:15

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...

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.