That’s not MY job: how far should cross-functionality go?
On a project I was ScrumMastering for I noticed much contention between many of the different roles on the team. In keeping true to Agile and Scrum we are supposed to be “cross-functional” but what does that really mean? I kept hearing “they’re not doing their job” and “that’s not MY job” in regard to requirements gathering, writing stories, and even bug fixes. There have been many pieces written on the roles of members of a Scrum team as well as many things written on cross-functionality of members, but what does that really mean and where do we draw the line to hold people accountable?
The situation I’m specifically thinking of involves my UX team and the information architects (IAs), you can also substitute other roles in place of the IAs to make it more applicable to your team. Their job is to take the system and user requirements and design them into something to guide the Scrum teams in developing the system. This requires the IAs to work very closely with the Product Owners and help them in fleshing out the requirements into something actionable. In this project instance, there was not a Definition of Ready or and business analysts to help the Product Owners in defining their requirements. This led to much frustration because while it is not implicitly the job of an IA to “write” requirements, they ended up having to be cross-functional and do it.
Now this problem boils down to more than just being cross functional or lacking a Definition of Ready and or business analysts (or any other role for that matter). The Product Owners were very new to product ownership and what that actually means, whereas our IAs were veterans to working with Product Owners and had high expectations of what the working relationship should have been as can be the case with many new roles. Regardless, it led to a lot of frustration on the IAs part as they were being tasked with running meetings that should have been owned by the POs and extracting information that should have been thought through.
Yes, taking on these duties and helping out new team members is an important part of being cross functional and a team player. However, when it gets in the way of the deliverables you have committed to, it becomes a problem. In this case, the IAs were too polite to bring up the issue and address the problem head on with the Product Owners. As the ScrumMaster I stepped in and first tried to help guide the POs in what their duties were and set expectations for what the IAs were looking for from them. There was also some management escalation involved and attempts to get business analysts on the team to help out the Product Owners in getting the stories “ready” to be worked on.
Really it came down to having some awkward conversations and crafting some working agreements with this particular segment of the team. It is still a challenge to make sure these agreements are adhered to and of course there are some areas that revert sometimes. So what does this tell us about cross-functionality?
1. Team members should be open to being cross-functional, swarming around problems, training in new team members, and getting out of their comfort zone to help achieve the common goal
2. If being too cross-functional is affecting the work they have committed to delivering in the Sprint on a consistent basis, then it needs to be addressed as a blocker and an action plan should be formulated by the team to help correct the work imbalance.
Team members should not be “stuck” working in only their roles, however that is where their expertise and commitments mostly lie. By swarming around tasks and being cross-functional we can get things done quicker however it is also important to consider the implications of individual deliverables and the potential overlap in effort being cross-functional may lead us to. In short, cross-functionality when used correctly is a good thing for the team and individuals, but when everything is cross-functional and a work imbalance is created it can be detrimental to achieving the Sprint and release goals of the team and overall project.