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.

Ruck?

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

Challenges of the Virtual Ranger Team Environment

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.

Analyzing and Learning from Recent Projects

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:

• Having team members sign up for the task in which they have interest
• Timely e-mail reminders of key checkpoints or milestones with work progress visualization
• Weekly meetings

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.

Understanding and Dealing with the Impact of Cultural and Working Conditions

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.

Understanding and Dealing with Motivations and Commitments

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.

Our Top Recommendations

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:

1. Clearly define and foster a team identity and vision.
2. Clearly define the process, such as the Ruck process.
3. Clearly define the communication guidelines and protocols.
4. Clearly define milestones, share status and celebrate the deliverables.
5. Implement an ALM infrastructure that allows the team to collaborate effectively, such as TFS and associated technology.
6. Promote visibility and complete transparency on a regular cadence.
7. Choose your teams wisely, asking members to volunteer and promoting passionate and get-it-done individuals.

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

Die Visual Studio ALM Rangers haben gelernt, dass wertvolle Lektionen zum Organisieren und Verwalten von Teams mit Mitgliedern auf der ganzen Welt – alle haben verschiedene Fähigkeiten Motivationen, Verpflichtungen, Projekt-Zugehörigkeiten und Einschränkungen. Hier teilen wir unsere Erfahrung und bieten Anleitungen für das Arbeiten mit Teams in weniger als idealen verteilten und virtuellen Umgebungen.

Zur Erinnerung, sind die Rangers eine Gruppe von Experten, die Zusammenarbeit zwischen der Produktgruppe Visual Studio, Microsoft Services und Microsoft MVP Most Valuable Professional () Gemeinschaft durch fehlende Funktionalität Adressierung, Annahme Blocker entfernen und Veröffentlichen von Empfehlungen und Anleitungen, die basierend auf praktischen Erfahrungen zu fördern.

In diesem Artikel beginnen wir durch unsere benutzerdefinierte Projekt-Management-Prozess namens Ruck definieren; dann wir bieten eine Zusammenfassung der virtuellen Team Herausforderungen und Beobachtungen, die mit Rangers Projekte mit Ruck mit Visual Studio Team Foundation Server (TFS) als die Lösung (Application Lifecycle Management, ALM) freigeben. Wir schließen mit unseren Empfehlungen für die Rangers und andere virtuelle Teams in ähnlichen Umgebungen.

Ruck?

Die Ranger wurden Hund Fooding Visual Studio TFS als ALM-Lösung mit dem Ziel der Verbesserung der Qualität unserer Business Operations und Lösungen der Produktion. Ein Kernbereich mit potenziellen Auswirkungen, riesige Investitionen wurde das Prozessmodell und den zugehörigen Anforderungen-Management-Prozess. Unsere Absicht Core ist eine wiederholbare und systematische Weise suchen und Adressierung der Ranger Initiativen der killer-Features zu erstellen. Definieren und die Weiterentwicklung des Prozesses hat sich eine große Herausforderung erwiesen – etwas wie ein Flugzeug-Modul während des Flugs beheben – aber mit mehrere Projektteams erfolgreich mit Variationen des Prozesses können betrachten wir es als eine solide Säule. Um sicherzustellen, dass wir keine jemand an die Methoden zu verwirren oder ärgern Prozess fanatisch, haben wir vorläufig nennen unsere angepassten Prozess "Ruck", die in der Welt Rugby bedeutet "loose Scrum."

Herausforderungen der virtuellen Ranger Team-Umgebung

Eine häufige Herausforderung bei Rangers ist, dass jeder einzelne seinen Arbeitsplatz, zu Hause und Ranger Welten und Verpflichtungen auszugleichen. Die meisten Ranger Aktivitäten haben die niedrigste Priorität dieser drei und oft nachts passieren. Was das Ökosystem Rangers einzigartig ist, dass unsere Lösungen können nicht freigegeben werden, wenn sie bereit sind, aber implizit Zeit-boxed mit Technologie-Meilensteine und die Nachfrage nach der Lösung. Wie wir haben noch um eine magische Weise erweitern die Anzahl der Stunden pro Tag zu finden, wir auf eine einzelne Ranger schiere Leidenschaft für die Technologie und die Gemeinschaft zu helfen, freie Zyklen für Ranger Aktivitäten finden verlassen. Obwohl dies erstellt eine heroic IT-Experten, die zahlreiche Kontextwechsel absorbieren und qualitativ hochwertige Leistungen zu produzieren, kurz gesagt, ad-hoc- und zufällige Schüben, außerdem eine Form der anti-Scrum Prozess vorgestellt.

Blick auf die verschiedenen Standorte unserer Teammitglieder im Index Rangers (bit.ly/9LKgZb), die derzeit enthält nur eines kleinen Prozentsatz der Rangers, erkannten wir, dass die Rangers und somit unsere Teams, um den Planeten verteilt sind. Wir haben bewusst sein, die wir mit einer Vielzahl von unterschiedlichen Kulturen arbeiten und, dass wir können über kulturellen Normen oder Zoll Annahmen, weder nehmen Sie die Umgebungen für gewährt. Folglich implementieren wir situational Leadership und Prozess in unseren Projekten um kulturelle Unterschiede zu berücksichtigen (Siehe das Buch "Führung und die eine Minute Manager: erhöhen Effizienz durch Situational Leadership" [Morrow, 1985] von Kenneth H. Blanchard, Patricia Zigarmi und Drea Zigarmi).

Siehe Abbildung 1, eine große Auswahl an Zeitzonen erfordert, dass einige Team-Mitglieder bis spät bleiben gelegentlich oder zu ungewöhnlichen Zeiten für eine Besprechung Status oder Design aufstehen. Dies ist weder Spaß noch produktiver.

Abbildung 1 typische Rangers Besprechung über Zeitzonen hinweg

Die Kombination von Rangers aus verschiedenen Ökosystemen wie Produktgruppen, Services, Partner, MVPs und Gemeinschaften stellt eine Vielzahl von Motivationen und Verpflichtungen, die alle vom Programm Rangers Ökosystems und Anerkennung angenommen werden.

Während unser Ziel ist es für maximale Transparenz und Zugriff auf alle Elemente von allen haben wir Randfällen aufgrund von Geheimhaltungsvereinbarungen, Lizenzierung und Infrastruktur-Einschränkungen.

Die häufigen Kontextumschaltungen – und starten und Beenden von einem Projekt oder Feature Bereich – ist das schwierigste Problem, weil es sich um eine demoralisierenden Erfahrung des Teams ist. Dies kann machen Sprint Burn Down Charts interessantes zu lesen, aber schwer zu effektiv verwenden für Status und Fortschritt nachverfolgen, wie Sie, in sehen können Abbildung 2. Das erste Diagramm in Abbildung 2 zeigt eine Steigerung in Task Arbeitsaufgaben als Einzelperson oder Team lernt gibt es weitere Implementierung des Produkts rückständigen Artikels als erster realisiert. Das zweite Diagramm zeigt Beenden der Arbeit an einem Projekt aufgrund von Verpflichtungen des Kunden. Im Geschwindigkeitsdiagramm Abbildung 3 veranschaulicht unsere Aussage bezüglich der Auswirkungen der Kontextwechsel und das Starten und Beenden von Featurebereiche.

Abbildung 2 Sprint Burn Down Charts widerspiegeln Herausforderungen (zum Vergrößern klicken)

Abbildung 3 Projektgeschwindigkeit

Schließlich variiert, da die Freiwilligkeit des Programms Rangers, Rechenschaftspflicht erheblich, bieten einige Optionen, um eine Verpflichtung zur Übermittlung zu erzwingen. Glücklicherweise die meisten Rangers halten selbst verantwortlich und stellen daher die meisten Ranger Teams auf jedes Mal.

Analysieren und lernen aus zuletzt geöffnete Projekte

Wie bereits erwähnt, haben wir einige Herausforderungen bei Teams nicht an einem einzigen Standort befindet, wenn Teams sind in verschiedenen Regionen und wenn es keine individuelle Verpflichtung jenseits der Passion to be a Ranger beitragen. Wir haben versucht, die an diese anzupassen, indem die Strukturierung von Teams nach Geografie, aber häufig nicht Arbeit da es gegen unseren Glauben an Vermietung Entwickler geht wählen Arbeit aus Gebieten, in denen sie Interesse haben, auch wenn es nicht ihre aktuelle Geographie auszurichten. Aus diesem Grund haben wir selbstorganisierende und verlassen sich auf die Erfahrung, um zu bestimmen, was best Practices für ein bestimmtes Projekt arbeiten.

Die Beschaffenheit des unsere virtuellen Ökosystem zwingt uns zahlreiche vordefinierte Regeln, Prozesse wie Scrum zu brechen. Wie in Kanban (Siehe das Buch "Kanban: erfolgreiche evolutionären Änderung für Technologie Unternehmen" [Blue Hole Press, 2010], von David j. Anderson), passen wir unser Prozess für unsere Bedürfnisse. In vielerlei Hinsicht beziehen wir situational Leadership Projekte, abhängig von der einzigartigen Attribute von jedem speziellen Projekt. Beispielsweise führen wir wöchentliche treffen, da jeder Tag Arbeitsplätze hat. Tägliche Besprechungen ("Stand-Ups") sind zu begrenzt und zu häufigen. Darüber hinaus sind unsere treffen klassische Stand-up Scrum-Sitzungen nicht, weil zu wenige Personen gleichzeitig erfüllen können. Dies zwingt regelmäßig uns dazu haben zwei Sitzungen an einem Tag mehrere Zeitzonen gerecht zu werden.

Ranger Projekte sind komplex und erfordert, dass wir Transparenz, Kommunikation, Prüfpunkte und Besprechungen häufig haben. Weil jeder andere Verpflichtungen, wie z. B. Familien und ihre Arbeit Tag müssen Teams eingegrenzt zu vermeiden. Wir lernen und anzupassen, wir unsere eigenen Muster Projekt einrichten und für bessere Einfluss anzupassen. Einige dieser Muster sind:

• Team-Mitglieder für die Aufgabe anmelden, in denen sie Interesse haben, müssen
• Rechtzeitige e-Mail-Erinnerungen Prüfpunkte oder Meilensteine mit Arbeit Fortschritt Visualisierung
• Wöchentliche treffen

Unsere vorgenannten Herausforderungen noch verschärfen als Projekt Rhythmen ändern. Dies gilt nicht nur für unsere Ranger Ökosystem; Wir erleben in vielen Projekten beim Start. Eine ordnungsgemäße Cadence mit einem neuen Team braucht ein paar Schritte und Fehlentscheidungen vor jeder schließlich synchron, ist mit regelmäßigen Rhythmus ausführen.

Wir, die Autoren habe direkt in der große open-Source-Gemeinschaft außerhalb von Microsoft, so dass hier schreiben Annahmen zugrunde liegt, die von anderen Publikationen und Blog unterstützt werden nicht gebucht. Im Gegensatz zu open Source-Projekten haben Ranger Projekte eine feste Lieferdatum Zeitplan-Mentalität. Verstehen wir, öffnen die meisten Source Projekte Schiff, wenn sie fertig oder gut genug, um die Freigabe, werden jedoch lange dieser Vorgang dauert. Für Rangers-Projekte hängen viele Menschen stark von unseren Artefakte. Wenn unsere Entwicklungszyklus zu lange dauert, kann unsere Arbeit mit einer neuen Version von Visual Studio veraltet. Mit einem festen-Lieferdatum fahren das Projekt könnte anti-Scrum gelten. Jedoch sehen wir nicht dadurch als Time-Boxing Sprints unterscheidet; Wir Time-Feld das Gesamtprojekt.

Für unsere Projekte Ranger verwenden wir die MSF for Agile Software Development V5. 0 oder die Prozessvorlage Microsoft Visual Studio Scrum 1.0; Letztere ist weit mehr beliebt, weil es leicht ist. Unsere Projekte erfordern einige mehr Planung und Design; Einige Methoden Prozess bezeichnen dies als die Pregame. Wir verwenden eine Sprint 0 für diese Preise Arbeit, um einer Beteiligung an der Fahrbahn und Time-Feld festlegen, das Planen und entwerfen. Dies gewährleistet, dass das Startdatum für die Entwicklung und Ziele bekannt sind. Während Sprint 0 wir führen erforderlichen teamtraining, richten Sie die Umgebung, Planung, Forschung, epic Priorität abstimmen und überprüfen unsere Ruck-Prozess (wird später ausführlicher ePen besprochen). Einrichten von Umgebungen ist äußerst wichtig, wenn man bedenkt, dass ein Produkt wie Microsoft Lab Management.

Wie in Scrum erfordert unsere Ruck häufige Prüfpunkte. Wie bereits erwähnt, sind tägliche Besprechungen zu viel für das Team Ruck. Unsere Version von einem Stand-up ist eine wöchentliche Besprechung oder eine Reihe von Besprechungen in unterschiedlichen Zeitzonen, die in Microsoft Lync durchgeführt. Diese Sitzungen werden in classic Mode durchgeführt, wo Teilnehmer darüber, was gebeten werden, diskutieren, welche arbeiten sie auf Weiter und gibt es Hindernisse. Darüber hinaus verwenden wir die Gelegenheit, alle wichtigen Nachrichten kommunizieren, und wiederholen die Vision des Projekts/Sprint. Wir haben gelernt, dass die Verwendung von Grafiken am effektivsten ist. Ruck Master oder der Entwicklungsleiter wird seinen Desktop Sprint-Burn-Down-Diagramme anzeigen und zeigt eine Liste von Arbeitsaufgaben für die aktuelle Teammitglied Adresse freigeben. Visuals und Sichtbarkeit sind Schlüssel!

Ranger Projekte haben oft Schwierigkeiten, die konsistente Geschwindigkeit erreichen, wie Sie, in sehen können Abbildung 3. Dies ist aufgrund der Natur unserer Teams anti-Scrum wobei Teamkapazität immer im Fluss. Teammitglieder können ein Projekt in einem Augenblick abweichen, verlassen wir kreativ Arbeit verwalten oder neue Contributors erbitten. Da dies eine gemeinsame Umstand für unsere Projekte Ranger ist, haben wir ein Manifest Ranger betonen die Bedeutung der Verpflichtungen erforderlichen machen, wenn ein Projekt Ranger beitragen eingeführt.

Wir haben gelernt, dass kleinere Projekte und Team kleinere bessere Ausführung, ordnungsgemäße Cadence und stärkeres Engagement für Team-Mitglied aktivieren. Auch scheint es, dass es schwieriger für jemanden, der ein kleines Team als ein größeres Team aufzugeben ist. Abbildung 4 ein Sprint Burn Down-Diagramm veranschaulicht, wo wir gute Cadence Work Item Abschluss erreicht haben und die tatsächliche Entwicklung von Burn Down besser im Vergleich zu den vorherigen Burn Down Charts angezeigt, den idealen Trend entspricht Abbildung 2.

Abbildung 4 bessere Cadence Ergebnisse besser Burn-Down

Wir verwenden ePen eine allgemeine Ansicht oder Aufzug Tonhöhe für ein KE zu skizzieren. Eng der Agile-Community Verwendung ePen zugeordnet: eine Geschichte mehr umfassende für ein Feature zu erzählen, da Kunden vor-Ort-Details ohne jede zeitliche Verzögerung bereit ist. Sie können eine epische als eine Geschichte betrachten, die erklärt, warum jemand möchte unsere Lösung installieren oder laden Sie unseren Leitfaden. Das ePOS führt die Vision für ein Feature und steuert die Erstellung von verwandten Benutzergeschichten aus denen wir unsere Arbeit erstellen. Da die Out-of-the-Box-TFS-Prozessvorlagen keine epische Typ Element arbeiten, und wir haben Einschränkungen vermeiden wir wo Template Customization, Präfix wir das Feld Titel des Textabschnitts mit "Epic" (siehe Abbildung 5), und wir geben diese Arbeitsaufgabe eine Priorität von 0 (null) für einfache Identifizierung in Berichten oder Berichtsfilter.

Abbildung 5 Verwenden des Epic Präfix in den Titel des Benutzers Story Arbeitsaufgabentyp (zum Vergrößern klicken)

Ranger Projekte sind durch mehrere lose definierte Rollen, wie Entwickler, Tester, Ruck-Master, leitende Entwickler, der Besitzer der Produkt, epic Blei und Reviewer dargestellt. In vielen Fällen kann ein Team-Mitglied mehr als eine Rolle übernehmen. Eine Person könnte ein Entwickler für eine Funktion, die ein Tester für eine andere Funktion und Prüfer für ein anderes Projekt. Drei Core Rangers spielen in der Regel steadfast Rollen zu jedem Projekt: Bijan Javidi als Projektmanager, Willy-Peter Schaub als leitende Entwickler und Brian Blackman als Ruck Master und Trainer.

Die Notwendigkeit für häufige Prüfpunkte und vollständige Transparenz macht die Kommunikation einen entscheidende Teil unseres Prozesses und Ökosystem. Gute Kommunikation erstellt unterstützend, lancasterschule und kollaborative Webs innerhalb der geografisch verteilte Teams. Um ein Gefühl der Zugehörigkeit zu erstellen, haben wir immer virtuelle Kick-off Onlinebesprechungen, während, die wir gemeinsame Ziele, Vorgaben, Motivation, Visionen, Vorteile, Bereiche und Einschränkungen definieren. Am wichtigsten ist, stimmt das Team während dieser Kickoff-Meeting über Leitlinien für Infrastruktur und Kommunikation.

Ruck von Ruck Besprechungen, später, diskutiert minimieren die Notwendigkeit für jedermann in wöchentlichen Stand-up-Sitzungen vorhanden sein und sicherstellen, dass der Status und die Hindernisse transparent, mit ad-hoc-spontane und vordefinierten Kommunikation sind. Mithilfe des TFS Work Item Tracking (WIT) und der ePen zuordnen, wie in gezeigt Abbildung 6, wir Informationen erfassen und Status Informationen wie Status, Backlog, Features, Akzeptanzkriterien, Bugs und Hindernisse. Stand-up Minuten werden in Wikis und Design-Informationen in Dokumenten auf dem gemeinsamen Portal dokumentiert. In einigen Fällen werden die Minuten in der Quellcodeverwaltung gespeichert die – wie alle anderen Komponenten der Infrastruktur – zugänglich von überall in der Welt ist.

Abbildung 6 Team Foundation Server Artefakte die Hierarchie der Ranger PBI/Epic/Aufgabe zuordnen

Die primäre Fahrzeuge für Kommunikation und Zusammenarbeit sind die freigegebenen Portal und am wichtigsten, e-mail. Verteilerlisten und ein gesteuertes Vokabular verwenden, werden E-mails für alle Beteiligten, einschließlich Rangers außerhalb der Gültigkeitsbereich des aktuellen Projekts freigegeben. Dadurch wird sichergestellt, dass alle Beteiligten die Informationen erhalten, die Laufwerke Transparenz und selektive lesen, um Interessenten in die Informationen mithilfe von e-Mail-Regeln, delegiert.

Verstehen und den Umgang mit den Auswirkungen der kulturellen und Arbeitsbedingungen

Kommunikation und Management-Formate unterscheiden sich in vielen Ländern. Einige Kulturen bevorzugen formale und entfernte Kommunikation mit klar definierten Rollen und Erwartungen. Andere engagieren sich in informellen, im Gesicht und oft gemeinschaftliche Management, wobei ein Zeichen von Respekt auch ein embracing "Umarmung ist". Um klar zu definieren die möglichen Probleme und sicherzustellen, dass es keine Missverständnisse, die bitter und oft getrennte Teammitglieder verursachen können, haben wir diese Vielfalt zu erkennen. Wie bei vielen anderen ALM und virtuelles Team Mieter unbedingt Transparenz proaktiv und fortlaufend Umgang mit den Herausforderungen der Kultur.

Zeitzonenunterschiede und kulturelle Unterschiede, häufig Hand in Hand gehen. Während einige Kulturen oder Einzelpersonen nichts dagegen haben rund arbeiten – oder mehr vor allem aufstehen um verrückt Stunden der Nacht zu eine Teambesprechung – andere dauert große Offensive Wenn gebeten, persönliche Zeit mit der Familie in einem Projekt zu investieren. Zum Erstellen einer Umgebung, in welches Team Mitglieder fühlen sich, bequem und zusammenarbeiten können, wenn es ist wichtig, Mechanismen finden und Zeiten, die für jeder im Team zur Teilnahme an Konferenzgesprächen oder online-Diskussionen förderlich sind. Die Mehrheit der Ranger Kommunikation und Zusammenarbeit erfolgt über E-mail und, noch wichtiger ist, TFS Teamprojekt und Portal verknüpft. Wir sorgen auch regelmäßige Team Stand-up-Besprechungen zu planen, wo wir fördern die Zusammenarbeit, Status Freigabe und kontinuierlich die Team-Identität zu fördern. Wenn wir über Zeitzonen hinweg mehrere Stand-up-Sitzungen planen, nicht Teammitglieder auf ihre eigene Zeitzone beschränkt sind. Sie sind erlaubt, um eine oder mehrere Besprechungen teilnehmen, die ihre Zeitzone und ihre geschäftlichen Verpflichtungen entsprechen. Ruck von Ruck Stand-up-Sitzungen aggregieren den Status nach oben, wie in gezeigt Abbildung 7, mit der Zusammenarbeit und insbesondere die WIT-Infrastruktur. Sobald abgeschlossen, kann eine konsolidierte Teamstatus transparent mit dem gesamten Team und Aktionäre, die mit die vom Team ausgewählten Kommunikationsmechanismen freigegeben werden.

Abbildung 7 Ruck von Ruck Stand-up-Sitzungen

Abbildung 8 zeigt das ideale virtuelle Team Betrieb in einer Zeitzone, in dem ein leidenschaftlicher Feature Lead mit einer dedizierten und konzentriert sich die Anzahl der Teammitglieder arbeitet, Featurebereiche unterteilt.

Abbildung 8 Ideal virtuellen Team

In der Realität, das typische Ranger Team ähnelt Abbildung 9, wo das Team in mehreren Zeitzonen auf der ganzen Welt verstreut sind. Das Team führt die Arbeit mit Teilzeitressourcen in verschiedenen Zeitzonen, konzentrierte sich häufig auf mehrere Featurebereiche innerhalb des Projekts.

Abbildung 9 typische Rangers virtuellen Team

Jeder Zugriff auf alle Elemente erteilen, vollständige Transparenz, Förderung einer Teamumgebung geradlinige, Nein-Politik und Making der State-of-the-Art ALM-Technologie verwenden, wir konnten uns effektiv und leidenschaftlich Projektteams zu erstellen. Siehe Abbildung 10, alle Rangers haben Zugriff auf alle Projekte über eine Rangers-Portal, Arbeitsaufgaben, Quellcodeverwaltung, projektportale und das gesamte Rangers Portal umfasst. Die Rangers verwenden die kontrollierte Vocab, um E-mails, zu kategorisieren, Vereinfachung des Filterns und Verwendung von Regeln ermöglicht.

Abbildung 10 typische Rangers-Infrastruktur

Die Vielfalt der Arbeitsbedingungen ist wahrscheinlich der schwierigste Teil unserer virtuellen Teams. Nicht nur Teilzeit Teammitglieder Rangers sind und daher regelmäßig getrennt während regulärer Geschäftszeiten, sie arbeiten häufig in sicheren Umgebungen, beschränken den Zugriff auf die Public-Domain und Rangers ALM-Infrastruktur. Darüber hinaus funktionieren einige Rangers in weniger günstigen Umgebungen, in denen Kommunikationsleitungen 9.600 Bit/s oder 56 KB-Modem weiterhin standard-Infrastruktur. Dies schränkt ihre Fähigkeit, Umgebungen und Dienste, die auf Hochgeschwindigkeits-Netzwerke und großer Bandbreite verwenden.

Arbeiten mit TFS – insbesondere Web Access-Komponenten – und unter Berufung auf e-Mail-Nachrichten für Zusammenarbeit, wir konnten uns eine effektive und zuverlässige ALM-Infrastruktur erstellen, die die Mehrheit der Rangers passt.

Verstehen und den Umgang mit Motivationen und Verpflichtungen

Was die treibenden Kräfte sind, die IT-Experten stellen Opfern persönliche Zeit für die Zusammenarbeit mit anderen Rangers und aggregate Erfahrung, wissen und Informationen in Rangers Lösungen und Anleitungen, die oft isoliert arbeiten? Jede Person hat einen anderen Satz von Motivationen und daraus resultierenden Verpflichtungen müssen identifiziert und verstanden werden, so dass jeder Ressource innerhalb des Teams effektiv genutzt werden kann.

Beim Arbeiten mit virtuellen Teams, fanden wir heraus, dass es wichtig ist, alle Team-Mitglieder zu identifizieren, die leidenschaftlich für Technologie, haben eine "get it done" Mentalität und sind motiviert, aufgeschlossen und sehr selbstdisziplin zu üben. Kein Team Identität, Technologie oder Prozess können Personen, die viel Aufsicht effektiv in virtuellen Teams arbeiten, vor allem, wenn sie auch erwartet eine führende Rolle ein Team zu erfüllen müssen.

Mithilfe der Ruck-Prozess und die TFS-ALM Lösung ePen definieren, Produkt Rückstände und Aufgaben hat sich erwiesen von unschätzbarem Wert, insbesondere, wenn Teammitglieder aufgefordert werden, sich freiwillig für Aufgaben, anstatt die Aufgaben zugewiesen werden. Darüber hinaus die Möglichkeit für uns ständig Fortschritte zu verfolgen – oder deren fehlen – hat uns zu identifizieren und sich mit Herausforderungen und Hindernisse früh erlaubt. Leider ist eine Herausforderung, die wir noch erobert haben nicht rund um den menschlichen Faktor, der immer alle regelmäßig aktualisieren ihre Arbeitsaufgaben rechtzeitig ohne ständige Erinnerungen immer.

Siehe Abbildung 11, wir verwenden eine Kombination aus regelmäßigen Teammeetings, eine Strategie der laufenden Zusammenarbeit und Technologie zu definieren und die Kommunikation im Teams Zweck, Vision, Product Rückstand und Projekt-Status mit dem Team und den Beteiligten. Dadurch bekommen wir kontinuierliche Buy-in und das Engagement von allen, sogar bei der Arbeit in einem getrennten, virtual, isoliert und einsam Ökosystem.

Abbildung 11 verwenden der Technologie für die Zusammenarbeit und ALM

Es ist erstaunlich, wie ein isoliertes Problem Team Herausforderung beim ihre Existenz und Ihre möglichen Auswirkungen auf das Ziel des Teams ist transparent. TFS und unsere Ruck hat uns halten den Status und die Herausforderungen "angesichts der jeder" erlaubt Das Ergebnis ist, dass das Team oft identifiziert und Herausforderungen, meistert bevor diese bei der nächsten wöchentlichen Stand-up-Sitzung mitteilen müssen.

Unsere Top-Empfehlungen

Es gibt viele Empfehlungen, Fähigkeiten und Praktiken, die Ihnen helfen verbessern, der virtuellen Team-Umgebung, die Zusammenarbeit und die Wirksamkeit der jedes Teammitglied und die Qualität der Lieferbestandteile. Für uns enthalten die sieben Top-Empfehlungen:

1. Klar zu definieren und ein Team von Identität und Vision zu fördern.
2. Definieren Sie den Prozess, z. B. den Prozess Ruck klar.
3. Die Richtlinien für die Kommunikation und die Protokolle, klar zu definieren.
4. Klar definieren Sie Meilensteine Status und gemeinsamen Feiern Sie Lieferbestandteile.
5. Implementieren einer ALM-Infrastruktur, die das Team effektiv, wie z. B. TFS und die dazugehörige Technologie zusammenarbeiten kann.
6. Sichtbarkeit und vollständige Transparenz auf einen regelmäßigen Cadence zu fördern.
7. Wählen Sie mit Bedacht, Ihre Teams, Mitglieder freiwillig zu Fragen und Förderung leidenschaftliche und Get-It-done Einzelpersonen.

In einem zukünftigen Artikel werden wir untersuchen, wie die Rangers verwenden VM-Factory und die Testtools in der Teamumgebung für verteilte und virtuellen Visual Studio Konsistenz gefördert und die allgemeine Qualität unserer Out-of-Band-Lösungen zu erhöhen.

Brian Blackman ist principal Consultant bei Microsoft Services Partner ISV-Team, die Konzentration auf die Auswirkungen auf die ISV-Partner Erfolg in Engineering und in den Markt. Er hat einen MBA-Abschluss und ist CSM, MCSD (C++), MCTS und Visual Studio ALM Core Ranger. Er verbringt seine Zeit Code schreiben, erstellen und Bereitstellung von Workshops und consulting in unterschiedlichen Konzentrationen und alle Dinge ALM.

Willy-Peter Schaub ist Senior Program Manager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center. Da die Mitte-80er Jahren, er hat wurde streben Forsimplicity und Wartungsfreundlichkeit bei der Softwareentwicklung. Sein Blog befindet sich unter blogs.msdn.com/b/willy-peter_schaub und Sie können ihn auf Twitter bei twitter.com/wpschaub folgen.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Ben Amodio, Mike Fourie, Bill Heys, Bijan Javidi und Patricia Wagner