Software Development is a Team Sport! : TFS

Capacity vs. Velocity

aridle — Wed, 04 Apr 2007 02:11:00 GMT

My team just completed a discussion - at times a rather passionate discussion - about what work items we should be tracking in TFS. Sanjeev, our PM, argued in favor of tracking everything we do - except meetings. I, lead dev and agile purist that I am, argued in favor of only tracking those work items that directly contributed functionality to the software we are building. But, ultimately, we decided to track both. Here's why:

The argument for tracking everything is that unless we track all activity, we might miss some task that we are required to do. For example, the development process used in Developer Division at Microsoft requires us to pass several "quality gates" (such as a security review) before we integrate our work into the central repository. This work must be done, in order to satisfy the process. And, there are several different tasks that fall out of this work. Tracking them all makes sure we don't miss any required steps.

The argument for tracking only those things that directly contribute to the software is that by tracking everything, we will not be able to accurately predict when we will be done with our backlog. Non-backlog items would be given equal weight to backlog items. So, it would be impossible to set priorities. And, it would be impossible to accurately predict when we will be "done" with our backlog.

Needless to say, both Sanjeev and I felt strongly about our positions. (We had to break out the "talking stick" in order to keep from talking over each other.) But, ultimately, we decided that we were both right. So, we're going to track everything (capacity) and flag those items that directly contribute to reducing the backlog (velocity).

Our hope is that this will give us meaningful information about the taxes our development process imposes on us, as well as a way of prioritizing work that directly relates to reducing the backlog. Once we have both numbers, we will begin trying to squeeze as much velocity into our capacity as possible. Ultimately, I would like to see a burn-down chart that looks something like this:

Where:

Total Work = All work, including features & overhead
Feature Work = All feature work (sans overhead)
Overhead Work = All non-feature work, including "infrastructure" or "process" imposed work items that do not directly contribute functionality to the resulting software.

Calling attention to the overhead (as this chart does) allows the team (and their managers) to think about how much more productive they could be without it. Some of it will be out of the team's control - like the "quality gates" here at Microsoft. But, other bits of it will be within the team's control - like sending everyone to group status meetings when a single representative might suffice.

In other words, the three trend lines could be restated as:

Projected Total = This is when we think we will finish everything.
Projected Feature = This is when we think we will finish the features.
Projected Feature without Overhead = This is the soonest we could possibly finish the backlog, assuming all overhead items were to disappear.

So, in the example chart, the team in question expects to be done in iteration 14. They also believe that they will be finished with their feature work in iteration 12. And, if they were to drop everything but the feature work, the soonest they could finish would be iteration 9. So, the overhead is costing this team a full 5 iterations!

Ultimately, what we hope to accomplish with this data is to understand what our overhead looks like, and what impact it is having on our ability to deliver. We hope this will be incredibly useful feedback to the process about the process.

Now, how do I get TFS to produce this chart?!?! Where did I put that book on on MDX?

VSTS Guidance

aridle — Fri, 30 Mar 2007 20:35:00 GMT

A few years ago, patterns & practices published a book entitled Team Development with Visual Studio .NET and Visual SourceSafe. The book offered solid advice for teams developing software atop .NET using Visual Studio and Visual SourceSafe. It covered things like structuring solutions and projects, setting up a build process, working with source control, and even setting up the infrastructure for a team development environment.

As you might imagine, the introduction of Visual Studio Team System pretty much obsoleted the book. It was a fantastic book in 2002. But, it was very specific to Visual Studio .NET (2002) and Visual SourceSafe (6.0c). So, naturally, p&p started receiving requests to update the guide as soon as customers began using VSTS with all of its new team oriented features.

Well, we've been busy working on software factories for a while now. But, recently, J.D. Meier and crew have been building up a library of VSTS guidance over on CodePlex. I just spent a few minutes exploring the site. And, I've got to say that I'm very impressed with the volume and quality of work that J.D.'s team is doing. (Full disclosure: I'm a reviewer on some of the work.) I'm also a big fan of publishing the work as a Wiki on CodePlex.

My congratulations to J.D. and the entire team! Way to go! Keep up the great work!

Team System Roadmap

aridle — Wed, 28 Mar 2007 21:46:00 GMT

Also announced recently, for those who missed it, was our Team System Future Releases Roadmap. The roadmap contains detailed information about the upcoming Visual Studio Orcas release, as well as a high level discussion of Rosario (the Team System release after Orcas). Well worth the read.

Microsoft Acquires TeamPlain

aridle — Wed, 28 Mar 2007 21:40:00 GMT

In case you missed it, Microsoft announced this week the acquisition of DevBiz Business Solutions, makers of TeamPlain Web Access for Team System. Brian Harry has all the details. The best part? Existing Team Foundation Sever customers can download and use TeamPlain for free!

Be Careful What You Wish For...

aridle — Sat, 24 Mar 2007 23:33:00 GMT

A few months ago, I ranted about TFS Process Templates. Now, I'm a member of the team responsible for building these templates for future versions of TFS. Funny how that works!

At the moment, the team is closing down work on Orcas and starting to think about what might be in the next release. It is an exciting time. And, I'm glad to be a member of the team!

Watch this space for TFS/process related posts in the future...

It happens every time...

aridle — Wed, 19 Jul 2006 20:33:00 GMT

<RANT>

It happens every time I start a new project. Team Foundation Server makes me choose a process template when I create a new Team Project. But, since I’m not happy with any of the process templates I’ve tried so far (MSF Agile, Conchango Scrum, and one custom template), I end up asking myself do I want to put up with an inadequate template or take the time to customize a new one. Neither choice is a winner.

What I would prefer is the ability to start with something, customize it a bit as I learn how it works and how it doesn’t work, and then save those changes as a new template. But, TFS doesn’t make that very easy. Sure, I can add work item types and add fields to an existing work item type. But, that only applies to one project. It doesn’t affect the template. And, it doesn’t update any other projects that are based on that same template.

Invariably, this means that each team makes local customizations to their process template that other teams don’t know about. This results in a lack of consistency that makes reporting across projects difficult. Obviously, we could take away people’s admin privileges to prevent customization. But, that also takes away their ability to adapt which conflicts with the Agilist in me.

So, here I am again, beginning a project, needing to decide which process template to use. What should I do?

</RANT>

Continuous Integration

aridle — Sat, 12 Nov 2005 06:10:00 GMT

This week, I spent some time learning Team Build and configuring a build server for Continuous Integration (CI). I’ll tell you more about that experience in a separate post. But, before I go there, I want to make sure everyone is on the same page.

For those of you unfamiliar with the practice…

Continuous Integration is a mainstay in many agile tool belts. The idea behind it is that the longer you wait to integrate your code with the code of your peers, the harder it will be to do the integration. Many developers have direct experience with this phenomenon. Those who have been through it have a name for it: integration hell.

When combined with a comprehensive suite of unit tests, CI helps to prevent integration hell by encouraging developers (and testers) to make frequent check-ins. In fact, many agile developers integrate their code as frequently as every ten minutes (or faster!). That might seem extreme. But, it’s true. We do it here in patterns & practices.

In general, the CI integration process looks like this:

Get the source from the repository and merge your local changes (if there are conflicts)
Run all of the unit tests (to make sure you didn’t break anything)
Fix any broken tests (even if you didn’t write them)
Once all of the tests pass, commit your changes to the repository

In the early days of agile, many teams serialized this process by only allowing one developer (or one pair of developers) to integrate their code at a time. This prevented people from committing conflicting changes to the repository at the same time, which made integration much easier. But, the serialization clearly introduced a bottleneck.

Enter Continuous Integration Servers…

A CI server is a build server that runs a new build every time someone commits a change to the source code repository. When a team introduces a CI server, they can stop serializing integrations because the server will inform them immediately when something breaks the build or causes a test to fail. Instead of mitigating the risk of simultaneous integration through serialization, CI servers mitigate this risk by providing immediate feedback about integration problems.

For the curious, CI Servers integrate with source control servers in one of two ways: passively or actively. Passive integration involves the Observer pattern: the CI server registers for events fired by the source control server. Active integration involves polling the source control server at predetermined intervals, looking for changes. If your source control server doesn’t expose it’s event model, then you’re stuck with active integration. The advantage of passive integration is that it gives your CI server the opportunity to control exactly which changes make it into each build. The fewer changes compiled in a build, the easier it is to debug any problems that do occur.

Are you doing CI? Got questions? Drop me a line!

TFS Beta 3 Refresh

aridle — Fri, 28 Oct 2005 10:09:00 GMT

Today is the day! Visual Studio 2005 and SQL Server 2005 are now available for download by MSDN subscribers. And, Team Foundation Server is releasing Beta 3 Refresh to stay in sync with the RTM bits.

Since most of us in patterns & practices have already made the leap to the golden bits, I need to install the TFS Beta 3 Refresh. Basically, the upgrade process is a simple uninstall/reinstall. Start by uninstalling Beta 3 in the opposite order of installation, then follow the Beta 3 Refresh installation checklist for your server deployment. In a nutshell, here’s what I did to remove TFS Beta 3 from my servers:

Uninstall Application Tier:

Team Explorer
Visual Studio 2005, including the items listed at the end of the VSTS uninstall
TFS Services

It is not necessary to uninstall WSS or IIS from the application server.

Uninstall Data Tier:

TFS Databases
SQL Server 2005, in the same order as listed in the VSTS uninstall

It is not necessary to uninstall IIS from the data server.

Installing TFS Beta 3

aridle — Thu, 27 Oct 2005 07:52:00 GMT

I alluded to the fact that it took us a couple of tries to get the TFS Beta 3 install right in a prior post. Here’s the full story…

If at first you don’t succeed…

To begin, we chose to implement a dual-server deployment, because we anticipated the most area for feedback in this scenario. We also chose to isolate TFS on a VLAN in our lab, because it seemed like the prudent thing to do with pre-release software. The dual-server deployment requires Active Directory. So, the actual servers looked like this:

Active Directory (AD)
TFS Data Tier (DT)
TFS Application Tier (AT)

The installation procedure is very well documented. At a high level, it looks like this:

Create service accounts and grant permissions
Install IIS 6.0 on DT
Install SQL Server 2005 on DT
Install TFS databases on DT
Install IIS 6.0 on AT
Install Windows SharePoint Services (WSS) on AT
Install TFS services on AT
Install Team Explorer on AT
Using Team Explorer, add users to the TFS Admin group

There were no major hang-ups in the process. The guys in our lab were able to build the servers in a few days. (They’re busy!) The only feedback I received from them was this:

In Beta 2, the installation checklists included instructions to “verify the installation.” In the Beta3 help file, the instructions are gone. After doing a little digging, I think the guys are referring to a couple of bullets in the Beta2 help file that describe how to verify that SQL Server and the Reporting services are running. In Beta3, the help file references the SQL Server Books Online for this content.
The topic “To add a user to the Team Foundation Administrators security group using the TFS Group Security Client Tool (GSSUTIL.EXE)” is misleading since the VS SDK is no longer installed with Beta 3. I verified that the file is not installed on either server.

At this point, we had a fully functional, albeit empty, TFS Beta 3 server running in our lab. Unfortunately, once we tried to migrate data from our internal work item tracking and source control servers, we realized that the migration would be a whole lot easier if both the source and destination servers were on the same network. (Doh!) Rather than moving the existing servers to the corporate network, we installed TFS a second time.

Try again...

This time, I wanted to get a better understanding of the process. So, the lab paved a couple of servers for me, and I took it from there. Since the servers were on the corporate network this time, I used the corporate Active Directory server. Just as the lab did before me, I followed the Dual-Server Deployment Checklist in the installation guide (TFSInstall.chm). Not being a sysadmin by trade, I did hit a couple of snags:

After successfully installing SQL Server and the TFS Data Tier on one server, the TFS Application Tier installation failed when it was unable to detect the SQL Reporting Services web site running on the data tier server. This was a blocking issue for me. But, a more experienced sysadmin would have known to check that ASP.NET was enabled. Turns out it wasn’t. So, turning it on allowed the install proceeded normally. (If I had taken the time to read the “verify” steps in SQL Server Books Online, I might not have hit this problem.)
The only other issue I had was with the service accounts. The documentation clearly explains that you will need three service accounts: one administrator account used for setting up TFS, and two non-administrator accounts for running the TFS and reporting services. But, I did not have three service accounts, and creating them on the corporate network would have taken a few days. So, I tried to use the one service account that I did have. Unfortunately, setup prevented me from using this account multiple times. To complete the installation, I used my account and the account of one of my coworkers until we could request real service accounts. (No big deal, since these are not production servers.)

Again, nothing earth-shattering to write home about. In all, I spent about a day on the installation (not counting the time to pave the servers). But, considering the number of moving parts involved, and my lack of experience with many of them, that was pretty darn good.

Merrily, merrily, merrily, merrily…

I am happy to report that these same two servers have been running now since early October. We’ve moved forward successfully with work item and source code migration. And, I am starting to play with the new build server. I plan to install it tomorrow. I’ll post more installation notes once I’m done.

Piloting TFS Beta 3

aridle — Tue, 18 Oct 2005 02:47:00 GMT

A few weeks ago, Microsoft released the third beta of Team Foundation Server (TFS). If you are not familiar with it, TFS is an integrated suite of enterprise software development tools, including source code management, work item tracking, build automation, and detailed project reporting. At its core, TFS is a SQL Server 2005 repository with an application server component and new client software that integrates with Visual Studio 2005.

Having spent my fair share of time fighting VSS and a dozen or more bug tracking systems, I was very excited to see TFS when I first heard about it. So, when the TFS team asked for us to dogfood the product as they work to finalize it, I was thrilled to help.

But, like you, patterns & practices has a significant investment in its existing tools and practices. And, like you, we have many active projects, all with their own deadlines. So, in order to balance our need to meet our commitments with our desire to see what TFS can do to improve our processes, we chose to pilot TFS in our lab against a few of our key development scenarios before implementing it broadly. This gives us the opportunity to provide feedback to the product group while insulating our project teams from major infrastructure changes so close to the Whidbey launch.

Over the next several weeks, I will be running the pilot project. We have already built the servers (twice) and ported our work items to TFS from an internal Microsoft tool. At the moment, I'm working on migrating our source code to TFS from another internal Microsoft tool. Obviously, the converters I'm using are not a part of the shipping product. But, they were written by the same team that is writing the VSS converter among others. Check out Akash Maheshwari’s blog for more information about that.

For the time being, I just wanted to let you know what I’ve been up to for the last few weeks. Over the next month or so, expect some posts around my experiences with TFS in these areas:

Installation
Work item migration
Source code migration
Build management
Continuous integration
Iteration planning
Reporting

And, please feel free to tell me what’s important to you! I’m happy to run down any TFS related questions.