[Reposted from the old blog site in order to continue the series here]
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.
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:
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.
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.
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.
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:
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:
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.
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:
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.
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.