I recently received a newsletter from Agile Coaching Institute which had the following quote from the movie, The Imitation Game:
“Sometimes it’s the very people who no one imagines anything of who do the things no one can imagine.”
This reminded me of observations that I have made, time and time again, in teams starting up with Scrum. In a waterfall environment, often the PM or team lead will allocate tasks to individuals, with deadline dates. Typically the challenging work will be allocated to the more senior guys and the less challenging or mundane tasks will be dished out to the junior guys.
In some teams, I have also seen one or two individuals, who I call “solution heroes”, who go as far as dictating how the tasks should be completed, resulting in bottlenecks for decision making, and single man dependency. They also become the only person who has experience with certain areas of code or the domain. The effect that this has on the junior or less outspoken team members, is that they are not given the choice of what they would like to work on. Rather, they end up working on tasks that either other team members don’t want to do or only allocated work which is believed that they are capable of completing.
In contrast to waterfall, Scrum promotes collaboration, teamwork, self-organisation, autonomy, personal mastery, and more. Scrum is a pull based process, which means work is not allocated to an individual, or at least it shouldn’t be. In the process of Scrum, the team commits to work they believe they can complete within a given period, which is a called a sprint. During the sprint, any individual can pull the next highest priority story on the sprint backlog to work on. Or, they may choose to work with someone, for example, who is a domain expert, in order to gain knowledge of that domain. There are many ways in which you can encourage and support this process. You could suggest to the team members that they don’t allocate work to another team member and rather team members pull the next high priority task that they want to work on. Everyone should be involved in deciding how to implement the requested features. Encourage participation of the junior and less vocal team members in the various meetings and decisions. This can be achieved by facilitating various exercises. Ask powerful questions to the team and or individuals in order to provide them with an opportunity to share their opinion. Help the team to develop trust among each other.
This brings me back to the quote I mentioned at the start of this article. This process empowers the junior and less vocal team members to select the tasks that they want to work on, or select a story to work with someone else on, in order to improve their knowledge. Besides reducing key man dependencies, the junior team members are now empowered to make their own decisions. As a result, they are challenged and able to demonstrate their true potential by selecting tasks which previously would not have been allocated to them, due to the believe that they are not capable of completing.
Waterfall approach can actually demotivate teams. Depending on one’s own values, intrinsic motivators are generally more effective than extrinsic motivators. What that means is, the junior team members now have autonomy to select what they work on, and can improve their knowledge and skills, which supports personal mastery. This is therefore, not only good for the individuals, it is also good for the team. Team motivation is increased, there is a greater sense of team work and collaboration. Delivery is shared as a team and not dependent on one individual.
I have seen on a number of occasions junior or less vocal developers shine, and blow everyone away with what they are actually capable of achieving. This in turn results in greater respect from their peers, and they are treated as equals within the team. The team start to function as one, and problems are no longer solved by a select few, but rather as a collective brain.
I mentioned earlier, the solution heroes, which you may have in a team. I have seen these personalities prevent this process occurring. From my experience, it is difficult for them to take a step back and no longer receive the individual praise. They may feel threatened by sharing their knowledge on domains which currently only they are familiar with. Most of the time, through coaching, these guys are able to change and become team focused rather than individually focused.
On the occasions where this doesn’t happen, I have found that the best outcome for the team, and company, is to remove these individuals from the team, at least temporarily. This changes the dynamic of the team, and provides the team members to take on new challenges and disprove the belief that they are limited in terms of their skill.
Although the focus of this article has been on Agile teams, these principles can be applied to any team. All that is needed is trust in the team that they know how to do their work, and autonomy.
Give those guys who no one imagines anything of, a chance to do the things that no one could imagine.
Blog Post by Dillon Weyer
www.anuvu.co.za
@dmweyer
I would love to get a star rating for this post:
We are well aware of how much the Agilistas loathe and hate people who can get the job done. We’ve seen plenty of good people forced out of a project, and frequently out of a job, by losers whose Agile projects are invariably delayed by years, overrun budgets by tens of millions, and are ultimately scrapped.
The only problem we’ve found with the “hated” experts is that they are not running their own business. Many of them are indeed too focused on the technical aspects.
Here’s the sad truth: People who are good enough to be the single expert in a domain often don’t realise that this gives them power over the whole project. The bosses hate that - fearing that one day you might realise the truth, tear up the underpaid employment contract, hold the project hostage, and offer them a consultancy deal instead.
This is good business: Knowing what you’re worth.
But the truth is, most of these guys are techies not business people. If they were to appreciate the business value of their knowledge and skills, agilistas would not be working with them, they’d be working for them.
I see a lot of frustration and anger there ;)
I agree this is very valid problem. But doesn’t agree with the solution: “.. to remove these individuals from the team, at least temporarily”. For me it violates agile fundaments like:
- learn not punish : why best performer should be punished ?
- self organising team : who should remove team member ?
Actually, having the exact problem in my team we solved it by peer programming to encourage “solution heroes” to educate team.
I will add my experience on this. the key word is “team” the “hero” personality tries to do everything, at the expense of demoralizing the other team members who are perhaps not as good, but are still competent.
And I’m going to make a sports analogy here, you can take the best player on the football team and put him in the game alone and he won’t make a touchdown. But with the help of the team he can.
To explain that “hero” only shines because the team is helping, I have never seen a “hero” do it all alone.
Also last note, holding a project hostage you would get fired no one has that much domain knowledge :)