Team Foundation Server Deployment Planning
Delivery Guide
Developer Tools Deployment Planning Services
Page 1
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Table of Contents
1 Purpose of the Delivery Guide ............................................................................................ 4
1.1 Engagement Agenda........................................................................................................................... 4
2 Engagement Overview ....................................................................................................... 5
2.1 Phase 1: Pre-Engagement Activities (Day 0)....................................................................................... 7
2.2 Phase 2: Kick-off and Presentation (Day 1) ........................................................................................ 7
2.3 Phase 3: Discovery Workshops and Interviews (Day 2-3) .................................................................. 8
2.4 Phase 4: Deployment Plan Development (Day 4)............................................................................... 8
2.5 Phase 5: Plan and Resources Delivery (Day 5).................................................................................... 9
3 Step 1: Conduct an ALM Evaluation ................................................................................. 10
4 Step 2: Complete the TFS Deployment Checklist ............................................................... 11
4.1 Planning Checklist ............................................................................................................................. 11
4.2 Server Planning Questions................................................................................................................ 12
4.3 Project Planning Questions .............................................................................................................. 15
4.4 Customer Profile Checklist ............................................................................................................... 17
4.5 Infrastructure Profile Checklist ......................................................................................................... 18
4.6 Installation Scenario Checklist .......................................................................................................... 19
□ Basic Installation ............................................................................................................................. 19
□ Single Server Installation ................................................................................................................. 19
□ Dual Server Install (2 processors) .................................................................................................... 20
□ Multi Server Install (3-4 processors) ............................................................................................... 20
□ High Availability TFS Farm Install (3+ processors)........................................................................... 21
5 Step 3: Upload Leave-Behind Materials ............................................................................ 22
7 ALM Evaluation Guidance ................................................................................................. 23
7.1 Executive Overview .......................................................................................................................... 23
7.2 Vision Statement .............................................................................................................................. 23
7.3 Scope of Engagement ....................................................................................................................... 23
7.4 Out of Scope ..................................................................................................................................... 24
7.5 Risk Assessment................................................................................................................................ 25
Page 2
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
7.6 Potential Customer Views ................................................................................................................ 25
7.7 Overcoming Interview Obstacles...................................................................................................... 26
7.8 Evaluation Benefits ........................................................................................................................... 27
7.9 Understanding the Customer Situation............................................................................................ 29
Appendix A - ALM Maturity Level Definitions ...................................................................... 30
Appendix B - Maturity Model Practice Areas ....................................................................... 32
Page 3
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
1 Purpose of the Delivery Guide
The Team Foundation Server (TFS) Delivery Guide is written guidance for the technical delivery
consultant to assist in the development of the deployment plan. Please note this document contains
live links to resource and reference materials.
In addition to outlining the entire engagement, the Delivery Guide provides detailed instructions for
three essential on-site activities:
(1) Performing the Application Lifecycle Management (ALM) Evaluation
(2) Developing a TFS deployment roadmap using the TFS Deployment Checklist
(3) Delivering the final Deployment Plan and optional Leave-Behind Materials
1.1 Engagement Agenda
The five-day engagement involves a targeted ALM Evaluation that assists in developing a TFS
deployment plan. The end result is a customized deployment plan. The table below includes the
suggested agenda for the engagement.
Day
Activity
Phase 1: Pre-Engagement Activities (Day 0)
0



Customer completes and returns the Project Scope and Customer Commitment* doc.
Customer completes and returns the Pre-Engagement Questionnaire.*
Customer responses are used to adjust the project scope (if necessary).
Phase 2: Kick-off and Presentation (Day 1)
1



Review Pre-Engagement Questionnaire with customer.
Conduct the Team Foundation Server Business Value Presentation* for customers.
Lead discussion to understand desired outcome of engagement.
Phase 3: Discovery Workshops and Interviews (Day 2-3)
2-3

Interview SMEs to complete the TFS Delivery Guide* consisting of:
o ALM Evaluation (Excel file: 2012_TFS ALM Maturity Questionnaire.xls)
o TFS Deployment Checklist (embedded in this document)
Phase 4: Deployment Plan Development (Day 4)
4

Compile inputs from ALM Evaluation and TFS Deployment Checklist to complete the Deployment
Plan Template*.
Phase 5: Plan and Resources Delivery (Day 5)
5



Review final Deployment Plan with Customer.
Install and walk through any leave-behind materials you deem useful for the customer.
Complete Partner Survey* and submit deliverables* to Microsoft for Payment.
*items that correspond to templates or documents available from DTDPS website
Page 4
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
2 Engagement Overview
The process diagram on the following page is provided as a resource to help the consultant plan the
engagement. Each of the engagement phases is briefly described in the following sections. For more
detailed information about each step, refer to the “DTDPS Service Guide”.
All engagement materials can be found through the partner portal at www.microsoftdtdps.com
1. Select “Conduct the Engagement”
2. On the “Conduct the Engagement” page for DTDPS, select the appropriate engagement from
the colored box.
3. A new page will open with all engagement materials listed in the right column under
“Resources.”
Page 5
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Page 6
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
2.1 Phase 1: Pre-Engagement Activities (Day 0)
In Phase 1, “Pre-Engagement Activities”, the consultant and customer document the scope and
objectives for the overall engagement.
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 1 TFS PreEngagement Activities (zipped file includes the following)
TFS Project Scope and Customer Commitment (Word doc) and
TFS Pre-Engagement Questionnaire (Excel file)
The specific tasks that are completed in this phase include:
 Reviewing the customer’s business requirements
 Requesting that the customer complete the Pre-engagement Questionnaire
 Working with the customer to identify Subject Matter Experts (SMEs) - The consultant will work
with the customer to ensure that the roles and experiences of the SMEs, who have been
identified as interviewees, provide the proper breadth of understanding of the customer’s
processes and tools.
 Creating an interview schedule
 Creating a working-session schedule
2.2 Phase 2: Kick-off and Presentation (Day 1)
In Phase 2, “Kick-off and Presentation” the Lead Consultant will conduct a presentation to provide the
customer’s team a broad knowledge of Team Foundation Server and use the workshop discussion to
help the customer define their desired end state.
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 2 TFS Presentation
Introduction to Microsoft ALM (PowerPoint deck)
Note: Select the appropriate one for your audience.
Tasks for this phase include:
1. Presenting “Introduction to Microsoft ALM”
2. Demonstration of TFS
3. Q&A Session to gather requirements/scope
Note: During this exploratory session, be sure to explain that Visual Studio Online is a potential option,
as opposed to an on premise installation of Team Foundation Server. For more information on the
differences, please see the comparison document included in this DTDPS.
Page 7
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
2.3 Phase 3: Discovery Workshops and Interviews (Day 2-3)
In Phase 3, “Discovery Workshops and Interviews,” the Lead Consultant interviews the SMEs, gathers
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 3 TFS Discovery Interviews (zipped file includes the following)
TFS Delivery Guide (Word doc)
TFS ALM Maturity Questionnaire (Excel file)
documentation, and develops initial findings. The “TFS Delivery Guide” (this document) is a
comprehensive reference that walks the consultant through all the steps required to complete this
phase.
The specific tasks that are completed in this phase include:



Holding a kick-off meeting with the entire team
Gathering documentation on the existing processes and tools
Interviewing customer subject matter experts to complete:
 The ALM Evaluation (using the TFS ALM Maturity Questionnaire, if appropriate)


The TFS Deployment Checklist
Developing initial findings
2.4 Phase 4: Deployment Plan Development (Day 4)
In Phase 4, “Deployment Plan Development,” the Lead Consultant reviews the initial findings from
Phase 3 with the customer’s leadership team, determines recommendations to be included in the plan
that are outside the areas addressed by the engagement, and writes the plan.
During the first part of the session, the consultant should work with the customer to drill down on the
specific core maturity capabilities for their needs and target the primary issues with the highest impact
for working session topics. Possible discussion topics include:






Code Quality and Promotion Strategy
Build Management and Merging Scenarios
Requirements Management
Project Management
Test Management
Pilot Group Migration
For the second half of this phase, the consultant combines the learning from the working session with
findings from the “TFS Delivery Guide” to write the final deployment plan.
Page 8
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 4 TFS Deployment Plan Development (zipped file includes the following)
TFS Deployment Plan Template (Word doc)
The specific tasks that will be completed during this phase include:




Identifying initiatives appropriately based on the maturity level of the practices in place.
Generating a report based on the ALM Evaluation findings.
Inserting the following pieces into the “TFS Deployment Plan Template” document:
o ALM Evaluation report
o Answers from the checklists and questions from the “TFS Delivery Guide”
Customizing the deployment plan by attending to the relevant sections such as the “Future
State”, “Key Areas for Improvement” and “Roadmap” in the document.
A consultant may elect to use his/her own deployment plan template, however the consultant must
ensure all relevant topics (as outlined in the provided template) are covered in the final plan.
Additionally all materials and resources listed on the first page of the “TFS Deployment Plan
Template” must be included in the final plan for the customer.
2.5 Phase 5: Plan and Resources Delivery (Day 5)
In the final phase of the engagement, the Lead Consultant will:



Install and walk through any relevant leave-behind materials provided by Microsoft
(see section: Section 5, Upload Leave-Behind Materials)
Review the completed deployment plan with the customer
Submit deliverables to Microsoft for payment.
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 5 TFS Leave Behind Materials (zipped file includes the following)
TFS Leave Behind Resource Guide (Word doc)
Materials and Resources (virtual links, pdf documents, PowerPoint decks, etc.)
Page 9
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
3 Step 1: Conduct an ALM Evaluation
Team Foundation Sever is the collaboration platform at the core of the Microsoft Application Lifecycle
Management (ALM) Solution. In order to get the most from a TFS deployment, an ALM Evaluation must
first be completed.
For this Planning Services engagement, a special excel template has been designed for the ALM
Evaluation. The template consists of a highly relevant subset of ALM questions that can be completed in
the allotted time and provide valuable insight into the planning phase of a TFS Deployment. The ALM
Evaluation should be completed on site with a Customer Subject Matter Expert (SME).
There is an abbreviated User’s Guide at the end of this document for consultants who are new to the
ALM Evaluation.
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 3 TFS Discovery Interviews (zipped file includes the following)
TFS Delivery Guide (Word doc)
TFS ALM Maturity Questionnaire (Excel file)
Page 10
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
4 Step 2: Complete the TFS Deployment Checklist
The second step in Phase 3 of the TFS Deployment Planning Service is to complete the TFS Deployment
Checklist. Useful resource and reference links are embedded directly in this document.
4.1 Planning Checklist
This checklist outlines the general steps for planning a Team Foundation Server deployment.
Note that the links may take you to guidance for a specific version of Team Foundation Server. In most
cases, there is a selector on the page to select the appropriate version. Please use your judgment.
Done
Step
□
Plan Team Foundation Server Scope - Review Team Foundation Server components to determine which
components you might want to install.
□

Review the supported Team Foundation Server topologies to determine whether you have a network
topology that can support Team Foundation Server. For more information, see: Getting Started with
Visual Studio; Application Lifecycle Management with Visual Studio and Team Foundation Server; Visual
Studio Team Foundation Server Planning Guide; Visual Studio Team Foundation Server Upgrade Guide
Page 11
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Simple
Moderate
Complex
□
Review Team Foundation Server hardware and software requirements. Install and configure all required
hardware and software. For more information, see System Requirements for Team Foundation Server.
□
Review Team Foundation Server security requirements and plan for firewall and router configuration for
Team Foundation Server network requirements. For more information, see Accounts Required for Installation of
Team Foundation Server; Adding Server Roles and Features; Ports Required for Installation of Team
Foundation Server
□
Determine whether you want to customize Team Foundation Server process templates for your business
needs. For more information, see Customizing Team Projects and Processes; Customizing Project Tracking
Data, Forms, Workflow, and Other Objects; Customize Process Templates; Customize Process Configuration;
Team Foundation Server Process Template Customization Guidance
□
Review Team Foundation Server maintenance requirements and develop a Team Foundation Server
backup and restore strategy. For more information, see Backing up and Restoring Your Deployment; Managing
the Server Configuration
□
Review the Team Foundation Installation Guide for the steps appropriate to your chosen Team Foundation
Server deployment. For more information, see "Team Foundation Installation" in the Team Foundation
Installation Guide. You can download the latest version of the Team Foundation Installation Guide from the
Microsoft Download Center
Table 1: Planning Checklist
4.2 Server Planning Questions
The following checklist provides a list of questions that should be asked when planning an enterprise
deployment of Team Foundation Server.
Questions about the Topology in which you want to deploy Team Foundation Server
Page 12
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
□
Are You Currently Operating Your
Computers in a Workgroup?
In a workgroup environment, you must deploy Team Foundation
Server in a single-server deployment. Dual-server Team Foundation
Server deployments are not supported in workgroup environments.
For more information, see Managing Team Foundation Server in a
Workgroup.
□
Are You Currently Operating Computers in
Both Workgroups and Active Directory
Domains?
In workgroups and Active Directory domain, you can deploy
Team Foundation Server in either the workgroup or the domain. You
can support Team Foundation clients from both the domain and from
workgroups. If you want to deploy Team Foundation Server in the
workgroup, you must deploy Team Foundation Server in a singleserver deployment. If you want to deploy Team Foundation Server in
a domain, you can select either a single-server deployment or a dualserver deployment, depending on your operational needs. For more
information, see Managing Team Foundation Server in a Workgroup,
Managing Team Foundation Server in an Active Directory Domain,
Workgroup Requirements for Team Foundation Server, and Team
Foundation Server Requirements for Active Directory.
□
Are You Currently Operating Your
Computers in Multiple Active Directory
Domains or Forests?
If you are currently operating computers in multiple Active Directory
domains or forests, you can support Team Foundation clients in some
or all your domains or forests. You can even deploy the Team
Foundation application-tier server in one domain and the Team
Foundation data-tier server in a different domain, if it is required. For
more information, see Team Foundation Server Requirements for
Active Directory
Questions about the size of the team or teams that will be using Team Foundation Server
□
How Many Teams Do You Want to Support Team Foundation Server can support a maximum of five hundred
(500) team projects if you use the MSF for Agile Software
on Team Foundation Server?
□
How Many Users Make Up Your Software
Development Teams?
(Do you need multiple application tiers?)
Team Foundation Server can support a maximum of five hundred
(500) unique users in a single-server deployment. Team Foundation
Server can support a maximum of two to five thousand (2,000 –
5,000) unique users in a dual-server deployment. As you reach
the maximum, Team Foundation Server performance will decline.
This drop in performance can vary somewhat based on your
hardware and the size and complexity of your team projects. If the
number of unique users on your software development teams is likely
to significantly increase over the course of a project, consider
deploying a Team Foundation Server configured to support the larger
team. For more information about hardware requirements for
supporting numbers of users in single-server or dual-server
deployments, see Visual Studio Team Foundation Server Planning
Guide; Application-Tier Server Requirements for Team Foundation,
System Requirements for Team Foundation Server and Naming
Restrictions for Team Foundation Server.
□
Where Are Your Software Development
Teams Located?
(Do you need a proxy?)
If you have software development teams in more than one office
location, you can choose to deploy Team Foundation Server Proxy to
improve network performance by caching copies of version control
files locally for the developers working at a different geographical
location than Team Foundation Server. Alternatively, if you have
software development teams working in different locations that speak
Development process template for project creation. Team Foundation
Server can support a maximum of two hundred and fifty (250) team
projects if you use the MSF for CMMI Process Improvement process
template for project creation. If you have more than five hundred
MSF for Agile team projects, or more than two hundred and fifty MSF
for CMMI team projects, you must deploy more than one Team
Foundation Server. For more information, see Visual Studio Team
Foundation Server Planning Guide
Page 13
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
different languages, consider deploying an Team Foundation Server
at each location configured for that team's language. For more
information about Team Foundation Server Proxy and remote
connections to Team Foundation Server, see Managing Remote
Connections to Team Foundation Server Proxy. For more information
about Team Foundation Server and languages, see Language
Requirements for Team Foundation Server
Questions about the number and type of projects you plan to develop on TFS
□
How many team projects will you support?
How many different process templates will
you deploy?
How complex are your process templates?
The total number of team projects Team Foundation Server can
support depends on what process template you choose to use when
creating those projects. Additionally, Team Foundation Server has
other project-related limitations that you should consider as part of
planning for Team Foundation Server. For more information, see
System Requirements for Team Foundation Server and Visual Studio
Team Foundation Server Planning Guide
Questions about the life cycles of the projects you plan to develop on Team Foundation Server
□
Is Your Average Software Development
Life Cycle Measured in Years?
If the average development time for a software project you want to
develop on Team Foundation Server is measured in years, consider a
dual-server Team Foundation Server deployment. Dual-server
deployments are larger and can support larger numbers of unique
users. Because of the larger hardware requirements, dual-server
deployments can support many work items, documents, and source
code versions more gracefully than smaller, single-server
deployments.
□
Is Your Average Software Development
Life Cycle Measured in Months?
If, on the other hand, the average development time for a software
project you want to develop on Team Foundation Server is measured
in months, with small teams that work quickly on smaller projects,
consider one or more single-server Team Foundation Server
deployments. Single-server deployments are smaller and require less
hardware, and individual servers can be archived or discontinued as
the software projects developed on them come to a close.
□
Is Your Average Software Development
Life Cycle Unpredictable?
If the average development time and size for software development
projects varies greatly, consider a dual-server deployment. Because
of the larger hardware requirements, you are less likely to experience
performance or software limitation issues if one or more software
development projects on Team Foundation Server proves to be
longer and more extensive than first thought. If you choose a singleserver Team Foundation Server deployment, consider whether you
might want to implement space-saving measures such as limiting the
size of attachments to work items. For more information, see
Managing Data.
Questions about the maintenance and availability needs for Team Foundation Server
□
Will Team Foundation Server
Unavailability Put Your Software
Development Project At Risk?

How frequently will you back up
TFS?
Some software development teams are resourced so that any
unexpected server unavailability will put the project at risk. If so,
consider a dual-server Team Foundation Server deployment
with a standby Team Foundation application-tier and a
clustered Team Foundation data-tier. Providing this redundancy
increases your options for backing up data without locking out users
and reduces the risk that Team Foundation Server will be unavailable
due to an unexpected hardware problem. For more information, see
the Team Foundation Server Installation Guide. For more information
Page 14
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013


Does your company have regular
off-hours when backups can be
performed?
How critical is it to have TFS
available 24/7?
about where to find the installation guide, see Install Team
Foundation Server
Table 2: Server Planning Questions
4.3 Project Planning Questions
The following checklist provides a list of questions that should be asked when planning to provision a
Team Project on Team Foundation Server.
Questions about the Current Team Project and Future Work
□
Is this a new Team Foundation Server
Installation?
If you have installed Team Foundation Server for the first time, you
must create a new team project before you can use any one of the
features or tools of Team Foundation. If you are working on an
existing installation, you might find team project already existing on
the server, and you should evaluate the adequacy of that project for
your future work.
□
Do you need a new team portal?
Review the contents and focus of the current team portal. Determine
whether the content and focus of the portal is still relevant to the
future work. If you want to create another team portal that focuses
specifically on the future work, you must create a new team project
and team portal. We strongly recommend that you use only one team
portal for each team project.
□
Do you need different people to have
different permissions?
Review the task assignments and security permissions for all the
team project members. Determine whether:

Current team project members will be performing multiple
roles in the future work.

The same person will need different permissions for different
parts of the project.
Page 15
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

Different people will be performing the same roles as current
team members.
If you will have different people with different permissions working
on the project, you must create a new team project.
□
Do you want to use different check-in
policies?
Review the current check-in policies for the current team project.
Determine whether the check-in policies are still appropriate for the
future work. If you want to use different check-in policies for future
work, you must create a new team project and define the new checkin policies. Team Foundation Server supports using only one set of
check-in policies for each team project.
Do you want to use different settings? Reasons to create a new team project.
□
Do you want to use a different process
template?
Identify the process template and, if applicable, the process guidance
used in the current team project. Determine whether the template is
still appropriate for the future work. If you want to use a different
process template for future work, you must create a new team
project using that different template. Team Foundation Server
supports using only one process template for each team project.
After the team project starts, you can manually customize the
process template that is being used according to the team project.
However, unless these customized changes are saved to the process
template stored on the Team Foundation server, the changes will not
appear in any new team projects that are based on that template.
□
Do you want to use different work item
types?
Identify the type of work items used in the current team project.
Determine whether the work item types are still appropriate for the
future work. If you want to use different work item types or want to
use the same work item types with different content, you have to
create a new team project and define new work item types. Team
Foundation Server supports using only one set of work item types for
each team project.
□
Do you want to experiment with process
or other team project settings?
If you are new to Team Foundation Server or interested in improving
team functioning, you may want to experiment with alternative work
flows, classification hierarchies, build processes, policies, and more.
Create a separate team project to run these experiments.
□
Are there more than 10 million versioned
work items in the project?
Count the total number of work items in the current team project and
determine whether you have used more than half the capacity of
Team Foundation Server. Team Foundation Server supports a
maximum of 20 million versioned work items in a single team
project. If you have used more than half, you may run out of room
before you finish the new team project. Additionally, the complexity
of the work items can adversely affect Team Foundation Server
performance
□
Does the software functionality change
significantly?
If the future work introduces new technologies or significantly new
software functionality, you may want to create a new team project.
New technologies or functionality may require very different work
flows, testing, build scripts, and more that could, in turn, require
significant modifications to the current process template or process
guidance.
Do you want to use the same settings?
Reasons to add iterations and areas to an existing team project.
□
Do you use a master .mpp or .xls file to
manage?
Review the information and tools you use to manage the team,
especially if you manage more than one team project. If you use
Microsoft Project or Microsoft Excel as the major tool to manage team
Page 16
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
projects and want to track all project activity in the same
master .mpp or .xls file, you should continue adding more iterations
to a project instead of creating a new team project. Team Foundation
Server does not support using Microsoft Project or Microsoft Excel to
display work items that are shared across team projects. In other
words, if you manage two or more team projects and have work
items that are associated with more than just one team project, you
cannot display those work items in Microsoft Project or Microsoft
Excel. Instead, you must use one of the other reporting tools in Team
Foundation Server to view and manage those shared work items.
□
Do you want to manually move all the
active work items in the project?
Count the number of active work items in the current team project. If
you create a new team project, you must copy these work items from
the current to the new team project. Team Foundation Server does
not support the bulk copying or moving of work items from one
project to another. Assume for a moment that it takes 30 seconds to
copy and paste a work item from one team project to another, to
copy 500 work items would take 250 minutes or over 4 hours of
continuous work.
Alternatively, you could use Microsoft Excel to bulk copy work items
from one team project to the other. Although the bulk copy would
copy the current information in the work items, it would not copy the
work item history, attachments, and links to the new team project.
For more information about bulk copying work items using Microsoft
Excel, see Working with Team Foundation Clients
You must decide whether the advantages of having a new team
project outweigh the costs of copying the work items.
Table 3: Project Planning Questions
4.4 Customer Profile Checklist
Consultants should work with the customer to determine their logistics, and then select the profile that
best fits their installation scenario.
The Following table describes some customer scenarios and their possible deployment options.
Customer Profile
Team Project
Collections
Server
Single
Dual
Multi-
Single
Multiple
Virtualization (if desired)
(Recommended=X, Feasible=√)
* = Special Circumstance for very small team
Appl.
Tier
DB
Tier
Proxy
Build
1
Small Team (POC) sharing
all code in single location
(< 20 users)
X
Simple
/ Basic
Install
X
X
X*
n/a
X
2
1 small department
sharing all code in single
location (< 100 users)
X
X
X
√
n/a
X
3
1 small to medium
department with isolated
code (<250 users)
X
√
n/a
X
X
X
X
Page 17
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
4
1 medium department
with multiple separated
business units (< 450
users), single location
Single Data Center
supports all BU’s
5
1 medium to large
department distributed in
multiple locations sharing
common code base (<
2200 users)
Single Data center
supports all BU’s
X
1 App
Tier in
each
site, 1
shared
DB tier
1 medium to large
department distributed in
multiple locations, each an
isolated BU from the
others (< 2200 users)
Single Data Center
supports all BU’s
X
6
X
7
1 Large IT Organization
with separate
departments or BU’s
supported
a single data
Table 4:
Customerby
Profile
center (> 2200 users)
X
X
X
No
n/a
X
X
No
X
X
(fixed
VHD)
X
X
No
X
X
(fixed
VHD)
X
Consider
a TFS
Farm
X
X
No
X
X
(fixed
VHD)
In the above table, note the following:
 Proxy servers are only necessary for distributed teams. Then, only when their network
bandwidth is insufficient. Sometimes a distributed team will have no need for the proxy.
o Note: Additionally, a proxy server can sit in front of a Team Build server to reduce
impact on the TFS server.
 Build Servers can (and should) be virtualized in order to save hardware and operational costs.
 The Data Tier is never recommended for virtualization, but can be virtualized in small
department scenarios.
 The application Tier can always be virtualized if the customer desires it.
 For large organizations that are supported by multiple data centers (not depicted on the table),
analyze the needs of each data center when determining an installation scenario.
4.5 Infrastructure Profile Checklist
For assistance selecting the best installation option for TFS 2012, download the Visual Studio Team
Foundation Server Planning Guide: http://vsarplanningguide.codeplex.com/downloads/get/379900.
Be sure to address the following areas:
Page 18
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
□
□
□
□
1) Infrastructure
2) Team Project Collection
3) Team Project
4) Teams Planning
4.6 Installation Scenario Checklist
Determine the installation scenario that best fits the customer’s needs and select the Installation
Options
Find the chart for the installation option chosen in the previous section.
ATDT01 = Combined Application and Data Tier Server
AT01 = Application Tier Server
DT01 = Data Tier Server
SP01 = SharePoint Server
SSRS01 = SQL Server Reporting Services Server
□ Basic Installation
Component
ATDT01
AT01
(app tier and data
tier combined)
Application Tier
X
Data Tier
X
WSS
n/a
SSRS
n/a
Virtualization
Can be virtualized
DT01
SP01
(SharePoint
Server)
SSRS01
(SQL Server
Report
Services)
DT01
SP01
SSRS01
Table 5: Basic Installation
□ Single Server Installation
Component
ATDT01
AT01
Page 19
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
(app tier and data
tier combined)
Application Tier
X
Data Tier
X
WSS
X
SSRS
X
Virtualization
Should not be
virtualized
(SharePoint
Server)
(SQL Server
Report
Services)
SP01
(SharePoint
Server)
SSRS01
(SQL Server
Report
Services)
Table 6: Single Server Installation
□ Dual Server Install (2 processors)
Install on existing infrastructure or more than one server
Component
ATDT01
AT01
(app tier and data
tier combined)
Application Tier
DT01
X
Data Tier
X
WSS
X
SSRS
X
X
Virtualization
Can be
virtualized
Must not
virtualize
Table 7: Dual Server Installation
Note: SQL Server Reporting Service can be installed on either the Application or Data Tier
□ Multi Server Install (3-4 processors)
Install on existing infrastructure or more than one server
Component
Application Tier
ATDT01
AT01
(app tier and data
tier combined)
DT01
SP01
(SharePoint
Server)
SSRS01
(SQL Server
Report
Services)
X
Data Tier
WSS
SSRS
X
X
X
Page 20
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Virtualization
Can be
virtualized
Must not
virtualize
Can be virtualized
Can be
virtualized
Table 8: Multi Server Installation
Note
* SQL Server Reporting Service can be installed on either the Application or Data Tier
* SharePoint and SQL Server Reporting Services can be resident on any machine, separate or combined,
or either part can be resident on the Application Tier. The only constraint is that The Application Tier
requires a dedicated SQL Server Reporting Services component that is not shared for any other purpose
than the TFS App Tier.
□ High Availability TFS Farm Install (3+ processors)
Component
ATDT01
AT01
(app tier and data AT02,
tier combined)
…
AT0N
Application Tier
DT01
SP01
(SharePoint
Server)
X
Data Tier
X
WSS
X
SSRS
Virtualization
SSRS01
(SQL Server
Report
Services)
X
Can be
virtualized
Must not
virtualize
Can be virtualized
Can be
virtualized
Table 9: High Availability TFS Farm Installation
Note: SQL Server Reporting Service can be installed on either the Application or Data Tier
Note: Multiple Application Tiers can be installed supported by a single data tier
Page 21
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
5 Step 3: Upload Leave-Behind Materials
The final step in Phase 3 of the TFS Deployment Planning Service is to upload leave behind materials for
the customer. These key resources are intended to help customers become more familiar with TFS2012
and further their decision to deploy. During the course of the on-site activities, the consultant may
choose to upload these materials with the customer’s subject matter expert in preparation for a
demonstration with the customer on the final day of the engagement.
A list of these resources is provided here in the “TFS Delivery Guide” (below) as well as in the “TFS
Deployment Plan Template.”
START here: http://www.microsoftdtdps.com/
>>Conduct the Engagement >> Team Foundation Server Deployment Assessment>> Delivery Materials >>
Phase 5 TFS Leave Behind Materials (zipped file includes the following)
TFS Leave Behind Resource Guide (Word doc)
Materials and Resources (virtual links, pdf documents, PowerPoint decks, etc.)










VS2012 ALM Demo VHD - This virtual machine (VM) includes Visual Studio 2012 Ultimate, Visual
Studio Team Foundation Server 2012, and a sample application along with sample data which
supports hands-on-labs. This VM includes everything you need to learn and/or deliver
demonstrations of many application lifecycle management (ALM) capabilities in Visual Studio
2012. (Available through the link above.)
Visual Studio Case Studies – A compilation of industry leading white papers and case studies
that describe the Visual Studio Application Lifecycle Management solution
http://www.microsoft.com/casestudies/
Team Foundation Server MSDN Page: http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx
“How to” TFS videos on MSDN: How Do I? Videos
Microsoft Visual Studio Team Foundation Server 2012 Trial:
http://www.microsoft.com/visualstudio/eng/downloads
Team Foundation Server Team Blog: http://blogs.msdn.com/b/team_foundation/
VS and TFS ALM News: http://blogs.msdn.com/b/visualstudioalm/
Brian Harry’s Blog Site: http://blogs.msdn.com/b/bharry/
Channel 9 Team Foundation Server Videos: http://channel9.msdn.com/tags/TFS/
Visual Studio ALM Rangers: http://aka.ms/vsarunderstand and http://aka.ms/vsarsolutions
Page 22
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
7 ALM Evaluation Guidance
7.1 Executive Overview
An Application Lifecycle Management (ALM) Evaluation provides customers with deep insights into the maturity of
their software development capabilities and recommends potential improvements to increase predictability and
success in their application development projects.
The ALM Evaluation offering has been developed to reduce customers’ implementation risks and problems by
identifying their current development processes and capabilities and delivering an actionable plan to implement
ALM best practices and tools.
The ALM Evaluation offering is aimed at the technical decision makers (TDMs) of enterprise customers. These
include Chief Information Officers (CIOs), Chief Technology Officers (CTOs), Lead Architects, Vice Presidents of IT
and Application Development, and Directors of Application Development in enterprises that have at least 50
developers.
Customer interest in the offering stems from the fact that application development is a complex task that, if not
performed systematically, has inherent inefficiencies due to the following:

The complexities of managing the workflow across groups (especially with geographically
dispersed teams)

The inefficiencies in development across projects and applications (due to the limited reuse of
components and services)

Limited management visibility into the project status

Managing software defects and the application lifecycle
Customers that participate in the TFS Deployment Planning offering can expect to receive a comprehensive report
that shows the state of their development capabilities today and provides both recommendations for how to
improve the maturity of their development capabilities and guidance on the expected productivity gains.
7.2 Vision Statement
The vision of the Application Lifecycle Management (ALM) Evaluation is to provide the customer with a prioritized
list of improvement initiatives designed to significantly improve how they develop software. This is accomplished
by assessing the customer’s current ALM maturity level and focusing on both their process and their tools. During
the engagement, The Consultant establishes credibility by identifying the customer’s current ALM capabilities
based on a thorough ALM knowledge, thereby enabling the Consultant to position follow-on work that rapidly
advances the customer toward the advanced stages of ALM maturity expanding their business efficiency.
7.3 Scope of Engagement
The scope of the engagement is determined early in the engagement by the Consultant. The Consultant must
determine the customer’s objectives for the evaluation and facilitate the choice of engagement type. The
customer can choose a standard or a more in-depth enhanced engagement, as outlined below. The standard
evaluation is a short-term engagement, good for initial trust building or as a discovery component of another
offering, like the Team Foundation Server Deployment Planning Service or a Production Pilot. The more
Page 23
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
comprehensive enhanced evaluation is well suited to customers who want a deeper understanding of their ALM
capabilities and are willing to invest the time and money to gain that insight.
The standard ALM Evaluation is administered by a skilled Lead Consultant. It contains four phases and includes
evaluation on four or five practice area capabilities. These practice areas capabilities are outlined in the preengagement planning and kick-off phase. Next, the Lead Consultant conducts up to 10 individual or group
interviews of knowledgeable employees (selected from testers, developers, and managers of the IT group) to
determine the current ALM state. Those findings are discussed, along with brief recommendations, in the Working
Session meeting. The Working Session meeting is customized to a few areas, based on the customers’ needs, as
well as evaluation findings. The final deliverable, the Customer Summary and Recommendations Report, provides
a prioritized roadmap for process and tool initiatives.
The ALM Evaluation phases, based on the engagement type, are outlined below.
7.4 Out of Scope
Several items are out of scope for an ALM Evaluation engagement, but possible as follow-up engagements.
Any activity that is not listed above is out of scope. Table 2 provides a sample of the most likely customer requests.
Each of these can be a follow-up engagement.
Out-of-scope Item
Installing and configuring
Microsoft Visual Studio®
Team Foundation Server
Process reengineering and
roll-out organization
Designing, building, and
deploying any custom
application
Follow-up Engagement

Microsoft Services ALM Team Foundation Server (TFS) Lab
Pilot

Microsoft Services ALM TFS Production Pilot

Microsoft Services ALM Project Management with
Microsoft Solutions Framework (MSF) for Agile Software
Development

Microsoft Services ALM Project Management with MSF for
Capability Maturity Model Integration (CMMI) Software
Development

Custom time and materials (T&M) engagement

Custom T&M engagement
Table 10: Most likely customer requests
The consultant should carefully evaluate the areas that are out of scope. These areas represent good opportunities
for follow-on work as part of a custom Partner engagement. When the engagement is complete and the closeout
meeting takes place, it is a good idea to turn to the out-of-scope section of the work order and show all the things
that can be done if the customer would like to continue with a custom engagement.
Page 24
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
7.5 Risk Assessment
When delivering the ALM Evaluation offering, it is important for you to consider (and manage) the inherent risks.
To help you, some of the most common risks are listed in Table 3, along with their mitigation strategies.
Risk
Impact
Mitigation Strategy
Disruptive or
passiveaggressive
customer team
members
Providing
misinformation, hiding
real issues, and
reducing the impact of
evaluation
recommendations.
The consultant must understand that some of the customer’s team
members will consider the engagement a threat to their
livelihoods. This guide provides specific tactics that can help to
mitigate the customer anxiety, but nothing can replace excellent
consulting soft skills. See Section 6.2, “Interview Groundwork.”
Management of
scope
The engagement is
“fixed fee,” so
accepting scope
beyond that in the
work order will
negatively impact
profitability.
Setting customer expectations during the Pre-engagement phase is
critical. Consultants need to control the expectations. The specific
areas to keep in mind are:

The depth of recommendations. With the short
period of time in this engagement, it will not
be possible to have a detailed roadmap with
implementation plans for each initiative.

The interviewing of additional teams or
practice areas beyond the agreed-upon scope.
Table 11: Common risks
7.6 Potential Customer Views
It is important to understand how the customer views the attribute performance functions and the ALM maturity
evaluation questioning. That insight will aid your understanding of the power of the impact that the ALM
Evaluation engagement has on a company and the reactionary attitudes of its employees. This understanding will
enable you to develop essential interview techniques for successful service engagements.
The ALM maturity evaluation is a tool that:

Facilitates process improvement

Analyzes the strengths and weaknesses (based upon industry best practices) of how things really work

Acts as an instrument for organizational change

Requires active and willing involvement and a group effort at self-analysis
Note: This is not an audit from an external party that gives a “report card.”
Typically, the senior management recognizes that there is an issue or crisis and asks an outside company to come
in and diagnose the obstacles and propose solution plans. An ALM Evaluation consultant is welcomed by these
managers, yet the employees you interview often have less welcoming and defensive attitudes. You may inform
them of the benefits just listed; however, often these employees feel that their jobs may be threatened by your
presence and as a result of your questioning methods. In addition to that stance, you are bound to encounter
some or all of the following common customer preconceptions during an ALM Evaluation engagement:
 If we “fail” the evaluation, I will look stupid in front of my boss.

Will I lose my job if I tell the truth?

I am being compared to Microsoft’s theoretical model.

I am just going to “game” the results (cover my weaknesses and show the best possible face).

I do not have time for this worthless exercise.
Page 25
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

I will find excuses to skip the midpoint and finding meetings.

Nothing is wrong with my group. I know we follow the best practices.
7.7 Overcoming Interview Obstacles
Going in with the knowledge that there is a problem to be found and someone to blame is not part of an ALM
Evaluation engagement. The goal of determining where the company is, in the ALM Maturity Model, plus where
they want to be takes a careful approach that focuses on the processes—not on the people—in an effort to
improve how the organization operates.
Approaching these evaluations with the mindset of a counselor who is there to listen and aid, helps you to obtain
both the results that are necessary for successful service relationships and the ability to offer future service and
product solutions. Go in as a jackhammer, digging up the road for the answers, and all you may get are tight-lipped
responses or an outright rebellion.
Remember to avoid firing off questions that can put the interviewee on the defensive. In preparation, make every
effort to internalize the capabilities, so that you will be able to ask questions in a conversational tone. Table 9
contains two examples of ways to conduct interviews, demonstrating the focus on the processes —over the
individuals and the decisions that they have made.
Capability
Code reuse
Description: Code reuse
covers the ability to
recognize what existing
code can be used in new
software projects. Code
reuse aids the software
development team by
reducing software
development time scales,
reducing costs, and
contributing to the
dissemination of
knowledge and expertise.
Customer
Operations
“Applications are
developed in silos, and
code is replicated
through each, so as
you can imagine we do
not really have
anything being reused,
or we use design
patterns and no
reference
architecture.”
Customer
Situation
Interview Focus
The developers get 
defensive because
they claim that
they know how it
should have been
done in the first
place, but
management
pushed the silo
approach to get
the applications
rolled out more
quickly for the

business users.
The ALM consultant (interviewer) must
focus on determining whether there is a
culture around code and software reuse
as well as around skills and competencies.
A line of questioning about the source
code location(s), which tools are used,
and where in the organization they are
used should give the interviewer a clear
indicator of whether the code is
centralized and whether there are any
processes in place for attempting code
reuse.

The interviewer should be able to
articulate examples of reusable code. The
instructor should question the
interviewer and possibly ask: Can you
give me some examples of reusable
code? Some answers to look for are:
The interviewer should try to determine
whether the customer understands the
value of both code reuse and the proper
architecture to enable code reuse, such
as patterns that promote reuse.


Platform libraries

Application frameworks
Reusable components, such as the
logging application block
Page 26
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

“Our source control
system is Microsoft
Description: Source control
Visual SourceSafe®. We
is the use of the
use this for everything,
capabilities of the source
including document
control repository to
storage. It is pretty
enable developer
well organized and
productivity while ensuring
things are versioned.
the safekeeping of the
We do, however, have
code.
problems with our
code base structure in
Visual SourceSafe. The
lack of branching
seems to be another
problem for us, and so
is concurrent
development.”
Source control
Code from software factory code
generation
Our developers do 
not check code in
very often; they
keep it on their
individual
computers. But,
our biggest

problem is the lack
of any traceability.
Interviewers should be looking for a level
of process and even process automation
around source control. They should also
examine whether heavy automation is
compensating for current repository
weaknesses.

Labelling and branching comprise an area
that the interviewer should thoroughly
understand when performing these
evaluations. This area should be given
thorough attention during the interviews.
The interviewer will be trying to
understand the customer’s level of
understanding and usage of labeling and
branching.

When discussing branching, a savvy
developer will most often pose a
situation such as: When working with a
new Version1.1 release with bugs fixed,
how do you make sure that those
updates will be reflected in the Version
2.0 code that you are currently working
on?

The interviewer should be asking
questions about the existence of a
branching strategy, how it was defined,
and what the criteria were.

The interviewer will be asking about
traceability. This person should try to
delve into what the customer thinks
about their level of traceability, where
traceability is lost, and the cause for that.
The interviewer should be able to
articulate what traceability means, as
well.
Interviewers should also focus on
determining whether the source control
structure is hampering possible build
optimization, and if so, why it is currently
that way. Does it affect dependency
management? An effective interviewer
should drill down into dependency
management and the problems around
that topic, such as circular references.
Table 12: Sample ALM Evaluation questioning
7.8 Evaluation Benefits
The customer views that were expressed earlier in this document are impacted by how the interview is presented
and conducted. What is important is not only the way that the interview questions are relayed, but
Page 27
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
communicating the benefits that will be achieved during and through completion of the ALM Evaluation
engagement.
You might ask: Why is it important to understand the academic view of the evaluation? The answer is that you can
educate your customer about the many benefits by understanding the functions of an evaluation. This will aid in
defusing any negative attitudes held by any of the customer’s team members.
The Maturity Evaluation is an analytical tool that assesses the company’s ALM strengths and weaknesses. Although
you may know from the work order that a problem exists, there may be other issues to discover. These issues may
or may not be related to the primary reason for being there in the engagement. Only by completing the entire
ALM Evaluation engagement will you have the tools that are necessary to conduct the proper analysis.
The process of the evaluation provides a voice for change agents. Typically, staff members have a very good idea
of what should be changed, but they typically struggle to get their ideas heard. The evaluation gives them a voice.
The ALM Evaluation engagement provides staff members with an opportunity to better understand their own
organization, its practices, and its communications. It not only determines whether an organization is performing a
function, but whether they can reliably take localized success and generalize it across the organization to
continued and increased ALM success.
The engagement provides the organization a reference model that is based on Consultant experiences and
industry best practices. It aids in planning the company’s growth by prioritizing changes—indicating what to work
on first.
The evaluation process motivates self-analysis and growth in the following ways:

All ALM-related teams are required to be interviewed. Through this process of broad participation and
increased communication, the organization’s internal change is fostered by the education of industry-wide
ALM best practices that are discussed during the interview.

When openness is fostered during cross-functional interviews and the organization is broadly participating,
the process typically reduces “turf” protection and, at a minimum, makes it easier to spot. Your focus is to
treat and focus on the processes—not on the people—in an effort to improve how the organization works.

The ALM Evaluation engagement functions as a tool to implement process improvement plans. Members of
different teams may have similar ideas on how to improve things, but because they may be
compartmentalized, they may be easily dismissed. Interview participation from associated teams can
broaden the communication of these ideas and allow them to come together to form a force for change.
This can happen as a result of the ALM Evaluation engagement, the interview meetings, or both.

The ALM Evaluation engagement acts as an instrument for organizational change. The ALM Maturity
Evaluation aids organizations in mapping out the process for improvement, transforming how they work.
Unification efforts require leadership to get everyone to see things in the same way and to get middle-level
managers to see across borders.

The ALM Evaluation engagement helps company unification efforts, because the evaluation requires
leadership from the company’s senior management to set goals, monitor progress, provide resources, and
support change. In immature organizations, this can be a radical departure from the norm, where
management looks at software development as a mystery.

Evaluation results are fulcrums of positive change, transforming how the organization grows and achieves
higher ALM practices.
Remember that your function is to be the counselor, not the jackhammer, and to benefit the customer by:

Motivating self-analysis

Conducting team interviews that require broad participation

Fostering internal change

Reducing turf protection or making it easier to spot
Page 28
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

Fixing the process, not the people

Improving how the organization works

Maintaining confidentiality

Acting as a voice for change agents

Getting people to see the same thing in the same way

Involving senior management to help with efforts at unification

Hosting an unthreatening environment

Providing a safe environment to discuss the pros and cons of what they do

Thinking across boundaries

Offering additional beneficial Consultant services
With this knowledge, you will successfully reinforce the positive message to the customer’s staff through a careful
understanding of what fears you might face and how to defuse them.
7.9 Understanding the Customer Situation
Before starting the engagement, the consultant should get enough background information about the current
environment so that the engagement can be positioned within context. This should not be an in-depth analysis
(which is beyond the scope of this exercise), but it should capture how the customer currently feels. Some
examples of areas that should be covered are:

The current development tools across the enterprise, with an emphasis on the primary tools that are used
and the projects that will be focused on during the engagement.

The customer’s current “difficulties” with the software development process.

Any process improvement efforts that might be in process (and the methodology that the customer uses for
process improvement).

The general software development methodology. Does the customer run an MSF Agile shop or a more
formal (MSF CMMI) shop?

The current skill levels.

The current status of any initiative in the organization that relates to the application development process.
Understand whether the customer has a current technology roadmap. This may be either implied or explicitly
written. The customer’s roadmap and how it relates to the Microsoft roadmap is something that the consultant
delivering this engagement should consider, especially when preparing recommendations as a result of the
engagement.
Use the key findings from this exercise as inputs to the customer deliverable document that will be delivered at
the end of the engagement.
Page 29
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Appendix A - ALM Maturity Level Definitions
The ALM Maturity Model defines a set of ALM capabilities and four levels of maturity for each capability. Each
level of maturity brings with a distinct level of value and specific benefits to the customers organization. (See:
Table 10.) Similar to the Core Infrastructure Optimization (IO) and Application Platform Optimization (APO)
software application models, the ALM Maturity Model consists of four levels that range from the most basic to the
most advanced, dynamic maturity practices. The customer receives a score for each capability within each
maturity classification, based on how much of the maturity level they practice. The four maturity levels are
classified as follows:

A company at the Basic maturity level is typically homegrown and does not have documented processes;
has little to no cross-functional communications; and performs in an ad-hoc, informal manner. (These
companies are not professional development organizations, and they usually do not know the next steps for
developing software.)

A company at the Standard maturity level performs in a more uniform way but not 100 percent
consistently, such as when a few departments follow the process but you see that some of the other areas
do not. The company may follow best practices, but it is not receiving the value because of implementation
or commitment.

A company at the advanced maturity level performs the right process across the organization, has clearly
documented processes that are maintained, and follows best practices. This level is where most companies
strive to be.

The Dynamic maturity level is rarely found, because it is not feasible for most companies to be performing
at this level. Therefore, do not be alarmed or try to lift a customer into this maturity level since it may not
make economic or business sense for them to be there. The companies that qualify for this level generally
perform at the top of their industry and include the lower maturity levels in their practices.
This model aids your customers in understanding the key competencies that are related to successful ALM
adoption. The model also offers them a clear and targeted plan that is tailored to their companies’ objectives.
Table 10 provides the maturity characteristics that are associated with each level.
Maturity Level
Basic
Standard
Advanced
Characteristics






The development team uses homegrown practices.



Best practices are starting to be adopted.



The documentation of practices is slight or informal.

Tool usage is formal, with usage policies documented and enforced.
The practices are performed in an ad-hoc or informal manner.
The practices are undocumented.
There is little (or no) communication across teams.
Some key roles (such as QA) are not consistently performed.
Multiple development teams (or all of them) are starting to use consistent
practices.
The tools that are used are generally disconnected and not integrated.
There is a relatively informal use of the tools, with no usage policies
defined.
The use of tools that support best practices is pervasive across teams.
The tools are fully integrated into the integrated development
environment (IDE).
Page 30
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Dynamic



The documentation is formally maintained.


Portfolio management tools and processes are fully integrated.
Best practices are adopted and documented.
Development practices are highly innovative and demonstrate industry
leadership.
It is possible to track requirements and use impact analysis reports for
change requests.

Help desk quality metrics are used to track errors, turnaround time, and
the cost of maintenance.
Table 13: ALM Maturity Model levels
Page 31
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Appendix B - Maturity Model Practice Areas
The ALM Maturity Model Evaluation is based on eight practice areas of the ALM process. Inside each practice area
are the core capabilities and their attributes. You will be inquiring about and applying a score to each practice
area. You arrive at the maturity by calculating the scores of these eight ALM practice area attributes. Your
interview questions determine the scoring for each attribute in the practice areas, which are then combined to
determine the maturity level of the customer.
Table 16 lists the practice areas along with some related Basic through Dynamic maturity traits in more detail.
Practice Area
Architecture and Design
Maturity Level Criteria
Basic



The architecture is not properly documented.

Architecture creation does not consider deployment early in the design
process.


The understanding of the Architect role is unclear.
The use of modeling tools is inconsistent or non-existent.
No clear process exists for transforming business requirements into technical
requirements.
Use of the database modeling tool is inconsistent. There is limited database
architecture.
Standard

The Architect role is understood and clearly identified combined with other
roles.



Tools have been identified, and an early adoption phase exists.

Individual project teams have documented database architectures, but no
enterprise databases exist.
Some habits have starting forming, and some process consistency exists.
Documentation is maintained irregularly and inconsistently across teams or
projects.
Advanced






A dedicated architecture team exists.
Architectural tools take the deployment process into account.
Integrated tools are used across different teams and projects.
The use of practices and processes is capitalized on.
Practices and processes are applied across teams and projects.
Some or all of the database modeling is delegated to a dedicated Database
Administrator (DBA) team.
Dynamic



The process is formalized, documented, and has an architecture.

The organization contributes back to the development community both
internally and externally through the use of published articles, white papers,
and conferences.

Well-documented enterprise databases, consistent and versioned enterprise
data models, and feedback loops to continuously improve the process exist.
The inclusion of patterns and practices is consistent.
A clearly defined mechanism exists for sharing or forcing the usage of patterns
and practices across projects and teams.
Page 32
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Development
Basic









Developers perform only functional testing, if that.
Unit testing is left up to the discretion of the individual coder.
Little if any code reuse exists.
No code reviews by peers or mentors take place.
No metrics are available for code quality.
Code analysis is ad hoc, if it is used at all.
No published coding standards exist.
Database schema-naming conventions are ad hoc and inconsistent.
The database programmability and schema are not in source control.
Standard

Some unit testing takes place, but no formal, written, standard approach
exists.


Some developer-written unit tests appear in source control.


Key code is peer-reviewed.


Basic naming standards exist, but they are not consistent across all teams.
Handcrafted “one-off” test classes exist, but they are not integrated into the
integrated development environment (IDE) testing framework.
The testing policy is inconsistent and informal, but a willingness to improve
code quality through unit testing exists.
The use of comments in the code is inconsistent.
Advanced








There is consistent use and policies for unit testing that supports smoke tests.
Code coverage is used and consistently applied.
Static analysis is used.
Statistics are regularly captured.
Developer- written unit tests run after the QA build verification tests (BVTs).
Code is consistently and thoroughly reviewed.
Published coding standards are consistently applied.
The database is fully versioned in source control.
Dynamic
Software Configuration
Management




Benchmarks for quality targets exist.


Targets can be internally set.





Source control may or may not be used.


An unclear understanding of branch and merge concepts exists.
“Performance budgets” for developers exist.
The organization is an industry leader with published quality metrics.
The continuous monitoring of statistics and metrics for continuous
improvement exist.
The auditing of coding standards takes place.
Basic
Local copies of code exist.
The build process is manual and on-demand.
The build process is not documented.
No traceability exists among the build, the content or work performed, and
the requirement.
Check-in occurs irregularly.
Page 33
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013
Standard





The source-control tool usage is not integrated.
A dedicated build computer exists.
The build process is informal and undocumented.
Branching and merging are understood by the lead integrators.
Daily or regular check-in is performed.
Advanced







An integrated source-control tool in an IDE is used.
A dedicated configuration management role exists.
The build process is formal and documented.
Build metrics are regularly published.
On-demand builds are enabled.
Unit tests run after BVTs.
The database is built from source-controlled components as part of a build
process.
Dynamic
Deployment and
Operations





Highly sophisticated build scripts exist.

Little or no communications exist between the operations and development
teams.


No formal help desk or bug tracking process exists.

Infrastructure deployment issues are identified and resolved at deployment
time.

The environments— such as those for development, pre-production, testing,
UAT, and production— are not segregated.



The build promotion schedule is ad hoc.
Multiple internally and externally produced code modules are integrated.
Build-outcome alerting and monitoring takes place.
All schema objects are unit tested prior to a schema change being completed.
A scripted tool is used to simultaneously deploy schema changes to multiple
environments
Basic
No tools are used; operations are based on e-mail messages with manual
follow-up.
Build promotion is unregulated.
The environment is undocumented.
Standard

The help desk incident tracking tool (for training, user issues, and
infrastructure) is a stand-alone one.



Incidents are not integrated with TFS bug tracking nor escalated to TFS.




The automation and validation of build deployments is limited.
Some monitoring is in place.
Some procedures and/or approval processes are in place for build
deployment.
The Deployment Manager role has been identified.
The infrastructure is documented.
The environment is segregated, but ownership is unclear.
Advanced

The help desk is integrated with the bugs in TFS.
Page 34
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

Monitored instrumentation is hooked into the infrastructure and the
applications.

Tools exist to deploy and validate successful build deployments, smoke tests,
testing scripts, and data generation scripts.


An approval process with traceability integrated into the tools exists.


The infrastructure architecture is documented in integrated tools.
A clear cross-functional team (of infrastructure-development team members)
has been identified.
The environments are segregated, ownership is clearly defined, and promotion
procedures are well understood and consistent among the environments.
Dynamic
Governance

Help desk quality metrics are used for turnaround time, the cost of
maintenance, and the identification of error-prone subsystems.



Deployment is automated.






Projects are started with limited justification.
Monitoring is proactive and ongoing.
IntelliTrace data collectors exist on production environments to enable
IntelliTrace snapshotting for developers.
Basic
Projects are funded based on key influencer opinions.
No return on investment (ROI) evaluation or retrospective takes place.
No portfolio review process takes place.
No compliance program or target is in place.
No process improvement initiative is in place.
Standard




The certification for the chosen compliance program is informal.
Compliance certification is applied and inconsistently monitored across teams.
Processes use semi-manual tools (for example, Microsoft Excel® lists).
The use of initiative targets is random.
Advanced


The certification for the chosen compliance program is formal.


Cross–team resources are managed and their time is assigned.
Portfolio management techniques are used, but portfolio and project
management tools are not necessarily integrated.
Governance is integrated with the certification and compliance program.
Dynamic
Project Planning and
Management



The portfolio management tools and process are fully integrated.

The ROI and retrospective are supported by metrics.


No formal stakeholder communications plan is in place.

Team coordination is informal, and task assignments are made verbally or by
using e-mail.
The organization has Microsoft Project Server integrated with TFS.
Participation occurs in the creation and review processes of industry standard
compliance programs.
Basic
The processes for estimation, planning, risk management, and scope are
informal or non-existent. An instinctive and intuitive approach is used.
Page 35
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013

Financial information is not evaluated by the Project Manager on an ongoing
basis.

No clear Project Manager responsibility is defined.
Standard





Microsoft Project may be used.
The use of Project is individual, not integrated, and not standardized.
Tool usage is dependent on the strength of the individual Project Manager.
Financial information is manually evaluated by the Project Manager.
The Project Manager responsibility is clearly assigned.
Advanced

The integrated use of TFS exists for the management of bugs, tasks, and
change requests.

EPM is used for financial and resource tracking through EPM (Project Server)
to TFS integration.

External resources, stakeholders, and partners share project information and
have integrated tools—such as Microsoft SharePoint® and Microsoft Visual
Studio® Team Web Access — to perform their roles in the project


Dedicated Project Managers exist.
Constant feedback from the product owners, and end-users, to the
development teams is easy and quick.
Dynamic
Testing and Quality
Assurance



The full integration of Portfolio Manager, Project Server, and TFS exists.


No dedicated quality assurance (QA) team exists.




No quality metrics exist.
Metrics are used to drive projects and aid in estimation and re-estimation.
A Program Management Organization (PMO) is in place.
Basic
Ad-hoc functional testing, which is closer to debugging than testing, is
performed by the development team.
The fix and deploy cycles are long.
The regression bug rate is high.
Test data is not abstracted and no test data generation is available.
Standard





A dedicated QA group has been staffed.
A test planning process has been defined.
Non-integrated testing tools are in place.
The testing procedures and environment are informally documented.
Progress tracking is rudimentary.
Advanced




The organizational culture is accepting of defined testing policies.
Test planning begins at the requirements phase.
Testing is a measured and quantifiable process.
Integrated tools generate publishable metrics.
Dynamic


A test process improvement group and tools are in place.
The organization has industry leadership on evaluating potential testing tools
and strategies.
Page 36
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013


Defect prevention is practiced.

The use of automated testing tools is audited and required prior to the
deployment of schema changes.
Requirements Engineering Basic
and User Experience

Testing is based on statistical sampling and measurements of confidence,
trustworthiness, and reliability.
Broad assumptions are made by the development team that they know what
to build.

They work in an ad-hoc manner, using their own initiative, perceptions, and
ingenuity.




Little or no written requirements exist.

Little or no customer feedback on user experience.
Little or no validation with stakeholders takes place.
No User Experience (UX) role has been defined.
User documentation is either non-existent or not standardized (which means
user documentation is on demand and as needed).
Standard




The quality and format of documented requirements are consistent.

User-centered design principals are understood, but supported by
disconnected tools.

Some consistent user documentation exists.
The versioning of requirements is enabled and tracked.
The requirements are accessible to all the stakeholders and team members.
Some non-integrated tools are used for user interface (UI) modeling and
prototyping.
Advanced

Multiple types of requirements—for example, functional, non-functional,
business-system, and feature—are captured.


Requirements relationships are tracked, and tasks are traceable.

Multiple types of requirements—for example, functional, non-functional,
business, system and feature—are captured.


Requirements relationships are tracked, and tasks are traceable.
Fully integrated tools that use requirements coverage analysis reports are
used for traceability.
Fully integrated tools that use requirements coverage analysis reports are
used for traceability.
Dynamic



A product Change Control Board has been instituted.




UX experts incorporate the latest and best UI principals.
Impact analysis reports for change requests are used.
Published metrics exist for new requirements, implemented requirements,
tested requirements, and requirement change requests.
The continuous improvement of UX for subsequent use occurs.
UX designers have a good understanding of the technology and its limitations.
The designers are able to understand the intersection of ease of
implementation versus a great-looking UI.
Table 14: ALM Maturity Model practice area criteria
Page 37
Team Foundation Server Deployment Planning Delivery Guide, Version 3, 10.2013