An introduction to Agile development with Team Foundation Server: TFS Support for Agile practices

1. TFS support for Agile practices
2. Tailoring TFS to support your Agile process with process templates
3. Iteration planning
4. Information radiators
5. But I’m not a .NET developer
6. Agile support in TFS 11

A topic that comes up reasonably often is how Team Foundation Server supports Agile development. This series of posts provides my response to that query. This is the first in the series and I’ll update the list of topics over time as there are some other posts I intend to add, as well as linking to published topics. Unless otherwise mentioned all references are to Team Foundation Server 2010 – i.e. the current release, although I will run through what’s coming in the next version in a later post.

Agile practices

I won’t summarise what, when, how and why Agile, as there are plenty of great resources covering that already. I want to start by explaining how TFS supports the key Agile practices. For now this won’t be related to a specific process, such as Scrum, but kept at a generic level. Kent Beck wrote a whitepaper called Tools for Agility and I want to outline how TFS supports the the Agile practices in the paper. I’ll quote from the paper:

“The Agile Manifesto says, “We value processes and tools, but we value individuals and interactions more.” …

This is the “while there is value in the items on the right, we value the items on the left more” from the Agile Manifesto.

“Some have taken it to mean … that the agile development community is populated by neo-Luddites tossing tool CDs onto bonfires and scratching project plans on cave walls with the burnt ends of sticks.”

I really empathise with this, I’ve seen teams adopting Agile that throw away all tools and that believe post-it notes will solve all problems.

“I appreciate the opportunity to counteract this impression, to make the case for the appropriate use of tools (and processes) in agile development, and to look forward to the evolution of software development tools.”

This is the key to me; there are aspects of Agile that require, and I’ll emphasise require, the appropriate use of tools. It’s not a question of whether to use a tool for these areas but rather which tool. In the paper, Kent draws a (stylised) map between practices and tools:

Given that the tools are required in the given areas to support the high-level practices, I want to examine how TFS supports each of the tooling areas highlighted in this diagram.

Configuration Management

Agile teams will be rapidly iterating code and releases, requiring rock solid source code control support. At the infrastructure level this means you need high performance and scalability, including support for distributed teams, if required. TFS stores all data, including source code, in SQL Server and this provides the ability to scale from running full TFS on a laptop (e.g. my laptop) to supporting a distributed team of thousands with suitable hardware and TFS architecture (e.g. the Microsoft Developer Division of about 3,800 people around the globe).

Some specific features that will help support Agile teams:

• Folder versioning. Rapid refactoring often involves changing not just the code but also it’s structure. TFS Folder versioning supports this.
• Branching . Within an iteration/sprint each individual/pair/feature crew might want their own branch or branches in order to support parallel development across the team. TFS branching helps to support this and, importantly, to track what’s happening with branch visualisation and timeline tracking. Branches are now first class citizens in TFS 2010 and as such have fine grained permissions and capabilities.
• Shelving . This TFS feature allows a developer to “park” code in a sand boxed area on the TFS server such that it is safe, but won’t effect anyone else’s code or any builds. This can help with safely sharing code, including code reviews.
• Annotation . In a rapidly changing codebase annotation allows you to overlay who did what and when into the source code itself. This can help quickly identify exactly what lines of code were changed, by who, and for what reason, in a specific build.
• Check-In Policies . Rapid code changes and check-ins shouldn’t mean that code quality suffers. TFS check-in policies allow you to define a quality gate to ensure that all code reaches a certain quality before it reaches the repository. For example, specific unit tests have been run and passed and code has been associated with one or more user stories or tasks.
• Change Sets . Maintaining the context of a check-in becomes even more important with rapid, frequent check-ins. Why did that code get checked in? A change set identifies which files were checked in and what user stories or tasks were associated with the check-in. To be able to go back and understand why changes were made (e.g. these files were checked in to fix bug 23) can save considerable time and effort at a later point in the project.
• TFS Proxy Server . Allows a remote team to get versions of the code and checkout from a local cache, rather than having to traverse a WAN to the central TFS server.

 

Continuous Build

TFS includes an automated build engine. This provides built-in support for scheduled builds, such as nightly or weekly builds, as well as continuous integration. This link provides a summary of Martin Fowler’s practices that constitute continuous integration and TFS supports all of these practices through capabilities such as:

• Support for multiple build machines. TFS 2010 introduced a build controller, which controls one or more build agents. This allows for a build farm (one or more build machines) to distribute load and help deliver rapid releases.
• Gated check-in . This new build trigger takes the pending changes and runs the build in a shelveset on TFS. Only if the build is successful do the pending changes get checked in. Otherwise, the failed build stays in the shelveset and the submitting user is warned. This mechanism helps drive quality code check-ins and reduce the risk of breaking the (integration) build. Gated check-in also reduces the need for check-in policies to be separately configured, reducing the maintenance effort.
• Build logs.Why did this build get triggered? Who by? What was built? What tests were run? What user stories, tasks and bugs were addressed in the build? Where do I get the output of the build? Is it ready for testing? All of these queries and more are succinctly answered in the generated build log.
• Build notification. Having continuous builds in place is of little value unless the development team takes broken builds seriously. This is primarily a cultural change for teams adopting Agile but the cornerstone is having clear visibility of the builds so that failed builds are identified quickly. TFS 2010 provides a build notification tool as standard, email alerts can also be configured and there a number of third party integrations that use the TFS API to increase visibility of builds, such as a TFS build screen saver, Brian the build bunny and Black Marble’s Phone Explorer.
• Lab Management . TFS 2010 introduced Lab Management, which introduces support for virtual test environments. The combination of TFS automated builds and Lab Management means that a build can not only get the source code, label it, compile it and run unit tests on it, but also spin up a virtual test environment, deploy the build across one or more test machines in the test environment and then run automated tests before tearing down the environment. This is less likely to be configured for continuous builds (because of the time required) but does allow scheduled builds to run through an automated deploy and test cycle, helping to functionally test much closer to the code being available.

 

Unit Test & Refactoring

I’ve combined these two practices as they are often two sides of the same coin. Unit testing and refactoring are supported at two levels; in the editor, e.g. Visual Studio, and in the repository, i.e. TFS. Visual Studio provides unit testing and Test Driven Development (TDD) support as well as other tools to help increase code quality such as code coverage, code metrics, test impact analysis and static code analysis, together with architectural tools such as code visualisation and architectural dependency checking. These all support iterative development of code by helping confirm the quality of that code as quickly as possible.

TFS supports these primarily by providing mechanisms to automate the use of these tools in a controlled way to either ensure quality prior to check-in with check-in policies or as part of a build as discussed in the section above. Either way the intent is to discover problems as fast as possible, before the problem becomes more complex, difficult and expensive to fix.

Transparency

Software development teams need to report on their progress. Reporting involves data collection (“have you finished that task?”) and reporting (aggregating, analysing , extrapolating etc.). TFS allows you to minimise data collection by automatically collecting metrics from everyday activities. For example, marking a bug as closed generates a metric without the individual having to explicitly update any other system or tell anyone. All of these metrics are then pushed into SQL Server Analysis Services to refresh the reporting cube. All of the supplied reports then have updated data and most of these reports are by default displayed in one of the TFS project’s SharePoint dashboards. This means that information about the progress of the project is collected automatically, displayed automatically and made available to the extended team to view and understand what and how the team is doing. This provides a mechanism for open and transparent reporting that allows the tooling to do the grunt work. As Kent Beck states in his paper:

“A transparent team can more cheaply and effectively coordinate their efforts towards shared goals. Acting transparently sends a signal to others that they can trust you. Trust, when realized, reduces the friction of development as people focus more on what they are accomplishing together and less on avoiding blame.”

There are specific reports that support Agile processes, such as velocity and burn down which I’ll cover in a subsequent post, but the key here is that regardless of the report contents, TFS provides a mean to support transparency in projects.

Summary

I hope this is a useful summary of how TFS supports the key Agile practices. In the next post we’ll take a deeper dive into TFS support for specific Agile processes, in particular Scrum.

Cheers,
Giles