In my previous post, I talked about confidence and how it plays an important role in the adoption of SCRUM. The next aspect of a team, specially the smaller ones, is that the majority of the team members need to be multi-disciplinary, in other words, need to wear multiple hats.
A Scrum project is divided up into sprints which can be anywhere between 2 and 4 weeks (ideally). Before each sprint, there is a planning stage, where items are taken off of the product backlog and planned for the sprint (I'll talk about how we plan in another post). Once the number of items are selected, the sprint starts and team members start to work on them.
Now here's one important detail: in true Scrum, and that is Scrum that really works, there is no task assignment. The Scrum master does not assign tasks to team members. Tasks are self-assigned by those who work on them.
From a perspective of a team leader, be it a technical lead or project manager, this might not seem such a great idea at first.
How can I be sure people will get things done?
How do I know how much Joe has done and how much Jack has done?
What if John is pulling all the weight?
Obviously, as members assign themselves tasks when working on them, all these questions are answered in the first sprint. But here's a more difficult one (which recently came up in a conversation with a colleague):
What if Jack is taking all the easy tasks...it's human nature to be selfish and aim for the least effort
In my book, it's not human nature. And in my book, Jack has no place on my team. In other words, if you have a team member like Jack, get rid of him. You don't need him.
This self-assignment of tasks and not having to micro-manage people (which is always a good thing), brings on another issue: you need multi-talented people. In the same way a project can fail if your bus number is low, a sprint can fail and consequently your whole project can get delayed because of the same issue. When a sprint is planned, and all members have agreed on a list of tasks to work on, these are regularly categorized, be it due to technology, business or any other factor. People tend to stick to a certain category. If Joe has been working on the back-end, he tends to pick tasks that are related to that area. If John is working on reporting, he'll pick out tasks of that nature. This isn't necessarily a bad thing, unless it becomes pathological. What cannot happen is for Joe to refuse to work on something that is not directly related to his area. If Joe runs finishes his tasks and he only sees a list of tasks that fall out of his area, he needs to be able to jump in and grab one of them. Otherwise, the task remains there until John, the "owner" of that area can work on it, who happens to be working on a previous task. What is even worse is if Joe does have a task in his area, but that it depends on another task which is not in his area.
What ends up happening is that John is causing a bottleneck. The time that Joe is waiting is ultimately time that is lost, which in turn is translated into a delay and consequently a failure of the sprint.
Therefore, it is very important for team members to have the knowledge, and more importantly, the confidence to confront different situations and take on various tasks. This doesn't mean that they have to do it alone. One of the jobs of a Scrum Master is to remove impediments, and if an impediment is caused by a lack of knowledge, the scrum master, one that also needs to be multi-talented has to act as a mentor and lead, has to guide team members through the different challenges.
Scrum doesn't work if you sit around for the next guy to get rid of your problem.