While working on a recent project, I was approached with the question, “What is a cross-functional Scrum team anyway?”
We Agile Coaches who practice Scrum preach about having a cross-functional team without truly defining what that means to an organization. A cross-functional, software development, Scrum team encompass representatives from across functions to develop the required feature or function. For example, a Scrum team responsible for a data entry screen in a mobile application would have a UI designer, a Java coder, an Angular coder, a mobile developer, an iOS developer, a data engineer, a systems tester, a BA, a Scrum Master, a Product Owner, and perhaps an advisory architect. The cross-functional nature of the team ensures a user story is complete in terms of the entire functionality: coding completed and checked in, user story functional testing complete, UI visible, data returned, integration points identified, and so on.
A cross-functional Scrum team is not a component or technology team. Separating ‘teams’ into a UI team, data team, API team, testing team, or any other technology team defeats the team dynamic of intermingling different views when reviewing a user story. It forces user stories to be broken down along process or technology lines rather than looking at a user story feature as a whole. Team members who understand only their playground, may not play well with others when they journey to a neighbor’s playground. This means that if a team member does not know what the rules of play are in another’s sandbox, there may be misunderstandings, conflict, and frustration.
Mixing disciplines within a team also creates an environment of learning and holistic understanding of what is involved in building the feature identified in the user story. The simple task of estimating user stories with a cross-functional Scrum team exposes areas that team members may not have considered. Testers, for example, may elaborate upon how a perceived low effort, low complexity estimate may require high effort from testing in terms of setup, test case development, code accessibility, and other factors. It is also true that a team matures more rapidly in an environment of diversity.
Taking into account a team member’s needs is the first step towards building the Agile maturity of a Scrum team. For example, as a team member, I know that you require X amount of time for development because of data dependency. As a data engineer, I have a dependency on knowing and understanding the data elements the user requires to be displayed based on the query submitted through the UI. Hence, I work closely with the UI developer to understand how to build my tables. As an architect, I assist the team in locating the different inputs and outputs so that the feature is developed with satisfactory results.
There are those who believe a cross-functional Scrum team is one having architects, technical leads or subject-matter experts joined together to establish an architectural design and approach for a solution. They then direct how the development team proceeds with feature development. I call this type of team an architect or design team. Each member brings his knowledge and expertise to analyze a solution in order to figure out the best, most efficient way to meet the customer’s needs. Once the architect/design team has decided on the approach, they become valued advisers for the remaining phases of the project. They can be called upon during Sprint development to clarify the technological reasoning behind a user story or provide advice on how to best implement the development. This team is on the periphery of the Scrum team, helping them and guiding them but not actively developing for the Scrum team.
A truly cross-functional Scrum team is a joy to watch in action, almost like a dance. Sharing information and understanding each other’s point of view allows teams to move closer to becoming a collaborative Scrum team -- which is one step closer to becoming mature in Scrum.