Specialized Functional Teams
Scrum, like most Agile frameworks, is built around the concept of a small, dedicated, cross-functional teams that are empowered to self-organize and self-manage around a shared commitment to delivering “potentially deployable” increments of working software frequently – typically every two weeks. Each Scrum team has within it the necessary mix of skills and knowledge to deliver on this commitment. This concept of a self-contained, self-sufficient team maximizes flexibility and collaboration by minimizing external dependencies and allowing the team to focus on their work.
In organizations early in their Agile Evolution, where functional specialization and departmental silos have been deeply entrenched, it’s often necessary to evolve gradually toward teams that are fully independent and self-reliant. And it should be noted that, in larger, more complex organizations; and for those operating in a product domain that involves highly specialized technical skills, the value to be realized from truly self-reliant teams often doesn’t justify the effort and expense.
In these environments it is necessary for Scrum teams to leverage capabilities from outside the team in order to meet their commitments. These are capabilities that involve skills that are a) held by a small number of people in the organization; b) needed by a large number of teams; c) not needed by teams in sufficient quantities or frequency to justify dedicating a person to each team (even if you had enough people to do so).
In environments where this is the case, a common challenge that emerges quickly after Scrum teams are initially formed, is that the existing policies and processes used by these functionally specialized groups cannot keep up with the needs of the Scrum teams. Scrum teams deliver small increments of working product that is “potentially deployable” in short (2 week) iterations. This puts pressure on the organization. Delays of even a few days, waiting for a response or deliverable from an external group, can cause Scrum teams to not meet their iteration commitments, which reduces their velocity, which impacts release scope and/or timeline.
Scrum doesn’t fix your problems - it just exposes them, and gives you a framework in which to address them.
As Scrum teams become faster and more capable, they naturally put pressure on the organization, exposing bottlenecks and inefficiencies that weren’t noticed before. A functionally specialized group that takes 2 weeks to deliver an effort estimate and can then commit to assigning people to that effort (at 10-15% dedication) within 3 additional weeks after the estimate is accepted, may have seemed perfectly reasonable before Agile and Scrum. But now that organization has become the limiting factor for the entire value delivery system. Just as we’ve dedicated time and effort to improving the effectiveness and flexibility of the core software delivery team (the Scrum team), we must now dedicate ourselves to improving the cycle time and throughput of the functional specialty teams that support our Scrum teams.
How a given specialty area, in a given organization, should be addressed is going to be largely unique to that specific situation. However, there are a number of common patterns that generalized from successful implementations.
Empower the Scrum Teams:
Often, many of the skills held by the specialized functional team are also held (at a generalist level) by members of the Scrum team (or could be with a bit of training). In these cases, as much as 90% of the specialized work could be done by the generalists on the Scrum Team. But, in the interest of oversight and ensuring that the 10% is done correctly, all of the work is done by the functional specialists. By enabling the Scrum team to do more of their own work, the scrum team’s flexibility is increased (as well as their opportunity for professional development), the burden on the specialized functional team is reduced, and the functional specialists are freed to focus on the high value 10% and oversight work for which they are most needed.
Streamline the Functional Teams:
Just as Scrum is being used to streamline the product development cycle – removing waste, shortening cycle times, improving feedback and optimizing for throughput – there may be opportunities to apply agile principles and practicies to the specialized functional team processes. The specific frameworks and practices applicable to a given team will vary – some may leverage Scrum, others may be a fit for a Kanban system, still others may choose a hybrid approach. Understand the nature of the work being done, focus on the needs of the customer(s) being served, and implement a process that focuses on effectiveness over efficiency, enables rapid feedback, empirical control, and continuous improvement.
Groom the Backlog:
For certain specialty functional groups, the best way for them to assist the Scrum team – if they cannot be part of the team – is to provide their input and contribution prior to the Scrum team beginning a backlog item. System architects and User Experience Designers often fit into this space. Architectural and design issues can be considered prior to a backlog item being pulled into an iteration – as part of the backlog grooming activities. In these cases, architectural or design reviews may be considered part of the “Definition of Ready” for a story. It should be noted that this pre-iteration activity is by definition risky and potentially wasteful – as work is being done before all information is available or final decision to implement the story has been made. It may be that this risk and waste is acceptable, but care should be taken to avoid reverting to “big up-front design” under the guise of backlog grooming. Whenever possible, combine this approach with Empowering the Scrum Team to minimize potentially wasteful activity.
Forward Looking:
By our definition, specialized functional teams are supporting a number of different scrum teams who will need input and contribution from the specialized team at differing intervals and levels effort. This means that the workload for the specialized team will vary over time. This variability is often at the core of Scrum team frustration in not being able to get timely assistance – because they’re requesting assistance at the same time as every other Scrum team in the organization.
As Scrum teams mature they will begin to exhibit a consistent velocity (within statistical control limits). This provides the level of predictability and necessary to allow realistic release planning and road-mapping (see the 5-levels of Planning). By having a plan, and providing visibility as that plan evolves over time, teams can predict when stories that are expected to require involvement from any specialized functional groups. Those specialized functional groups can then, by looking across the release plans for all supported Scrum teams, anticipate the level of support that will is expected over time, and can feed any concerns back to the Scrum teams so that they can adjust accordingly.
It should be noted that, while the other patterns described are intended to remove cycle-time and throughput constraints in your specialty functional groups, the Forward Looking pattern focuses on identifying and managing those constraints. In order to effectively manage and maximize the value delivery capability of your organization, both constraint identification/management and constraint removal tactics must be employed. Just as we look take a systems perspective to maximizing value in our Scrum teams - empirically measuring and continuously improving the team’s effectiveness; we must do the same at an organizational level.
