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.

We are following scrum in our project. I see most of the times the scrum master allocates the tasks for us. However, I read from many scrum books that scrum works the other way around (the 'pull' approach) and team members pick up tasks or features. Is scrum master assigning tasks the correct approach or does it go against the agile ideology?

share|improve this question
4  
You are asking the question in a way the suggests you think there is a correct way to implement scrum. This is not how you should look at it. Scrum is a basic framework with some very generic guidelines. But every team and every project must adapt the guidelines to suit there current needs. Without a lot more details about your team it is impossible to give specific advice. –  Loki Astari Feb 22 '11 at 8:29
    
+1 Martin - Exactly. It's a framework. No need to be dogmatic or purist in your approach. –  Agile Scout Feb 22 '11 at 15:04
4  
@Scout: A ScrumMaster acting as a command-and-control project manager is neither Scrum nor agile. –  Martin Wickman Feb 22 '11 at 17:58
    
@MartinWickman - He hasn't mentioned that the team feels they are being "commmanded". Maybe they've abdicated this responsibility and choose to focus on writing code instead of picking things to work on. "If you choose not to decide, you still have made a choice." Peart –  JeffO Apr 13 '12 at 15:15

6 Answers 6

up vote 15 down vote accepted

According to the Wikipedia Article on Scrum, Sprint tasks are not assigned by the ScrumMaster:

Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in.

Furthermore, the definition of a ScrumMaster is that he/she is the person responsible for making sure people follow the rules of the Scrum process.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

The ScrumMaster does not assign tasks, plain and simple. The team is self-organizing, and decisions of who works on what is decided by the team.

This is true Scrum. Many organizations may of course use variations of this, however.

share|improve this answer
    
Yes. PO prioritizes. Team members estimate and select. Simple and powerful. –  Martin Wickman Feb 22 '11 at 18:01

I've been a scrum master in both types of environments (where I pushed tasks to individuals and where individuals pulls tasks).

O the Push team, the development resources were not interchangeable. The Windows Client work had to go to the windows developer and the web work to the web developer. So I was able to push tasks to resources during planning sessions. I was also able to do individual capacity planning to know when to stop pushing.

The pull method worked well on a team where any task could be picked up by any resources. But, I couldn't do individual capacity planning during the planning session, instead I had to depend on average velocity to know when enough was enough. (It took ~3-4 sprints before we had a good idea on velocity).

I came across an interesting article outlining pros/cons of Push vs. Pull.

share|improve this answer

Never.

Scrum is totally clear on this. The Development Team, as a group, is responsible for completing the items in the Sprint backlog. They are also completely in control of how they go about getting the development done and nobody is allowed to tell them how to do it.

As a coach, the Scrum Master does have a role in pointing it out when he sees the Team is in danger of missing Sprint objectives for whatever reason. But then he needs to ask them to figure out how they are going to deal with it, and then get out of their way.

Another approach could be to let the Team complete the Sprint, hold them responsible for the lack of results and then let it get discussed in the Sprint Retrospective.

share|improve this answer

In my opinion the scummaster shouldn't do that, team members should themselves pick up tasks. If the scrummaster is only doing the administration as is the case in our team is see no problem. Our scrum master makes sure the paper scrum board stays in sync with the excel file. The role of scrum master should be a facilitating one we're he/she makes sure you can do your work unhindered. This is the way we work. Do you know why your scrummaster does this? Is he a project manager afraid to become obsolete? Is he afraid the team will not pick up tasks themselves? It might be a good idea to discuss this during a retrospective.

share|improve this answer

Like any ideology, there are times when the rule book needs to be thrown away, or carefully ignored.

Use some judgement as to what seems appropriate. Just be careful about somebody becoming a de-facto project manager - or worse, bullying people into doing certain things.

There's a big difference between task allocation by dictate (you SHALL do X) and allocation by discussion and agreement. Sometimes the agreement might be lukewarm.

Then again, maybe the team needs directing... its hard to know.

However, I'd be concerned about any process at all that insists you must follow the process to the letter with no room for wiggle or judgement. Such a process is a substitute for thinking.

share|improve this answer
    
Thinking is hard and I can only do so much per day. May as well let something or someone else think about the little stuff. –  Crazy Eddie Feb 22 '11 at 5:21
1  
In scrum you delegate this responsibility to the team. You don't stop thinking. In fact you think collectively. So decisions are better. –  user2567 Feb 22 '11 at 6:18
2  
I went through a case where no one on the team would pull a task. Despite repeated attempts to encourage the initiative to just grab a card from the board, work would stop until I myself pulled the card and handed it over. I think that stems from a transition mentality. When the engineers are used to having assignments pushed on their plates, it can be hard to turn that around. –  smithco Feb 22 '11 at 6:20

That's the way it's supposed to work, but as with all things that work great in theory...it doesn't always actually work.

There's dependencies, customer wants, and drivers from the outside. Some things just have to get done before you can work on that fancy widget everyone wants to work on.

There's basic developer abilities driving from the inside. Some things are just hard and some people are just better. Sure, when working within an infinite timeline I can just let you figure it out; but when something's got to get done then assigning to the person best placed to get it done fastest and best is the one that's getting the job.

And then there's personality issues like over-controlling Scrum Master and/or developers who can't tie their own shoes without being told to. My team, for example, has both. Simply works better for everyone to ignore this little fact about Scrum in such cases.

In other words, don't just do it because the process says to. Do what works. Screw the rest.

Of course, then there's also the other basic fact of human existence....maybe you don't even know who the Scrum Master actually is. Maybe it's not the person with that title. Maybe you don't even have one.

share|improve this answer
    
"Some things just have to get done before you can work on that fancy widget everyone wants to work on." If this is an occasional thing, sure. If not, maybe you should be using shorter sprints - or maybe Scrum is not the right approach for your team. –  Robin Green Dec 12 '13 at 20:21

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.