Scrum, like most Agile frameworks, is built around the concept of small, dedicated, cross-functional teams that are empowered to self-organize and self-manage around a shared commitment. They commit to a goal of 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 can be 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 practices 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 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 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 be 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 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.

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by Isaac Montgomery, April 18, 2011

Hi Lee - it's been a long time - I hope the world has been treating you well!

I agree, the "Groom the Backlog" approach has inherent risks; as I said in the article and as you expanded on in your comment. I also agree that your alternative approach of having the team request support in the moment, as that support is needed, is a preferred alternative.

The issue comes when the organization is unable to respond to those requests in a timely manner - which is where the "Streamline the Functional Team" approach comes in. However, this approach tends to be more expensive and takes longer for the organization to adopt.

Ultimately, the key is to adopt an approach or combination of approaches that your organization can achieve in the short-term; can make the organization a little better than it is today; and then continue inspecting and adapting.

So, I think we're in agreement!

As for determining the natural variability in your team's velocity, there are a number of approaches I've seen used. The subject is beyond the scope of what I can describe here (maybe in another article), but I would enthusiastically recommend Donald Wheeler's 'Understanding Variation - the key to managing chaos' and his description of 'process behavior charts'.

Take care, and I hope our paths cross soon!

• 
• +0
• 
• 

...
written by Shih-gian Lee, April 09, 2011

How do you come up with upper limit and lower limit of your velocity?

It introduces high risk for a system architect to be involved before Scrum team picking up a backlog item. This is one of the things that will bring the project to a halt very quickly. It has nothing to do with the experience and skill of an architect. It is about acting too quickly without enough information. For example, an organization may have a guideline for talking to external system via web services, period. But, we may not need to go through Web Services. We can just query the DB directly -- more straightforward and easy. This kind of approach won't come to us until we work on an item.

As for UX engineer, request a dedicated person from the functional team at the beginning of the project to hash out the look and feel for several iterarations. After that, a UI template will emerge and Scrum team can do 90% of the work by following the template. When there is a need for specialist, Scrum team can request one ahead of time. Scrum team will have a pretty accurate guess what area will need UX engineer involvement after several iterations.

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview