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
but…
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.
agile agile disciplines agile roles cross-functional cross-functional scrum cross-functional teams cross-functionality definition of ready leadership scrum scrum team scrummaster servant leadership teamwork User Experience UX Runway
3 Responses
Thanks for bringing up a topic that lots of teams face from one direction or another when transitioning to the new attitude toward roles in a Scrum mindset.
I think one thing that is key to remember is that Scrum a) asks for a cross-functional *team*, while b) also asking members to do whatever is necessary to meet team commitments. A lot of people focus too much on b) while not looking enough at a).
There are certainly a lot of situations where individuals have been too siloed and can benefit both themselves and their companies by exploring outside of what they’re used to. Much has been explored here, so I’ll leave it at that.
However, when looking at the issue of cross-functional *teams*, this becomes more of a system issue, which Lean thinking would advocate as the place to focus first. So yes, if you have a team with insufficient expertise to efficiently get requirements fleshed out (or whatever other need of the team), absolutely someone should step up and do that work inefficiently. Simultaneously, and just as absolutely, the team/ScrumMaster should recognize the current team structure as an impediment to progress and figure out a plan to alleviate that. In some situations, that’ll be growing from within, supporting members of the team to build their expertise with the necessary role. But in plenty of cases, the problem will be one of team membership, and it’s time to look to hiring someone to the team to reach cross-functionality.
Now, to avoid the grumbling you encountered, I think we just need to make people more ready to think in terms of system thinking. That of course comes with the caveat of not discouraging people from getting out of their comfort zones, so it’s a tough problem.
It’s hard when a team has to learn how to work with a different Product Owner, and even harder when it is someone new to the role. A few of my teams have new Product Owners right now, and regardless of how mature the team is, there is a struggle to redefine the working agreements and coach/support the new PO in his role.
I agree, there are certainly growing pains when new folks are brought in and there will be slack that needs to be picked up. Redefining the working agreements is a good place to start. Also it is up to the team to support and help coach the new team members into the fold. Thanks for the comment, Allison.