Cross-Functional Scrum Teams

Think of a basketball game

3 June 2014

Ajay Sharma
NIIT Technology


I have seen many discussions of the concept of cross-functional Scrum teams. The argument is that if you have a team with testers, BAs, and coders, does it make sense for testers to code, BAs to test, and coders to gather requirements?

I think that's a good question, but on a Scrum team, the team is really presented a goal, and its members must determine how to get there. The best example for this scenario that I can present is a basketball game.

The goals of basketball are very simple: Get the ball through a hoop and prevent your opponent from doing the same. You have a team of five players on the floor, and that team must figure out how to achieve its goal. The traditional basketball team is made up of a center, a power forward, a small forward, a shooting guard, and a point guard. These positions all have areas for which they are responsible. The center and forwards play close to the basket and are responsible for rebounding and points near the hoop. The point guard handles the ball and is the floor general. The shooting guard has backcourt responsibilities and looks to create baskets from the outside, either through a jump shot or a drive to the basket. This is an oversimplification, but close enough.

With that being said, there are times when the situation in the game changes and the shooting guard may need to go inside and fight for rebounds. The point guard may get trapped in the backcourt and need to pass to someone else to bring the ball up-court, and the center may be left alone at the top of the key and be forced to take jump shorts. So essentially, the shooting guard is playing the role of the forward, someone else is taking the role of the point guard, and the center is taking the role of a shooting guard. To accomplish the team goal of scoring and preventing the other team from scoring, these real-time adjustments and examples of cross-functionality must take place.

Similarly, on a Scrum team, the coders should be doing the coding, the BAs should be performing the analysis, and the testers should be testing, in general. However, the team should have a goal, and if, to accomplish the goal, someone needs to help with the testing, or a developer needs to gather some requirements, or a BA should need to get into the code (gasp!), the individual team members should be ready and willing to step in and fulfill those overall needs of the team.

In my previous company I learned this, and I feel I now truly understand the concept of cross-functional Scrum teams.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (4 ratings)

Comments

David Grant, CSP,CSM, 6/4/2014 8:35:10 AM
I think there's two parts to cross-functionality. Firstly, it enables iterative delivery by not enforcing sequential analysis, programming and test phases, and secondly, (which is the point you raise) composing your team of "specialising generalists" (i.e. individuals with T-shaped skills).

It's important to recognise that when team members are not working within their specialism, they will suffer a significant drop in effectiveness and the team velocity will suffer as a consequence. It is the responsibility of the team to note these situations, and to address them properly, by investigating the root cause for the imbalance and applying an appropriate remedy.

As Scrum practitioners, we should celebrate what cross-functionality brings in terms of keeping on track towards a sprint goal, but not necessarily celebrate the conditions under which it shows up.
Ajay Sharma, CSM, 6/4/2014 12:07:03 PM
yes David I Completely agree with you.
Gene Gendel, CSP,CSM, 6/4/2014 9:53:46 PM
Ajay – you are raising a great topic: becoming a T-shaped person, where Depth = Specialty and Breadth = Generality. Works great, right?:) And your example of a basketball team (any team for that matter) is perfect. A person has his primary role but, if needed, should be able to step into one or two secondary roles. If there is a peak demand of a certain skill (Reinertsen refers to this as ‘Surge Capacity’), everyone should shift gears towards that demand). This is certainly beneficial to a team. But this is also beneficial for an individual, as it makes him more valuable to an organization.
But here is the trick: some companies take it to an extreme and expect that every team member becomes a “universal soldier” by, sometimes, pressing too hard on developing secondary/tertiary skills. Sometimes, they do it deliberately, with intention. For example, by transforming all of its resources into T-shaped and ending up with a large pool of equally qualified people, they (companies) start trimming their resources, and they typically start with the most expensive tiers. Another words, companies promote the same (good) idea but for their reasons (improving economics).
But back to the topic of excessive pressure to become T-shaped: this may take away from a person’s ability to remain a true expert in his primary domain. The thing to remember is this: as much as it is important to cultivate multi-functional (T-shaped) workers, it is even more important to ensure the main focus is to make TEAMs multi/cross-functional. Needless to say, those workers that manage to develop their secondary skills really well, while preserving their primary skills, make themselves very-very marketable.
….One more point…. Becoming T-shaped is very contingent upon being able to reciprocally learn from your peers (e.g. BA from QA, QA from Dev). This assumes that people are willing to share their primary expertize others. This, in its turn, assumes that people do not fear that by sharing their primary expertize the will become less valuable (more disposable) to an organization. This condition can be only met is individuals are not praised/assessed/reviewed as individuals. Because if they do, they will always, naturally (we are all humans) put their personal interests first. And this ties directly with the very key issue that many companies face: bad extrinsic motivations harm agile and Kaizen. But his is another topic that I am planning to discuss separately:).
Grrrreat post Ajay!
Gene
Ajay Sharma, CSM, 6/6/2014 1:24:06 AM
Thanks Gene..
You are right that T-Shaped team is crucial for scrum.
When hiring people, and putting together teams, look for T-shaped people. Always check if they are specialists in at least one useful area, and then verify that they are willing and able to pick up other kinds of work as well. Therefore three attributes is necessary for that team:
1. People who have T-Shaped skills
2. A Musketeer attribute (All for one and one for all) and
3. Willingness to swarm
For example:
For example, Amit is an expert Oracle DBA. This is his specialty and where he prefers to do work. However, Amit can also work outside of his core specialty area by doing some testing and documentation work. John doesn't have deep skills in testing and documentation like people who specialize in testing and documentation do.
Roman Shtekelman, CSM, 6/6/2014 5:34:53 PM
Ajay, can you please share your view on the following team structure: testers who are not able to code, front end developers who specialize in CSS, HTML and Jave Script but dont code in PHP, and PHP coders who know little Javascript. How would you reshape this team, would you encourage PHP coders to learn some JS and vis-versa. So there will not be distinction and all coders will be T shaped or in act even all rounded? Or T shaped ( say Specialize in one technology but able to work with another), or just leave as is? Comments are appreciated.

You must Login or Signup to comment.