"John is the best person for this task"... Or is he?

Imagine that we are visiting a company that's following the Scrum methodology. It's early in the morning, and the team just finished their stand-up.

After the stand-up, the developers have a tech huddle in front of the Scrum Wall. Those huddles are useful - techies can discuss the development tasks and the approach they will follow in great detail. When the team starts talking about who should implement which story, John, the senior developer, steps forward and claims the most complicated story.

No one is surprised as “John is the best person for this task". It is a business-critical story, and the team wants to showcase the new fancy integration work in the next showcase. Nobody challenges the situation.

Yes, people understood that the junior developer, Sam, wanted to work on the story, but hey, there are plenty of stories to play. Sam can pick up an easier and a less risky task. Most people agree that such a division of work is best for the project.

I don’t.

Let's think about a worse scenario. The Project Manager himself asks John to implement the story that has the highest business value. John is the most senior developer, and the project manager is a risk-aware person, as any good PM should be. He “manages” his project with finesse, people think.

I don’t.

I call both of these behaviours “bad smells” - symptoms of a deeper problem.

Agile teams are self-organizing, and team members are empowered to take the initiative. By factoring in business priority, they commit to the piece of work they are working on and share their knowledge and skills with other team members.

When John steps forward each and every time for the complex stories, and junior members of the team are not allowed to pick them up, the team behaviour contradicts Agile team culture.

How can the junior developer Sam feel that he is empowered if he is not allowed to pick the stories he wanted? Sam might not have enough experience for such a complicated story, but this is why developers pair. Pairing him with a senior developer will encourage collaboration and commitment.

How can the team feel that they are self-organizing if their project manager decides who will work on what? Does the project manager exhibit a collaborative behaviour? The stories should be prioritised by business value, and anybody who is willing to do so should be allowed to pick up the next card in line.

When these behaviours become chronic, team members start to feel disengaged. When practice contradicts the praised theory, you will certainly see eyebrows raised, and scepticism will prevail.

Don't get overly concerned about failure. Let people fail in a controlled way. With the right safety net, controlled failures will have a very limited impact on the project, but learnings from them will be invaluable. Failing is the most important part of the learning process, and failure is always an option.

So next time, when everybody thinks "John is the best person for this task," challenge the status quo.