DotNetCurry Logo

Agile Development Best Practices Using Visual Studio 2015 and TFS 2015

Posted by: Gouri Sohoni , on 1/28/2017, in Category Visual Studio, VSTS & TFS
Views: 2526
Abstract: This article will discuss best practices for Agile Development from a developer’s perspective and how tools like Visual Studio help implement these Agile best practices.

This article will discuss best practices for Agile Development from a developer’s perspective. While doing so, this article will discuss tools like Visual Studio 2015 and Team Foundation Server (TFS) 2015 that can help in Agile Development.

Note: Most of the functionality available with TFS 2015 is available with Visual Studio Team Services (VSTS).

This article is published from the DNC Magazine for Developers and Architects. Download this magazine from here [PDF] or Subscribe to this magazine for FREE and download all previous and current editions.

Agile software development involves creating increments of working and demonstrable software within stipulated time period. It evolves through the collaborative efforts of a cross-functional motivated team. People think that there is no planning in agile, but contrary to the belief, Agile teams do plan features they are going to implement. But usually these plans are for the immediate future only. Agile process involves - development with new techniques and tools, on time delivery, finding bugs early, and having a positive approach for change.

We will not be delving into details of the Agile Manifesto and Agile Principles. There is plenty of material available on these topics.

Being agile involves a lot of team efforts. Getting feedback from customers or stakeholders early and quickly, reduces development efforts. Improving quality by using tools or by identifying bugs at an early stage help in making the team agile in software development.

Best Pratices for Agile Development

Agile Practices – Management and Developer

There are 2 main divisions for Agile practices - one is from the management’s perspective, and the other is from a developers’ perspective.

The management practices are Sprint Planning, Capacity Balancing, Spring Monitoring, Kanban board and Sprint Review & Retrospective. All these management practices have excellent support when we use Team Foundation Server (TFS) 2015 or Visual Studio Team Services (VSTS).

However in this article, we will focus on the developer’s perspective, and demonstrate how Visual Studio 2015 and TFS 2015 provides support for implementing agile practices.

Agile Practices – Developer’s Perspective

Test Driven Development or TDD

Test Driven Development (TDD) is a technique where you write the test first, and then write the functionality that fulfills the test. It is similar to defining the technical requirement first, which is represented by the test, and then create the code to satisfy that requirement.

The test fails for the first time as you have not written the functional code.

As we build the code, the test passes at certain points, and then we can stop adding code. This process helps in reducing development time and also reduces the bugs that may crop up.

Proper usage of TDD requires that developers have knowledge of how the applications will be used in a real situation. TDD ensures that different functionality in the application is properly tested. As the tests are being executed even before writing the code, debugging at a later stage can be avoided.

In order to write TDD, you should first know what you want to do and how to test it. Write a small test with only a stub in it because of which the test will fail. Now write code to pass the test. Run the test and watch that is passes. If it fails, fix it, as you must have written something wrong.

There is no direct support for TDD in Visual Studio 2015, but we will see a small walkthrough of writing TDD.

Create a project of type Unit Test Project which has a default class with the test method.


Change the name of the class so that the refactoring is automatically taken care of. See the following figure:


Observe the attribute for the class and test method which is added automatically, as shown in the following figure:


We can execute this test method using Test Explorer, and it will fail as there is no functionality. Add a new project to the solution of type class library and write some code in it.

public class CalculatorClass
    public int Sum(int[] num)
        int result=0;
        for (int i = 0; i < num.Length; i++)
            result += num[i];
        return result;

Now add a reference from unit test project to the class library project.


Change the code in Test Method so that it tests the functionality.

public class CalculatorTest
    public void TestMethodSum()
        int actual, expected = 45;
        CalculatorClass target = new CalculatorClass();
        actual = target.Sum(new int[] { 5, 10, 30 });
        Assert.AreEqual(actual, expected);

Run the test from Test Explorer and see that it passes now.

Unit Tests Support in Visual Studio

Visual Studio provides excellent support for writing unit tests. The unit tests are not only limited to Microsoft framework, but third party testing is also supported.

Visual Studio 2015 supports the following automated tests - Unit Tests, Coded UI Tests, Web Performance Tests, Generic Tests, Load Tests and Ordered Tests.

Unit testing has already been discussed in this article

Coded UI Tests (CUIT) are for testing the User Interface of an application. We can create CUIT by either recording the actions using CUIT Builder or use the already recorded actions (using Microsoft Test Manager). Another option to write CUIT is hand coding. You can find more information about CUIT at

Web Performance Tests are used for HTTP requests and responses for a web application or a web site. You can also add validations, as well as parameters to the test.

Generic Tests are executed outside the Microsoft testing environment and returns a result as pass of fail. In case we need a particular sequence for executing tests, we can use Ordered Tests.

Once all the tests are written and executed, we can find out how these tests perform across different networks, and different browsers. We can achieve this by using Load Tests. We can create a scenario in which we can determine the percentage of various networks, browsers, tests. We can also specify the number of concurrent users, and if there are any think times etc. Load Testing can be executed either with Visual Studio 2015 or Visual Studio Team Services.

Pair Programming

In this technique, two programmers work together at the same workstation. One writes the code and the other observes it, and reviews the lines of code. The reviewer gives suggestions to improve the code wherever possible. The one who writes the code is termed as driver, and the other as navigator. This increases the quality of software. Pair programming requires social communication and will fail if the pair is not working in tandem.

There is no direct support for pair programming via a tool like Visual Studio 2015. It is achievable with some experience, as one may initially feel awkward to start writing code in pair. It should be noted that two people are working together and none of them is mentoring the other. Instead, this is a collaborative effort to achieve high quality code.

I personally have followed this practice many a times along with my husband while writing code for our products and it gives excellent results. Our co-ordination solves many problems before they become big issues while writing code.

Refactoring Code

This process consists of reconstructing existing code. The external structure for the code remains as it is, but the internal structure can be changed to make it more elegant, easy to understand and maintainable. Refactoring increases the readability of code and decreases complexity. It is a good idea to write unit tests before refactoring. The techniques for refactoring are encapsulating field, extracting a method, renaming, extracting interface, removing parameters.

Visual Studio 2015 supports Refactoring techniques. Extracting a method creates a new method by extracting selected code. A new method is created and the selected code is replaced with the call to the new method. This is one of the best coding practices. It creates granular approach to the code and reduces code duplicity.

Select the code against which you need to add a new method > right click on it > select the menu for Quick Actions and Refactoring.


Selecting the menu provides the option for method extraction.


This is followed by options for renaming the method from NewMethod to a proper name, adding comments, adding any strings etc. If renaming is selected, the two references will be automatically changed.


Rename Refactoring is useful in renaming identifiers like fields, variables, methods, classes, properties or even namespaces. We have already seen class renaming in TDD. When a variable is renamed, it also updates the usage of the variable. Changing the method name will update all reference to the method as seen in the previous refactoring technique. Changing the namespace will change the using statements and also the fully qualified names.

The Encapsulating field refactoring option lets us create a property from a field. All the code references will be automatically updated. In order to use it, right click the line in Visual Studio where the public field is declared, and select the menu for refactoring. It shows options to encapsulate the field to use a property as follows:


The other option is to encapsulate but still keep using the field:


Remove parameter refactoring technique is used to remove parameter from methods/ delegates. The parameter is removed and a new declaration is shown. Select the method from which to remove the parameter, and select the option for refactoring followed by change signature. This step removes the parameter from the signature of the method, but not from the body of the method. This will lead to errors during the build process in case you forgot to remove the parameter from the method body.


Feature Driven Development (FDD)

This is an iterative and incremental agile development process. It serves the purpose of delivering demonstrable software in a stipulated time period (sprint). This practice is more useful for large projects and teams.

Code Review

Agile teams are cross functional. A part of this functionality can be achieved via code review. Code Review helps developers understand the code base. When one developer completes writing code, another developer also called as the reviewer looks into the code for logical errors, checks if the functionality is matching the requirement, and if the unit testing suffices the functionality. He/she can also find out if the guidelines for code writing are followed or not. In agile development, Code Review is very useful as no one person is solely responsible for the complete code base.

There is a direct support of Code Review in TFS or VSTS while writing code with Visual Studio 2015. There is a special work item of type Code Review Request for a developer to initiate code review. The reviewer can then send a Code Review Response in return with the comments and suggestions.

After writing code, a developer can select Request Review option from Team Explorer – My Work.


The Code Review Request work item looks as follows:


You can add multiple reviewers and click on Submit Request. The reviewer can review the code, provide comments and suggestions.


Observe that the files are included in a review, and once selected, show the changes made by the requester. Comments for an individual file can be added and finally sent by clicking on Send Comments. The requester then takes the necessary actions on the code and once done, the code can be checked in. The code is automatically put in the ShelveSet, which can be un-shelved and later checked in. Code Review can be closed once the code is un-shelved.

CICD (Continuous Integration Continuous Deployment)

Continuous Integration and Continuous Delivery are the two features of agile practices which help in reducing the sprint duration.

As a developer, you may be working on user stories or product backlog items and writing code for the tasks assigned to you. As this is a collaborated development, other developers are also doing the same. We need to create an integrated build with all the code, from all the developers. The moment any developer checks-in code, a server side build is triggered to find out if the new code does not break the application when integrated with the latest code in the source control.

This can be easily achieved by setting the trigger as Continuous Integration for the build created with TFS 2015 or VSTS. Whenever a developer checks in code, the build will get automatically triggered with latest code in source control.

Here is the layout for such a build:


We can also specify the trigger for Gated Check-in which will ensure that the code will be checked-in only if it can be built with all the latest code in the source control.

Continuous Delivery is taking the concept of CI further. Once the application is built, it can be taken to the next stage to QA lead for testing or to the production depending on the requirement. This can be achieved with TFS using Release Management.


In this article, we discussed some features of agile process from a developers’ perspective. There are a lot of best practices which can be implemented while following the agile process. We also explored how tools like Visual Studio help implement these Agile best practices.

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on Google+
Further Reading - Articles You May Like!
Gouri Sohoni is a Trainer and Consultant for over two decades. She specializes in Visual Studio - Application Lifecycle Management (ALM) and Team Foundation Server (TFS). She is a Microsoft MVP in VS ALM, MCSD (VS ALM) and has conducted several corporate trainings and consulting assignments. She has also created various products that extend the capability of Team Foundation Server.

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!