How the Visual Studio ALM Rangers use Team Foundation Service to Get Ready for Visual Studio 11

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) process.

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 messaging.

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.

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 team.

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.

The Team 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.

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” dogfooding playground.

Note 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:

1. Introduction
2. Getting Started
3. Manage Security
4. Agile Project Management
5. Using Visual Studio, Microsoft Test Manager, and Eclipse
6. Team Build

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 your team.

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.

Note 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.

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.

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.).

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.

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 process template.

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.

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.

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.

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.

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.

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 Studio 11.

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.

Bijan 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.

Brian 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.

Jeff 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 code.

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 Boer