The question here is- Are we using the right environment to create teams with
cross-functional, T-shaped skills?
We see many instances in new Scrum teams in which team
members don't work on skill sets other than their own core skills. I have heard
such concerns from many ScrumMasters. This is a situation where you will find
that it is not easy to create a cross-functional development team with a
T-shaped skill set.
If we inspect closely, there are many reasons behind this unwillingness from team members, which need to be addressed prior to attempting the creation of a cross-functional, T-shaped development team.
Let us imagine what the scenarios might have been when you tried this experiment with your team:
If we inspect closely, there are many reasons behind this unwillingness from team members, which need to be addressed prior to attempting the creation of a cross-functional, T-shaped development team.
Let us imagine what the scenarios might have been when you tried this experiment with your team:
- Hey Bob, could you do testing along with Chris, as Maria will be on leave for the next four days?
- Trisia! You're leaving us by next month and Mak will be on this project, and it would be great if you could help David in executing the test cases.
- Brad, you have worked very well in this .net MVC project, but the integration part in php is not doing well. Because you've previously worked in php also, can you please start looking into that? You may devote 60 percent of your time in that module.
- Hey Paul, please work on data migration till other functional requirements are ready to be discussed.
There may be a lot of other scenarios within teams you
worked on or might have seen in other teams. (Please add your thoughts in the
comment section below.)
What do you think went wrong in scenarios above?
Generally in newly formed teams, we ask a developer for help when someone with that skill set is not available or when it is discovered, at an advanced stage, that more help is needed to complete the sprint tasks. Usually this leads to stretching working hours. I have generally found that in newly formed teams, it works adversely to burden someone in pretext of asking for his or her help.
Sometimes a developer doesn't bring up the fact that he or she doesn't have adequate skills in a required area. Hence it makes sense to indicate that appropriate training will be provided prior to assigning him or her such tasks. Also, we need to assure these developers that their core skills will always be considered when assigning tasks. In mature teams, we rely on task "pulling," but initially in new teams it's task "pushing" in the forming stage.
There is always a fear that working on a different skill set will lead to work on other skills only, and no longer on core skills, especially if there's a scarcity of experience on the team with that needed skill set. However, developers should not have to fear that they'll be spending most of their time on the "other" skill set at the expense of their core skills. This can hamper their ongoing improvement in their core skill set and prove demoralizing.
Often such situations lead to job hopping instead of creating cross-functional teams.
What do you think went wrong in scenarios above?
Generally in newly formed teams, we ask a developer for help when someone with that skill set is not available or when it is discovered, at an advanced stage, that more help is needed to complete the sprint tasks. Usually this leads to stretching working hours. I have generally found that in newly formed teams, it works adversely to burden someone in pretext of asking for his or her help.
Sometimes a developer doesn't bring up the fact that he or she doesn't have adequate skills in a required area. Hence it makes sense to indicate that appropriate training will be provided prior to assigning him or her such tasks. Also, we need to assure these developers that their core skills will always be considered when assigning tasks. In mature teams, we rely on task "pulling," but initially in new teams it's task "pushing" in the forming stage.
There is always a fear that working on a different skill set will lead to work on other skills only, and no longer on core skills, especially if there's a scarcity of experience on the team with that needed skill set. However, developers should not have to fear that they'll be spending most of their time on the "other" skill set at the expense of their core skills. This can hamper their ongoing improvement in their core skill set and prove demoralizing.
Often such situations lead to job hopping instead of creating cross-functional teams.
See more at:
https://www.scrumalliance.org/community/articles/2015/march/monster-of-cross-functional-teams
No comments:
Post a Comment