What are effective techniques for dealing with varying abilities in a SCRUM/kanban team?

Question

I'm currently involved in a scrum-ban (mixture of SCRUM and kanban) team where we have a wide range of developer ability levels. I'm referring to "developer ability level" in the common senses of the term, i.e. time taken to write working and maintainable code combined with communication/teamwork skills combined with general design skills, etc.

Although the sprint backlog is split up into workable tasks, some tasks are more complex and/or critical than others. As is generally done in scrum, these tasks are not specifically assigned to developers and can be picked up by whoever feels up for working on any given task.

This issue that comes up is that if a more complex or critical task is completed by a less-capable developer, the resulting code is almost invariably sub-optimal in terms of correctness, maintainability, and design.

Ideally, only the most complex or critical tasks would be taken up by the more capable developers, while more simple tasks could be covered by the less-capable developers. However, specifically assigning tasks to specific developers goes against what is mandated by scrum. What are some effective techniques to deal with this situation? Or is it just better to not use scrum in this situation?

Answer 1

Are you comfortable assigning varying experience-related labels to your developers? For example, splitting your developers up into Tier 1, Tier 2, and Tier 3 groups. More complex tasks are saved for the higher-level tiers.

When creating SCRUM tasks, instead of dropping them all into one global pot, there could be four pots... Anyone, Tier 1, Tier 2, and Tier 3. Tasks assigned to the "Anyone" pot can be picked up by any developer, while tasks assigned to specifically-tiered pots can only be picked up by developers of an equal or higher tier.

Just some thoughts... How many developers do you have?

Answer 2

There's nothing holy about the official rules of Scrum, or any management methodology. Pretty much every team has to tune a process until it fits their team, and then keep on tuning it. It's totally reasonable to expect a team to take a good bunch of cycles before they realize where their gotchas are, and find ways to account for them.

There are technical solutions you can use - the one that comes to mind first is a development manager or team lead who does the assigning of tasks either at the beginning of the sprint or as people free up.

For your issue, it sounds like some of the team may be reaching outside of their ability level. It's probably worth being sensitive to the egos at play there. Also worth looking about how to bring up the lowest members. Maybe teaming them up with mentoring programmers for defined periods in the week, and doing some pair programming?

Just some thoughts...

Answer 3

I think the best way to deal with it is using Pair Programming.

If you use it on your team you won't have to worry about difficult tasks being implemented by not-so-experienced developers, they can just pair with the experienced ones and the code will surely have the quality as it was developed by the experienced one or even higher.

Also, it will be a good opportunity for the unexperienced ones to learn more and do a "live code review"

Answer 4

It sounds similar to a case I worked on, where we applied pair programming and/or enforced code reviews for each completed task. This generally raises and/or ensures that quality is preserved. You also gain the positive side-effect of raising the general skill level of the entire team over time, and you minimize the risk of hurting the ego of your developers.

To avoid creating the feeling that some developers are "above" others, the techniques mentioned should be applied regardless of who is solving the task. This also has a positive learning effect which applies to seniors as well as juniors.

Good luck!

Answer 5

Design Reviews - if a piece of work is complicated or hasnt been done in a similar way before, do a design, then review it. This should be a task within the user story.

Pair Programming - if more than one person feels they should complete a user story let them all do it. That maybe taking it to an extreme but a Scrum teams success is judged by completing all user stories they commit to. If everyone does the same ticket the chances of success are slim.

Code Reviews - this should not be taken as someone telling you what you did wrong, it should be taken as an opportunity to learn how you could do things better, both for the reviewer and coder.

Definition of Done - if everyone knows what 'done' means, which should include reference to code quality then whoever does a piece of work should do it with equivalent quality levels.

---

Granted the inexperienced person will take longer to complete a user story, but with code reviews and pair programming should learn quickly so next time they will be more experienced and quicker.

This is another reason why using story points for estimation is a good idea. An 8 hour user story is specific to the person completing the task. A 10 point user story is 10 points whoever completes it.