Can scrum master allocate tasks?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.