Agile Infrastructure vs. Waterfall Components - Should Scaled Agile Organizations use Specialized Teams?

To be able to deliver quickly, it is commonly accepted that agile teams need to be organized as cross functional feature teams. Having teams organized by skill set or architecture is discouraged as the necessary interaction between teams in such an organization slows down feature development and introduces integration issues.

But is there ever a place for specialized teams in an Agile organization? Your speaker believes that there is, but that most organizations don't understand how to use specialized teams correctly.

This session explores the difference between an organization that uses specialized infrastructure teams that can help your feature teams go faster and a specialized component organization that slows down feature development. Finally this session considers the grey are between components and infrastructure and the guidelines to help when the issue isn't quite so clear.

Timothy Korson, Ph.D.
Certified Scrum Trainer


3 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • Traditional component based team structures
  • Cross functional Agile Team Structures
  • Specialized Agile Infrastructure Teams
  • Case Study
  • Recomendations and conclusions

The following was sent via email:

Spotify has specialized infrastructure teams. For example they have a specialized team that creates deployment tools and infrastructure, which the feature teams then use to directly deploy their features without further dependency on the deployment team. This is much more agile that having the development team develop and then the deployment team deploy.

Many companies create separate component teams, each of which specializes in some part of feature development. The development of a given feature requires the interaction of a number these component teams resulting in handoffs and delays.

The underlying difference seems to be that in general, a new feature does not require updates to the deployment tools and infrastructure, whereas, in general, a new feature may require updates to a number of components. In the first case, having a specialized team providing deployment infrastructure actually helps the feature teams go faster. Spreading a feature across multiple component teams creates dependencies that slow feature development and create other integration issues.

Now let’s blur the issue a little. Consider a company that produces software which integrates video features.  Should the company have a separate video team that specializes in video codecs etc.? The classic agile answer is typically “no.” Having a separate video team typically means that any feature with a video component will create handoffs and delays between the primary feature team and the supporting video team.

In my experience, these handoffs and delays are not inherent. Having a specialized video team could aid, or hinder, agility depending on how the video team interacts with the feature teams. If a video team is regarded as a traditional component team, in charge of producing and configuring all video code, delays and handoffs are a natural consequence. But what if the video team is organized as a true infrastructure team that creates specialized video libraries and other infrastructure for feature teams to use? For this to work, organizations have to discipline themselves that all features currently under development be built on EXISTING video libraries and infrastructure. This rule prevents handoffs and delays and give operational definition to the difference between component and infrastructure teams.

Component teams are structured so that multiple teams have to write code and interact for a given feature. Infrastructure teams are always busy enhancing the infrastructure they provide, but a new feature doesn’t require any new code from them. Features are built on existing infrastructure. If the infrastructure isn’t rich enough – the feature team creates any additionally needed code – or delays the feature development until the infrastructure teams have released a new version of the infrastructure.

In short, infrastructure teams are treated like third party OS providers. If a team is writing a feature on an Android platform, they use whatever is provided in the current version of Android or write their own custom code.




Learning Outcome

  • Understand the difference between infrastructure teams and component teams
  • Learn how to use infrastructure teams to enable feature teams to go faster
  • Understand the problems inherent in component teams
  • Learn how to organize multiple agaile teams so as to acheive colaborative agility while maintaining the advantages of specialized skills and teams.

Target Audience

Anyone involved in organizing or working with multiple Scrum/Agile teams. This includes Managers, ScrumMasters, Product Owners, Coaches, Architects, etc.

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • George Dinwiddie
    By George Dinwiddie  ~  4 years ago
    reply Reply

    Hi, Timothy,

    Your proposal doesn't make it clear to me how infrastructure teams differ from component teams, and don't introduce handoffs and delays.

    • Timothy Korson
      By Timothy Korson  ~  4 years ago
      reply Reply

      Exactly, that is why you have to come to the presentation :)

      Trying to explain in the brief context of the proposal would, I fear, lead many to misunderstand me.

      • George Dinwiddie
        By George Dinwiddie  ~  4 years ago
        reply Reply

        Only the abstract will go in the program. The outline is for the reviewers.

  • George Dinwiddie
    By George Dinwiddie  ~  4 years ago
    reply Reply

    Oops! The session slots were supposed to be 30 & 60 minutes, not 60 & 90. Is there any way this could be shortened to 60? I realize that might be tough, and perhaps we can come up with another solution.