Scaling Agile using Microsoft Visual Studio Team Services

When the Agile Manifesto was written about 16 years ago, it had a simple goal and that is to uncover better ways of writing software.


Writing software was and still is at the heart of it. In fact, the manifesto states that the primary measure of progress is a working software.

Small teams are able to easily adopt and adhere to these principles, since they usually don’t have historical processes and practices they are bound to.

However, larger organizations, have historically struggled in deriving the same value from Agile methodologies for a multitude of reasons.

In the recent years, there have been many strategies aiming to scale Agile for larger enterprises.

Business Mapping
all take different approaches at adapting agile to the realities of larger enterprises.

Whichever methodology you chose, keep in mind the original goal and the primary measure: Better Ways of Writing Software | measured by | A working software.

Let us choose SAFe as an example, and let us choose Visual Studio Team Services (VSTS) as a tool to implement it.


Out of the box, when you create a VSTS project, it lets you choose one of 3 default process templates: Scrum, Agile or CMMI.

You may be asking yourself:

Sample Implementation:

Imagine the following Organization Structure:

Let’s see how such an Organization would organize its work in VSTS.

The initial setup would lead to the following areas hierarchy:

In addition, we would have the following cadences (for instance):

Each team will choose their areas of interest, and they would subscribe to the cadence the will use to plan.

The Portfolio Team:

For this example, let’s consider the “Modern Portfolio” Team. The team would mostly focus on Envisioning Epics, describing them, and most importantly defining their value stream or funding source.

They could manage their work using a Kanban view which allows them to visually plan and track the stages of their Epics as well as their related implementation features.

(All Epics in this example are imaginary, and names were hidden)

Each epic is tagged using a combination of its value stream or funding source. As each epic gets decomposed by the different program teams, the portfolio team can then monitor progress and the value it accrues. Results are much better when a bottom approach is followed. Most of their planning activities can be done directly from the board.

The Portfolio team can monitor the flow of their backlog, to make sure they are working on the same amount of value at any stage of their lifecycle, and that their backlog is proactively populated. Hence, they might set their dashboard with indicators showing them how many Epics are being considered for each stage, and they would continuously monitor the cumulative flow diagram, but more importantly track the “Lead Time” for their Epics. This indicator shows them how fast are they able to take an idea from inception to market availability.

The Program Team:

The role of the program teams is to implement the vision and goals set by the portfolio team. They will be creating Features, Mapping them to Epics:

They will plan their work using program Increments:

They will track progress through their workflow stages using the Kanban board, allowing them to see the value they accrue via the implementation PBIs from different feature teams:

More importantly they will track Lead Time and Cycle Time to make sure their release train is on a healthy path.

The Feature Team:

Sometimes feature teams are also be referred to as implementation teams or products teams. They are mostly focused on implementing the Features defined by their parent program team and they do that by implementing Product Backlog Items and resolving bugs.

They plan using Sprints that belong to the parent Program Increment:

Their kanban board reflects the stages they go through to deliver a working Story or Bug:

Their dashboard would have KPIs From the Sprint Progress, Bugs Count, Testing Results, PBIs Lead and Cycle Times, Cumulative flow , Test Trends, Build History, Release Progress and Real Time telemetry from their production systems. In other words KPIs allowing them to answer the question: Do we have a working software?


All these teams would do shared planning and look at their delivery roadmap, across teams and across cadences:



Add yours →

  1. I enjoyed reading your post. One key thought. The blog leaves out the most common model for scaling agile, Scrum of Scrums (SoS) aka Scaled Scrum.

    • From my experience, Scrum of Scrums is an Activity that should be conducted by the program level

      • @Chuck, yes a daily scrum at the team of teams level is sometimes referred to as a Scrum of Scrums. I’m referring more specifically to Scrum@Scale, Scaled Scrum, or Scrum of Scrums as scaling models which are 3 different names for same for the same thing, the recommended model for scaling agile per the scrum alliance. Nexus is the alternative for scaring scrum.

        Scaled Agile Framework, SAFe has recently come on the scene and while the term “agile” appears in its title, the principles it promotes are significantly different from those promoted by Scrum. It combines waterfall and scrum (scrumafall) which is very attractive for organizations that reluctant to take the full plunge into scrum.

        My point was simply that the article left out the 2 most widely followed models to scaling scrum.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: