The Visual Studio ALM Rangers have learned valuable lessons about organizing and managing teams with members around the globe—all of whom have various skills, motivations, commitments, project affiliations and restrictions. Here, we’ll share our experience and provide guidance for working with teams in less-than-ideal distributed and virtual environments.
To recap, the Rangers are a group of experts who promote collaboration between the Visual Studio product group, Microsoft Services and the Microsoft Most Valuable Professional (MVP) community by addressing missing functionality, removing adoption blockers, and publishing best practices and guidance based on real-world experience.
In this article, we’ll start by defining our customized project-management process called Ruck; then we’ll offer a summary of virtual team challenges and share observations made with Rangers projects using Ruck with Visual Studio Team Foundation Server (TFS) as the Application Lifecycle Management (ALM) solution. We’ll conclude with our recommendations for the Rangers and other virtual teams in similar environments.
The Rangers have been dog-fooding Visual Studio TFS as an ALM solution, with the goal of improving the quality of our business operations and solutions production. One core area of investment with huge potential impact has been the process model and the associated requirements-management process. Our core intent is to create a repeatable and systematic way of finding and addressing the killer features of the Ranger initiatives. Defining and evolving the process has proven to be a challenging task—somewhat like fixing an airplane engine during flight—but with several project teams successfully using variations of the process, we can regard it as a solid pillar. To ensure that we don’t confuse anyone in terms of the methodologies or annoy process zealots, we provisionally chose to call our customized process “Ruck,” which, in the rugby world, means “loose scrum.”
A frequent challenge with Rangers is that each individual has to balance his work, home, and Ranger worlds and commitments. Most Ranger activities have the lowest priority of these three and often happen late at night. What makes the Rangers ecosystem unique is that our solutions can’t be released when they’re ready, but are implicitly time-boxed with technology milestones and demand for the solution. As we’ve yet to find a magic way of extending the number of hours in a day, we rely on an individual Ranger’s sheer passion for the technology and the community to help find spare cycles for Ranger activities. Although this creates a heroic IT professional who can absorb numerous context switches and produce high-quality deliverables in short, ad hoc and random spurts, it also introduces a form of anti-Scrum process.
Looking at the various locations of our team members in the Rangers Index (bit.ly/9LKgZb), which currently includes only a small percentage of the Rangers, we realized that Rangers, and thus our teams, are scattered around the planet. We have to be cognizant that we’re working with a variety of different cultures and that we can neither make assumptions about cultural norms or customs, nor take the environments for granted. Thus, we implement situational leadership and process in our projects to accommodate cultural differences (see the book, “Leadership and the One Minute Manager: Increasing Effectiveness Through Situational Leadership” [Morrow, 1985], by Kenneth H. Blanchard, Patricia Zigarmi and Drea Zigarmi).
As shown in Figure 1, the vast range of time zones necessitates that some team members occasionally stay up late or get up at odd hours for a status or design meeting. This is neither fun nor productive.
Figure 1 Typical Rangers Meeting Across Time Zones
The combination of Rangers from different ecosystems such as product groups, services, partners, MVPs and communities introduces a variety of motivations and commitments that all need to be embraced by the Rangers ecosystem and recognition program.
While we aim for maximum transparency and access to everything by everyone, we have edge cases because of non-disclosure agreements, licensing and infrastructure restrictions.
The frequent context switching—and starting and stopping of a project or feature area—is the most challenging problem because it’s a demoralizing experience for the team. This can make sprint burn-down charts interesting to look at, but difficult to use effectively for status and progress tracking, as you can see in Figure 2. The first chart in Figure 2 depicts an increase in task work items as an individual or team learns there’s more to implementing the product backlog item than first realized. The second chart depicts stopping work on a project because of customer commitments. The velocity chart in Figure 3 demonstrates our statement regarding the effects of context switching and the starting and stopping of feature areas.
Figure 2 Sprint Burn-Down Charts Reflect Challenges (click to zoom)
Figure 3 Project Velocity
Finally, because of the voluntary nature of the Rangers program, accountability varies greatly, offering few options to enforce a delivery commitment. Fortunately, most Rangers hold themselves accountable and therefore most Ranger teams deliver on time, every time.
As mentioned, we have several challenges when teams aren’t located at a single site, when teams are in different geographies and when there’s no individual commitment beyond one’s passion to be a contributing Ranger. We’ve attempted to adapt to this by organizing teams by geography, but this often doesn’t work because it goes against our belief in letting developers choose work from areas in which they have interest, even when it doesn’t align with their current geography. Therefore, we have to be self-organizing and rely on experience to determine what best practices will work for a particular project.
The nature of our virtual ecosystem forces us to break numerous predefined rules of processes such as Scrum. As in Kanban (see the book, “Kanban: Successful Evolutionary Change for Your Technology Business” [Blue Hole Press, 2010], by David J. Anderson), we tailor our process to meet our needs. In many ways, we apply situational leadership to projects, depending on the unique attributes of each specific project. For example, we conduct weekly meetings because everyone has day jobs. Daily meetings (“stand-ups”) are too bounded and too frequent. In addition, our meetings aren’t classic stand-up Scrum meetings because too few individuals can meet at the same time. This regularly compels us to have two meetings in a single day to accommodate multiple time zones.
Ranger projects are complex, requiring that we have transparency, frequent communication, checkpoints and meetings. Because everyone has other commitments, such as families and their day jobs, teams need to avoid being too bounded. As we learn and adapt, we establish our own project patterns and adapt them for better influence. Some of these patterns include:
Our aforementioned challenges exacerbate as project rhythms change. This isn’t unique to our Ranger ecosystem; we experience this in many projects at startup. Getting a proper cadence with a new team takes a few steps and missteps before everyone is finally in sync, executing with regular rhythm.
We, the authors, haven’t been involved directly in the large open source community outside of Microsoft, so what we write here is based on assumptions that are supported by other publications and blog posts. Unlike open source projects, Ranger projects have a fixed ship-date schedule mindset. As we understand it, most open source projects ship when they’re done or are good enough to release, however long this takes. For Rangers projects, many people depend heavily on our artifacts. If our development cycle takes too long, our work can become obsolete with a new release of Visual Studio. Having a fixed ship-date driving the project could be considered anti-Scrum. However, we don’t see this as different from time-boxing sprints; we time-box the overall project.
For our Ranger projects, we use either the MSF for Agile Software Development v5.0 or the Microsoft Visual Studio Scrum 1.0 process template; the latter is by far more popular because it’s lightweight. Our projects require some up-front planning and design; some process methods refer to this as the pregame. We use a Sprint 0 for this pregame work to set a stake in the ground and time-box the planning and design. This ensures the development start date and objectives are known. During Sprint 0, we conduct required team training, set up the environment, plan, research, vote on epic priority and review our Ruck process (we’ll discuss epics in more detail later). Setup of environments is extremely important when you consider a product such as Microsoft Lab Management.
As in Scrum, our Ruck process requires frequent checkpoints. As discussed earlier, daily meetings are too much for the Ruck team. Our version of a stand-up is a weekly meeting, or series of meetings in different time zones, conducted in Microsoft Lync. These meetings are conducted in classic fashion, where attendees are asked about what they worked on, what they’ll work on next and if there are any impediments. In addition, we use the opportunity to communicate any key messages and reiterate the project/sprint vision. We’ve learned that the use of visuals is most effective. The Ruck master or the development lead will share his desktop to display the sprint burn-down charts and show the list of work items for the current team member to address. Visuals and visibility are key!
Ranger projects often have difficulty achieving consistent velocity, as you can see in Figure 3. This is because of the anti-Scrum nature of our teams where team capacity is always in flux. Team members can depart a project at a moment’s notice, leaving us to manage creatively to get work done or solicit new contributors. Because this is a common circumstance for our Ranger projects, we’ve instituted a Ranger Manifesto to emphasize the importance of making the required commitments when contributing to a Ranger project.
We’ve learned that smaller projects and smaller team sizes enable better execution, proper cadence and deeper team member commitment. Also, it seems it’s more difficult for someone to abandon a small team than a larger team. Figure 4 demonstrates a sprint burn-down chart where we’ve achieved good cadence with work item completion and where the actual trend of burn-down better matches the ideal trend as compared to the previous burn-down charts shown in Figure 2.
Figure 4 Better Cadence Results in Better Burn-Down
We use epics to outline a high-level view or elevator pitch for a feature. This maps closely to the Agile community’s use of epics: to tell a more-encompassing story for a feature because the customer isn’t on-site to provide details without any time lag. You can look at an epic as a story that tells why someone would want to install our solution or download our guidance. The epic guides the vision for a feature and drives the creation of related user stories from which we create our work. Because the out-of-the-box TFS process templates don’t have an epic work item type, and we have constraints where we avoid template customization, we prefix the User Story Title field with “Epic” (see Figure 5) and we give this work item a priority of zero for easy identification in reports or report filters.
Figure 5 Use of Epic Prefix in the Title of User Story Work Item Type (click to zoom)
Ranger projects are represented by multiple, loosely defined roles, such as developer, tester, Ruck master, developer lead, product owner, epic lead and reviewer. In many cases, a team member may assume more than one role. One person could be a developer for one feature, a tester for a different feature and a reviewer for a different project. Three core Rangers usually play steadfast roles on every project: Bijan Javidi as project manager, Willy-Peter Schaub as developer lead, and Brian Blackman as Ruck master and coach.
The need for frequent checkpoints and complete transparency makes communication a pivotal part of our process and ecosystem. Good communication creates supportive, monitorial and collaborative webs among the geographically dispersed team. To create a sense of belonging, we always have virtual face-to-face kick-off meetings, during which we define a common set of goals, objectives, motivations, visions, benefits, scopes and constraints. Most importantly, during this kick-off meeting, the team agrees on infrastructure and communication guidelines.
Ruck-of-Ruck meetings, discussed later, minimize the need for everyone to be present in weekly stand-up meetings and ensure that the status and impediments are transparent, using ad hoc, spontaneous and predefined communication. Using TFS Work Item Tracking (WIT), and mapping of Epics as shown in Figure 6, we capture information and state such information as the progress, backlog, features, acceptance criteria, bugs and impediments. Stand-up minutes are documented in wikis and design information in documents stored on the common portal. In some cases, the minutes are stored in source control, which—like all other infrastructure components—is accessible from anywhere in the world.
Figure 6 Mapping the Ranger Epic/PBI/Task Hierarchy to Team Foundation Server Artifacts
The primary vehicles for communication and collaboration are the shared portal and, most importantly, e-mail. Using distribution lists and a controlled vocabulary, e-mails are shared with everyone, including Rangers outside of the current project scope. This ensures that all stakeholders receive all the information, which drives transparency and, using e-mail rules, delegates selective reading to those interested in the information.
Communication and management styles differ in many countries. Some cultures prefer formal and distant communication, with clearly defined management roles and expectations. Others engage in informal, in-the-face and often collaborative management, where even an embracing “hug” is a sign of respect. To clearly define the potential issues and ensure that there are no misunderstandings that could lead to bitter and often disconnected team members, we have to recognize this diversity. As with many other ALM and virtual team tenants, transparency is crucial to proactively and continuously dealing with the culture challenges.
Time zone differences and cultural differences often go hand-in-hand. While some cultures or individuals don’t mind working 24x7—or, more importantly, getting up at insane hours of the night to attend a team meeting—others will take great offense when asked to invest personal family time in a project. To create an environment in which team members feel comfortable and able to collaborate, it’s important to find mechanisms and times that are conducive for everyone in the team to participate in conference calls or online discussions. The majority of the Ranger communication and collaboration occurs through e-mail and, more importantly, the TFS team project and associated portal. We also take great care to schedule regular team stand-up meetings where we can promote collaboration, share status and continuously foster the team identity. When we schedule multiple stand-up meetings across time zones, team members aren’t restricted to their own time zone. They’re allowed to join one or more meetings that suit their time zone and their business commitments. Ruck-of-Ruck stand-up meetings aggregate the status upward, as shown in Figure 7, using the collaboration and especially the WIT infrastructure. Once completed, one consolidated team status can be transparently shared with the entire team and shareholders, using the communication mechanisms chosen by the team.
Figure 7 Ruck-of-Ruck Stand-Up Meetings
Figure 8 shows the ideal virtual team, operating in one time zone, split into feature areas in which one passionate feature lead works with a dedicated and focused number of team members.
Figure 8 Ideal Virtual Team
In reality, the typical Ranger team resembles Figure 9, where the team is scattered across a number of time zones around the globe. The team leads work with part-time resources in various time zones, often focused on several feature areas within the project.
Figure 9 Typical Rangers Virtual Team
By giving everyone access to everything, driving complete transparency, fostering a no-nonsense, no-politics team environment and making use of state-of-the-art ALM technology, we’ve been able to create effective and passionate project teams. As shown in Figure 10, all Rangers have access to all projects through one Rangers portal, which includes work items, source control, project portals and the overall Rangers portal. The Rangers use the controlled vocab to categorize e-mails, allowing easy filtering and use of rules.
Figure 10 Typical Rangers Infrastructure
The diversity of working conditions is probably the most challenging part of our virtual teams. Not only are Rangers part-time team members and therefore regularly disconnected during regular business hours, they often work in secure environments, limiting their access to the public domain and the Rangers ALM infrastructure. In addition, some Rangers work in less-than-favorable environments where 9,600 bps communication lines or 56KB modems are still standard infrastructure. This limits their ability to use environments and services that rely on high-speed networking and huge bandwidth.
Working with TFS—in particular the Web Access components—and relying on e-mail for collaboration, we’ve been able to create an effective and reliable ALM infrastructure that suits the majority of the Rangers.
What are the driving forces that make IT professionals sacrifice personal time to collaborate with other Rangers and aggregate experience, knowledge and information into Rangers solutions and guidance, often working in isolation? Every individual has a different set of motivations and resultant commitments, which needs to be identified and understood so that each resource can be utilized effectively within the team.
When working with virtual teams, we found that it’s important to identify all the team members who are passionate for technology, have a “get it done” mindset and are motivated, open-minded and highly self-disciplined. No team identity, technology or process will enable people who need a great deal of supervision to work effectively in virtual teams, especially when they’re also expected to fulfill a team lead role.
Using the Ruck process and the TFS ALM solution to define epics, product backlogs and tasks has proven invaluable, especially when team members are asked to volunteer for tasks, rather than being assigned tasks. In addition, the ability for us to continuously track progress—or the lack thereof—has allowed us to identify and deal with challenges and impediments early. Unfortunately, a challenge we haven’t yet conquered is getting around the human factor of getting everyone to regularly update their work items in a timely fashion without constant reminders.
As shown in Figure 11, we use a combination of regular team meetings, an ongoing collaboration strategy and technology to define and communicate the team purpose, vision, product backlog and project status with the team and stakeholders. This ensures we get continuous buy-in and commitment from everyone, even when working in a disconnected, virtual, isolated and lonely ecosystem.
Figure 11 Using Technology for Collaboration and ALM
It’s amazing how an isolated problem becomes a team challenge when its existence and potential impact on the team objective is transparent. Using TFS and our Ruck process has allowed us to keep the status and challenges “in the face of everyone.” The result is that the team often identifies and resolves challenges before having to report them at the next weekly stand-up meeting.
There are many recommendations, skills and practices that will help you improve the virtual team environment, the collaboration and effectiveness of each team member, and the quality of the deliverables. For us, the seven top recommendations include:
In a future article, we’ll investigate how the Rangers are using VM Factory and the Visual Studio testing tools in the distributed and virtual team environment to promote consistency and raise the overall quality of our out-of-band solutions.
Brian Blackman is a principal consultant with the Microsoft Services Partner ISV team, focusing on affecting ISV partners’ success in engineering and in the marketplace. He has an MBA and is a CSM, 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.
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 forsimplicity and maintainability in software engineering. His blog is at blogs.msdn.com/b/willy-peter_schaub and you can follow him on Twitter at twitter.com/wpschaub.
Thanks to the following technical experts for reviewing this article: Ben Amodio, Mike Fourie, Bill Heys, Bijan Javidi and Patricia Wagner
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.