This article is part of a series in which the Visual
Studio ALM Rangers present guidance to assist you in solving complex,
real-world environments. Our goal is to help you improve the consistency and
quality of your solutions and your overall Application Lifecycle Management (ALM)
To recap, the Rangers are a group of experts who promote
collaboration among the Visual Studio product group, Microsoft Services and the
Microsoft Most Valuable Professional (MVP) community by addressing missing functionality
(feature gaps and whitespace), removing adoption blockers and publishing best
practices and guidance based on real-world experience.
Since the start of the Rangers program in
2006, we have delivered a mix of enhanced features and best practice guidance.
Rangers and those who are familiar with our business know that we always select
our projects by community vote. In other words, Rangers decide what is needed
out there in the real world so you can do a better job. This has one side effect
though. If you look at a set of such projects—like the Visual Studio 2010 wave—it looks like a random collection of content with lots of gaps. That
brings us back to the future and our biggest Ranger “gig” ever, Understanding our Visual Studio 11 Readiness conspiracy. For the first time, we decided to go for full coverage, by design,
which led to 20 new Ranger projects! With so many concurrent projects, we are
breaking every record, but we know that it is worth the extra effort. What else
has a higher priority for a Ranger than being technically
ready for Visual Studio 11?
Teams that build software solutions have
always had an expectation of an out-of-the-box, high-quality, and predictable
application lifecycle management process and tooling. The biggest challenge in
the history of Visual Studio and Team Foundation Server has been that technology
usually precedes the practical guidance from the MVPs and Microsoft Services in
the field. All products experience this dilemma and it often results in
uncertainty of implementation, frustration, and blocking of product adoption.
The Rangers work hard to address this
challenge; with Visual Studio and Team Foundation Server 2010, the ALM Ranger guidance
was released shortly after the products were released. With the latest wave of
Rangers Readiness, we are SIMultanously shipping the out-of-band tooling and guidance with Visual Studio and Team
Foundation Server 11. Product teams call this SIM
shipping or simultaneous shipping.
As shown in Figure 1,
we deliver guidance on process and methodologies, Team Foundation Server planning
and management, Visual Studio Test and Architecture tooling, Team Foundation Build
and Windows Azure solutions, while working in close collaboration with
Developer Product Evangelism (DPE), MSDN, and Patterns & Practices. Our goal
is to eliminate overlapping guidance, duplication of deliverables and confusing
What makes the Rangers solutions different
is that we are not focused on what the product features are, but how
to best use those features, based on experience by those in the field such
as Rangers in Microsoft Services, Microsoft Most Valuable Professionals (MVPs)
and the ALM community.
In a previous MSDN article, Visual Studio ALM Rangers - Reflections on Virtual Teams, we wrote in detail about our process, which we have named Ruck. For
readers who are new to this, Ruck is defined as a “Loose Scrum.” The name is very fitting for our process, which is based on Scrum and
MSF, but it is by no means pure Scrum. We chose the name Ruck, because we didn’t
want to taint the hearts of Scrum purists by calling our process something it
clearly is not. The Visual Studio ALM Rangers use those tools and ceremonies
that work in our non-dedicated, non-collocated, often anti-Scrum projects. ALM Rangers
are MVPs and Microsoft FTEs who have day jobs that keep them gainfully employed
and their participation in the ALM Rangers is out of sheer passion for Visual
Studio and Team Foundation Server. These ALM Ranger community projects are their
side jobs and therefore their day job can sometimes get in the way of the work.
At times, this creates significant challenges. It reminds us of a squad on the
field of battle indiscriminately losing team members and you just have to deal
with it, because the mission will rarely change.
This Visual Studio 11 Readiness wave has a
significant impact on the Visual Studio ALM Rangers who use Ruck due to the sheer size of the project. Usually, only a few
projects are running in parallel. Now we have about 21 running in parallel with
several inter-project dependencies. Previously, ALM Ranger projects using Ruck were
running by themselves with no, or very few, dependencies on other projects. This
is no longer the case. Now, many projects are dependent on the work of other
projects and simultaneous shipping itself is dependent on all projects. Therefore,
we schedule a Ruck of Ruck meeting once a week. In addition, we display a Ruck
status page on our SharePoint wiki site. Project Leads, who are either seasoned
Ruck Masters or Ruck Masters in training, update the status sheet weekly with a
brief status report and list any impediments. If there are no impediments we do
not require their attendance at the Ruck of Rucks.
Figure 1 - Visual Studio 11 ALM
Rangers Family of Readiness Guidance
Anyone can access the SharePoint page and
see the status of another project. We enable transparency by giving everyone
access to all the projects on Team Foundation Service Preview as a Reader. Our
goal is to have full transparency and reduce bandwidth consumption of
our ALM Rangers. Thus, we do not require them to attend a Ruck of Ruck meeting
to tell us what they worked on, what will they work on next, and what their
impediments are. We can easily get that information from the Team Foundation
Service Preview and from the SharePoint wiki. The focus of the meeting is to
handle impediments that we cannot handle in email.
The release of a new version of Visual
Studio requires that we have program managers from the Developer Division who are
very familiar with the new features. In fact, they might have defined these new
features for Visual Studio 11, making them great candidates to serve as the
product owner. It’s notable how the Microsoft Developer Division is supporting
the Visual Studio ALM Rangers by providing a program manager to act as the
product owner for each Ranger project. In the past, we have often had a program
manager serve as a product owner or as a subject matter expert on an ALM Ranger
project, but never so many serving at once.
A product owner’s role is to help define
and approve our Epics and user stories. Since they are very busy getting the
next release of Visual Studio 11 shipped, we also try to minimize their
bandwidth consumption. However, many program owners take their role really seriously
and are present at all meetings, even when those meeting are late in the
evening (depending on their time zone.) The Visual Studio ALM Rangers recognize
their contributions and dedication and are very grateful to have them on the
The Visual Studio ALM Rangers have to scale
their work in ways new members have not done before. Knowing this, we have Ruck
Master training and are currently identifying potential candidates. Some of
those candidates learn that being a Ruck Master is not easy and this role is not
for them. In addition to the Ruck Master role, the project lead has other
duties on the team. Seasoned Rangers are assigned as mentors to the projects when
a Ranger is serving as a lead and Ruck Master for the first time. As we move
through this readiness wave, we are learning where we need to adapt and what we
need to improve. Insight and improvement are achieved through retrospectives, a
Ruck improvement community, and virtual Ranger Talks. As in Scrum, where the
Scrum Master should have only that duty, we have learned that this applies to the
Ruck Master, too. However, the ALM Rangers have not had the capacity to have a
dedicated Ruck Master for each project. This will change in the future as we
anoint new Ruck Masters.
Foundation Service Preview has had significant
impact on our process. The preview highlighted what we all know; Tools are not the
issue when striving towards agility, but rather the people and the culture.
Through the tools of the TFS Preview, we can quickly see when there are issues that
need attention. A few small behaviors have prompted us to change how we add
Product Backlog Work Items to a sprint, but that alone is not a process change.
Features in the preview, such as the burndown chart appearing above the list of
work items, impacted the visualization of team progress for our stand up
meetings. The burndown chart is in your face; there is no denying when your
sprint is facing imminent peril, as you can see in Figure 2.
Figure 2 - Prominent Burndown Chart
This is just one example. More examples will
surface as we go through the process of setting up a project and showing you
how the Rangers use the tooling. So, let’s create an environment in Team Foundation Service for our team to work within and for us to use as the “Rucking”
The environment is based on the Team Foundation Service Preview and the look and feel could change in the future. For more information about the preview, please contact the authors.
However, before we begin, you might want to
take the time to explore these Channel9 videos, which cover the details of the
Team Foundation Service Preview, and give you more information on the setup and
configuration steps we cover in this article:
Visual Studio, Microsoft Test Manager, and Eclipse
Step 1 –
Sign up for a Visual Studio Team Foundation Service account
We began by navigating to the Team
Foundation Service Preview (https://tfspreview.com), defining an account name,
supplying a valid invitation code and accepting the licensing agreement as
shown in Figure 3. Give the name of your URI some
thought because it is immutable and becomes the URL that you will share with
Figure 3 – Create an account
Step 2 – Create Team Project
After we create the account and the associated default Team
Project Collection, we create a Team Project for our team to use. For guidance,
you can check out the Team Foundation Server Planning Guide at http://go.microsoft.com/fwlink/?LinkID=230947.
This guide covers a number of scenarios in terms of server, Team Project
Collection, Team Project and Team design. The next question we dwelled on was whether
to create one Team Project per Ranger project, as shown in Figure 4, or one Team Project with a number of Teams, as shown in Figure 5.
Figure 4 – Multiple Team Project Scenario
Figure 5 – Single Team Project Scenario
We opted to create multiple Team Projects, giving us a clear
boundary between the Rangers projects and the potential to split the
Team Projects into separate Team Project Collections in the future. Again,
spend some time pondering over the Team Project name, as it too, is immutable.
Also see Requirements Management for Ranger Projects – What I wish we did differently with our Team Projects which discusses what we would want to change in future with the Team Project topology.
Figure 6 – Create a team project menu
When creating your Team Project, as shown in Figure 6,
take note of elapsed time, which should be a pleasant surprise compared to the
creation times we have grown used to with on-premise servers. Optionally, you
can dismiss the pop-up window for Create New Team Project and keep working
while the project is created in the background. Alternatively, you can stay focused
on this window and monitor the progress bar, as shown in Figure 7.
Figure 7 - Create Team Project Status Window
Step 3 – Create a Team
Next, we switch to administration mode and create a Team
named ACV_TFSTeamProjectGuidanceTeam, as shown in Figure 8. This enables
new functionality such as the agile planning tools (backlog, board, etc.).
Figure 8 – Create Team
We complete the team creation by adding our team members. We
use their LiveID credentials, but in the future, other authentication
credentials might be supported. The net result is a project-specific Team
Project that has one Team with seven members, as shown in Figure 9.
Figure 9 – ACV_TFSTeamProjectGuidanceTeam Team
Step 4 – Define iterations and Team focus
First, we assign start and end dates to iterations, as shown
in Figure 10, and select an iteration path for the backlog, as shown in Figure
11. Note that the ability to give iterations start and end dates is a new
feature in Team Foundation Server 11. Start and end dates allow for deprecating
the Sprint work item type that we had in the previous Visual Studio Scrum
Figure 10 – Define Iteration Dates
Figure 11 – Define Iteration Path for Backlog
Step 5 – Define the Product Backlog
Next, we define the product backlog, as shown in Figure 12, and associated tasks. To prioritize the backlog, you drag-and-drop items up
or down the list. The backlog priority is a hidden field in this latest build
and you can, but should avoid, editing the priority manually. As in previous
Team Foundation Server releases, you choose either the web application, Visual
Studio Team Explorer, or Excel as the tool to manipulate the backlog.
Figure 12 – Define Product Backlog
Step 6 – Define the Sprint Backlog
To conclude the setup administration tasks, we select a
sprint—in this case sprint 7 —and define the capacity of the team members in
terms of hours per working day (1), as shown in Figure 13. Looking at
the defined capacity, one of the Ranger challenges of part-time bandwidth
becomes evident, whereby the (2) total capacity and the (3) per resource
capacity for the sprint are clearly shown.
Figure 13 – Sprint Capacity
Clicking Contents, we get a view of the product
backlog items and the tasks that are associated with the selected sprint, as
shown in Figure 14.
Figure 14 – Sprint Backlog
A key tenant of Ruck, as with Kanban and
Scrum, is visualization of the work. We are
all aware of why visualization works, as for many of us this is key to
communication; I see much better than I hear. We use the visualization
available in the preview in our stand-up meetings as a way to confirm the
responses to what have you have worked on, what will you work on next, and if are
there any impediments. Figure 15 shows the Task
Board we use as a key visual element for the stand-up. Not only does the task
board provide for great visualization for communication, it confirms what is
being said and is a motivator for others who might not be delivering. But it is
also a fast and easy way to make changes through drag-and-drop of a task from
one column to another to match what is being said in the meeting. The board in Figure 15 is for the whole team. If you click TEAM
MEMBERS, the board changes to show tasks by team member versus by product
backlog item. After we start the meeting, we switch to the TEAM MEMBERS
view so you can see the Tasks for the person who is talking.
Figure 15 - Visualization using the Task Board
For a close view of the burndown chart, click
the burn down image. You will have a comprehensive view of the burndown details,
as shown in Figure 16.
This is great to use when the stand-up meeting is getting started so everyone can
quickly see the condition of the current sprint.
Figure 16 – Visualization with the burn down chart
As mentioned before, the tools are not an
issue—people are. Getting
people to take two minutes to update their work item seems as if we are asking
to them to pay taxes and we are often left feeling like the Ruck Police. This
is nothing new and is just part of causing change and instilling habit. But the
Team Foundation Service Preview enables quick adjustments of work items during
the meeting and immediate reflection of the change. Ruck requires the use of
the tooling because we are not collocated; we don’t have daily stand ups; and
we are not dedicated because this is side-work we are all doing. One could
rightly argue that MSF, Agile manifesto, and Ranger manifesto imply that we are
committed when we say we will do some work and also imply that we can depend on
everyone to update their work.
Team Foundation Service environment plays a
pivotal role in the development of the Visual Studio 11 Readiness content,
serving both as a supporting operational infrastructure for all the Ranger
teams and as a dogfooding environment for Team Foundation Server 11 and Visual
Our unique experience using this software
as a service solution, our success stories and our most difficult challenges,
as well as our hitchhiker’s guide to Team
Foundation Servce will be the focus of our future articles.
Javidi is a
Principal Architect at Visual Studio and the Visual Studio ALM Rangers lead. He
did application development consulting for two decades before joining Microsoft
Consulting Services in 1999, just in time to take the alert shift, as our
customers went through the Y2K scare. In January 2006, he moved from Germany to
our headquarters in Redmond and joined the Visual Studio team.
Blackman is a principal consultant
with the Microsoft Services Partner ISV team, focusing on affecting our ISV
partners’ success in engineering and the market place. He has an MBA, is a CSM,
CSP, MCSD (C++), MCTS, and Visual Studio ALM Core Ranger. He spends his time
writing code, creating and delivering workshops and consulting in various
concentrations and all things ALM.
Beehler is the Visual Studio
Chief of Staff and coordinates many aspects of the Visual Studio effort from
planning to execution to release. As a result, he’s involved with each of the
teams shipping Visual Studio and he "dogfoods" many parts of the
system in order to do his job. He was on the original Visual C++ 1.0 team and
enjoys being part of the effort to expand Visual Studio beyond ‘just’ writing
Willy-Peter Schaub is a Senior Program Manager with the Visual Studio ALM Rangers
at the Microsoft Canada Development Center. Since the mid-’80s, he’s been
striving for simplicity and maintainability in software engineering. His blog
is at blogs.msdn.com/b/willy-peter_schaub and twitter www.twitter.com\wpschaub.
Thanks to the following technical experts for reviewing
this article: Bill Heys, Patricia Wagner, Gregg