Fast forward a couple of years. With a few exceptions, Visual SourceSafe has been replaced with TFS Version Control in those run-of-the-mill enterprise corporations. This was quite an improvement but also a lot of the friction remained, at least in my humble opinion. Just as with Visual SourceSafe, TFS is being forced upon entire flocks of developers, mostly by management and/or non-coding architects. I still find this to be quite odd as managers never tend to use TFS themselves as this is generally considered a developer tool.

Anyway, this is usually the part where one starts writing down a five page rant against TFS. But I’m not going to. Why? Because I decided to  look for a good solution instead and holy sweet batman, I found one. A while back I decided to learn more about Git. It’s definitely not a silver bullet either but I was so impressed with all its capabilities that I moved all the code for my home projects from Subversion to Git. But the largest friction remained. I was still forced to use TFS day in and day out. But a couple of weeks ago I ran into this post from Richard Banks where he discussed a plugin for Git named git-tfs. This extension is basically a two-way bridge between TFS and Git that lets you treat TFS source control as a remote repository. The way Git works is that the entire repository is contained in a local .git folder. This way it’s able to play nicely with a TFS repository as they don’t collide.      

Setting up git-tfs is quite easy. Just download the latest version, put it in a directory and add the location to the PATH environment variable. Now you’re good to go.

To get the source from a TFS repository you have to execute the ‘git tfs clone’ command.

git tfs clone http://some_tfs_server:8080 $/some_team_project/trunk

Note that by using this command, it will fetch the entire history by retrieving all change sets. If you’re anxious to get started (as I first was ), then there’s also the ‘git tfs quick-clone’ command that will skip the history and just get the latest version.  

git tfs quick-clone http://some_tfs_server:8080 $/some_team_project/trunk

All source files that are fetched from a TFS repository are also no longer read-only, which is quite nice compared to how TFS source control does things. Now that you have all the source files, you can start by adding a .gitignore file and follow the development workflow that you would normally use with Git.

Suppose that you completed a new feature and you want to push those changes back into TFS. This can be done using the ‘git tfs shelve’ command.

git tfs shelve user_story_x

This will create a shelve set that contains the changes which you can then unshelve and check in as you would normally do with TFS source control. The latest release of git-tfs even lets you check in your source files directly without needing to shelve. This can be achieved by using the ‘git tfs ct’ command. Note that this only works for TFS 2010.  

Suppose that another developer on your team checked in some code in TFS that you want to pull into your local working copy. For this you can use the ‘git tfs pull’ command that first fetches the latest change sets and merges them with your version of the code.    

One thing that you also need to take into account are the TFS source control bindings. These are stored directly in the solution file (horrible, just horrible). When opening the solution in Visual Studio, I just choose to work offline and reestablish the bindings when I’m back in TFS.

If you’re forced to use TFS source control and you’re fed up with it, then I strongly advice you to learn more about Git, install git-tfs and be merry. Kudos to all the contributors of this wonderful open-source project. You guys are truly amazing!  

I hope this helps.

That said, there is still room for improvement and both the team and I understand there are still opportunities to improve. In all seriousness, the team at Microsoft wants to make TFS an approachable, no-brainer install decision for .NET teams, even small ones. This means they want to be able to compete for your attention with the likes of SVN, Git, Jira, Perforce, and anyone else making collaboration tools for developers.

The point of this post is for you to help me know what feedback I can give the TFS product development team as they look ahead to the next release of TFS. I am looking for legitimate feedback I can give the team on how to improve the TFS product.

Please bear in mind that I am interested in your feedback on TFS 2010, as TFS 2008 was improved upon 10 fold in the latest release. Also, I am not necessarily looking for feedback on Visual Studio, just the TFS side of the house. Please realize that the team who makes this product at Microsoft is just as committed and passionate about making great software as you are. They just really need your feedback to make the thing you want. In fact, they want to make a tool that every developer loves to use. Really. So what needs to change to make that the case?

Recall that TFS functionality is broken into the following major areas and I am looking for feedback on the 2010 version.

• Version Control
• Work Item management
• Team Foundation Build
• SharePoint integration (optional)
• Reporting and SSRS Integration (optional)

Thanks for anything you have. Thank you also for being respectful and not making this a bash-fest.

Disclosure

• I am a Professional Scrum Developer Trainer. That is: I have been certified by Microsoft and Scrum.org to teach others about Scrum and modern engineering practices on the Microsoft platform. More information about all of that is available here and here.
• I teach for a living. Mostly Visual Studio ALM along with topics I believe are focused on making better software craftspeople.
• I have watched teams get it wrong (and sometimes right) for about 20 years now. That admission makes me feel very old.

A Bit More Background

Choosing to enter the Microsoft and Scrum.org program and be part of the certification process for developers was not an easy one for me. Indeed, as several people I irritated with my waffling for over 6 months will attest, it was a decision I spent a long time considering. In the end, I obviously elected to become an instructor for certification courseware and this in this post I will tell you why.

On Scrum

I first practiced Scrum in or around 2003/4, if memory serves. I didn’t see it done well for several years after that.

On paper, everything sounded just spiffy when I studied Scrum and considered bringing it to my team and organization. Who wouldn’t want the benefits it promises of frequent feedback, clear accountability, and no-nonsense shipping of product? To get started we hired Jeff Sutherland to come in and teach the original Certified Scrum Master course offered through the Scrum Alliance. I was baffled that at the end of the 2 day discussion to receive this thing called a “certification”. My colleagues and I actually joked about it at the time as being proof that we didn’t fall asleep in class. As Ken Schwaber pointed out to me in an interview recently, we probably could have nodded off and been fine, actually.

My team struggled a great deal trying to use Scrum well. I won’t bother including the long list of mistakes we made, but we eventually got traction and settled into a cohesive rhythm. After we figured things out, Scrum became an amazing vehicle for delivering product, which was the original intent.

To my knowledge, Scrum is still used today in that organization. At the time of my departure was in fairly healthy shape.

Looking back on Scrum’s contribution to my professional life and its contribution to our industry as a whole, I am humbled. Scrum as an idea has done more to drive agile software development than perhaps any idea other than the original manifesto itself. TDD ranks right up there, but fewer CEOs have heard of TDD. There are a lot of reasons Scrum has won the marketing war, but the simple fact is that our profession is a better place for the presence of the Scrum framework and the people who provided stewardship to it, Ken Schwaber and Jeff Sutherland.

I know good and well that other techniques are very effective. Kanban is a wonderful way for many teams to operate. Feature Driven Development is a powerful model for the teams who need to formality of it. And of course, the gaping hole left by the absence Extreme Programming reminds us that zealotry has its costs. Scrum, as it advertises, is not a silver bullet. It won’t fix anything, in fact. Only people of good intent who come together and try to do something well can make that happen. Scrum can merely provide the rules of engagement.

Scrum is popular for several reasons. When it comes to the mechanics of the framework:

1. It is easy to understand.
2. It is easy implement and follow the basics.
3. It can show dramatic return in a short period of time.
4. The first Scrum in an organization is a highly visible Kaizen Blitz.

With all of those benefits, Scrum is plagued by the same problems as every other process or methodology framework in the world.

1. Human beings are the ones who try an implement it.
2. Human beings are the ones who try an implement it.

Scrum is great when wielded for good. It is the lowest barrier-to-entry agile technique I know (excluding engineering practices, like TDD and CI). Teams who currently live in plan-driven organizations derive great benefit from Scrum and so do the organizations themselves. Scrum can be very, very effective.

I chose to work with Scrum.org specifically because I know from experience there are more shops out there that need to change than those who don’t. I believe most of those shops cannot handle something like Kanban. [See this for more] My professional life as a trainer is focused on helping developers love our craft again. Those of us who got a thrill from lighting up a pixel many years ago have just been beaten to hell and back since deciding to do this for money. Although Scrum is only one arrow in the quiver, Scrum as a great vehicle for improving people’s professional lives.

On Certification

Ken has readily admitted that using C-word in the beginning of the Scrum Alliance has resulted in a complete and total mess. Primarily because certification involves a demonstration of something, typically knowledge. Unfortunately that requirement was never required to obtain a Certified Scrum Master “credential”. We can all recognize this is not a credential in it’s current form as offered by the Scrum Alliance, but merely a roster of class attendees. ‘Nuff said.

I also see there is value in demonstrating knowledge through a genuine certification process. For example, we all take driver’s tests. I look for ASE (Automobile Service Excellence) certified mechanics to work on my car. I trust a BMW certified technician to work on my motorcycle. What is a university diploma if not a certification award?

In almost any field, it is impossible to certify competence. Certification can demonstrate knowledge, but not ability, talent, experience, or wisdom. It is exactly for this reason that I never got hung up on a college degree as a hiring manager but went to great lengths to try and know a person. A college degree did show me what that person experienced, though, because I basically know what it means to get a university degree. There is value in that credential because it had to be earned.

Given the current state of the industry, there are 3 logical progression paths for Scrum certification.

1. Change nothing and remain a mockery.
2. Drop the certification word and idea altogether.
3. Add meat to C-word by actually testing for it.

Scrum.org is taking the 3rd option and I am going for that ride. My reasons include:

1. Working for change within a system is typically far more effective than pushing from the outside.
2. Scrum as an idea continues to help teams and individuals improve.
3. I respect the people involved in the stewardship of Scrum.org.
4. “Certification” means a demonstration of knowledge by a taking a test in this crowd. Not perfect, but a good start.
5. I believe the teams and other trainers I work with have the best interest of the craft at heart. Really.

On The Future of the Craft

In the last 60 years of programming computers, we have have learned that developing in small batches and delivering incrementally works. Scrum gives us a model for doing exactly that, and it will still be helping teams until the next great thing is found. Now that I know Ken a bit better I can say that Scrum itself will likely evolve to incorporate whatever works better.

Ridiculing certification or Scrum may well be the in-crowd thing de jour, but I see that Scrum addresses a core need in our industry, and genuine certification has its own benefits. Lean offers some wonderful directions for us, and shows all the signs of providing a path forward. But, let’s not forget that Scrum is an inherently Lean idea.

But I digress.

Another time, perhaps.

Visual Studio 2010 Beta 2 is available on MSDN this morning. It will be more widely available soon. With a new look and feel it is off an running. After working with it for awhile, I can honestly report that it is a pleasurable product to use. Much attention has been paid to aesthetic, and the customization story for products like ReSharper and Code Rush is even richer. This means that companies have a great platform upon which to make our favorite development environment dance.

One change we see as part of the Beta 2 drop is the exclusion of the term “Team System”.

That’s right! Team System is no longer going to be used as a product name going forward, even though all the favorite tools are still in the box. So, what’s going on here?

We’ve been struggling with the following product lineup for several years now:

• Visual Studio Professional 2008 with MSDN Premium
• Visual Studio Team System 2008 Development Edition with MSDN Premium
• Visual Studio Team System 2008 Architecture Edition with MSDN Premium
• Visual Studio Team System 2008 Test Edition with MSDN Premium
• Visual Studio Team System 2008 Database Edition with MSDN Premium

There’s a mouth full, eh? Not so funnily enough, the more frequent questions I get from customers investigating Team System has been around licensing. Frankly, it is confusing. MSFT heard this loud and clear and has taken steps to rectify the situation with this release. Instead of continuing with the Team System brand, we’ll now be talking about fewer and simpler options for purchasing Microsoft tools.

• Visual Studio 2010 Professional
• Visual Studio 2010 Premium
• Visual Studio 2010 Ultimate

OK, so fewer choices must be simpler, so what do I buy now? Well, this page shows the various tools available in the different versions. The truth is that there is still a decision process around what tools you want to pay for. Let’s take a look at just the testing tools available in Visual Studio.

If I want Code Coverage, I buy Premium. If I want Load Testing, I buy Ultimate.

Hopefully this packaging will actually be easier to understand and digest.

Here’s a link to the screen cast.

Here’s a pointer to the article.

In this episode, Tommy visited with me about effectively applying Team System to some agile software development practices. This ranges from Continuous Integration to the tool aisle at your neighborhood Sears store, but I’ll leave that for you to discover.

• Tommy’s Blog
• Scrum for Team System
• Manifesto for Software Craftsmanship
• Visual Studio Team System

Get the show here

Here are my ad-hoc notes from Sam’s talk.

• Organizational structure is a better predictor of defect density than any other measure.

  Here are ad-hoc notes from Sam’s talk.

• Get clean, stay clean

  • Understand your technical debt
  • Put limits on acceptable technical debt
  • Clean your house
  • Keep your house clean by putting limits on defects with a stop-the-line mentality.
• Scenario > Value Proposition > Experience > Feature
• Scenario – Our business would like to
• Value Proposition – How can I accomplish …
• Experience – Here’s how you …
• Feature – As a… I want… so that…
• When prioritizing features to add to products, clients vote VERY differently than MVPs. This was illustrated in an amazing slide showing how customers vs. MVPs voted for new features.
• Red bits – development on product already in the field. Must be stringently controlled and reviewed to ensure backward compatibility
• Green bits – development on features not yet released, so fewer constraints, but always reviewed to guard against rick after the feature turns into red bits.
• Sizing for features had to take quality gates into account
  • Code complete is a dead term. You must now be feature complete.
  • This includes things like threat analysis
• It takes several weeks to run all the automated tests that execute against Visual Studio Team System.
• OGF – Overall Gut Feel – A subjective measure based on expected customer experience.
• BVT – Build Verification Tests. Tests that verify a check in – typically unit tests.
• VS2008 vs. VS2008 SP1 – SP1 saw an improvement in quality of 10X
• While it is important to celebrate success, never declare victory.
• Do not undersell the investment to start a project well, and the cost of being truly done.

Duh.

I have worked with Team System quite a bit and with alternatives just as much. With a lot of experience behind me on this, I feel confident I can make a legitimate case for using Team System in a small team.

I consider a small team a development organization of fewer than 10 people.

Some Context and Disclosure

• I am a Team System MVP
• I use Team System on a daily basis
• I use SVN+Team City on a daily basis
• I care more about pragmatism and craftsmanship than tooling, and that means focusing on how to use tools, not just the tools themselves
• I have been present on day one of a brand new team
• I have been in a team that has grown quickly over a short time

Focus on the Work

What happens when teams squabble about tools instead of just getting on with it? Lots of churn and wasted energy, is my experience.

I can report having seen small teams succeed and fail. The success or failure in both cases obviously has a lot more to do with leadership and business than developer tools, but I can also say the way companies approach developer tooling can have a lot to do with culture.

Any startup or small team simply must be focused to succeed. This can also be extremely difficult to achieve. A small team simply doesn’t have the capacity or depth to be distracted with issues not pertaining to delivering product. Paradoxically, team members are often wearing several hats. That is, everyone is doing a little of everything. That can quickly trend to entropy, because no one ends focusing on the work at hand.

The last thing I want to do on day 1 of a new team, or very often in a small teams, is visit tooling. Not deliberately making choices about tooling, though, will eventually bite you. Hard. How many of us are in organizations with over 2 brands of source control systems because new ones were added in an ad-hoc manor? I’ve been there. How many unit test frameworks are being used? I have been on a team that used 4 at once. Think that caused some problems?

As team lead, I care far less about optimizations of specific tools, and far more about a cohesive and fluid process enabling flow within the team. I care a great deal that there is a single source of truth for requirements and very little that we are using the coolest new unit test framework.

Often, focusing on work simply means implementing a system of tools and getting past the discussion. Have you ever heard developers purse fight over text editors? Now, there’s a constructive use of energy. The same thing can happen when geeks whip out their favorite source control, merge tools, unit testing frameworks, Visual Studio add-ins, logging library, laptop brand, or bug tracking system.

Point number one is let’s get past the time suck of the my-NAnt-is-better-than-your-MS-Build and just prescribe a toolset so we can get on with the real business of our team.

Team System is Like a Box of Tools at Sears

When I go to Sears and browse the Craftsman (or DeWalt) tools, I usually see some interesting little specialty tools. I might buy a funky swivel socket or a single ratchet, but I rarely browse the aisle with the large all-in-one kits. The reason I don’t browse the kit aisle is because my father-in-law bought be a basic Craftsman starter kit almost 20 years ago and my collection of tools has grown over time.

I don’t still have all of the tools in that original kit, but I do still have many of them. Further, my need for hand tools have gotten more specialized over time. Also, I am making a bit more money than I was when I married my wife, so I may spend extra for a special-purpose hammer rather than always relying on the one that came in the original kit.

Without that original kit, though, I would never have been able to even get started. No, it didn’t have every tool I would ever need, but it had almost everything I needed right then.

Team System is much the same. A team can absolutely hit the ground running with the rich toolset VSTS provides. Maybe you’ll augment the toolbox over time. Maybe you’ll even change tools (can anyone say [TestClass]?) but the kit that comes in the box really can provide most of what a small team needs to get going, and do it in a single solution.

That’s huge.

As soon as I start looking around to sub-optimize my hammer or my source control, I am going to start slowing the team down. GIT? SVN? PerForce? There are a ton of options for source control, each with their strengths and weaknesses. It’s freaking source control. Get on with it. I mean, how sexy can a hammer be?

It May Not Cost What You Think

You can buy a big toolkit at Sears for far less than it costs to buy all the tools individually. Further, buying the toolkit for the person without tools is a good move because they will have all the basics covered in a single purchase.

Craftsman Toolkits are a favorite gift of mine for graduates and newlyweds for this very reason.

Microsoft has the same insight that Sears had. If a person gets accustomed to Craftsman by selling the kit cheaply, they’ll be a customer for life. This is the exact idea behind the BizSpark program. If you aren’t familiar with it, BizSpark is a Microsoft program that allows free (that’s right, free!) access to all developer tools, operating systems, and other software for startups.

Is your company less than 2 years old? Do you make software? If yes, you qualify, I kid you not.

Integration Matters

Even if you are paying full price (which you shouldn’t ) I believe the value of VSTS is still there. The productivity loss involved in setting up a system of disparate and non-integrated developer tools is tremendous. I have been there and done that.

I know SVN is good. I know Team City is good. I also know that setting up a basic Continuous Integration build in Team System is stupid simple. And the real money shot comes with Work Item management. How many teams out there are using work item management systems or defect tracking systems they hate?

Well, we all are.

So, we may as well have one that works right in the IDE and allows me to tie check ins to work I am performing. The context switching that occurs in non-integrated systems of reporting, SCC, build, and work item management is HUGE. Huge! No really.

Get On With It

The people involved in the recent online Team System kerfuffle are folks I would consider in the top 1% of developer talent. Quite frankly, it makes a lot of sense to me that people at that level will have replaced their hammer from the kit with one that has an ergonomic grip.

That said, there are a lot of startups and small teams in entropy out there. For those folks, I firmly believe that standardizing on an integrated toolset for the development team is a bigger savings than “free like a puppy” solutions that can work well, but with more churn.

Now quit fussing about source control and learn how to use a decent ORM, people.

Pluralsight On-Demand! now has the opening modules of our online course, Visual Studio Team System Fundamentals. This course focuses on Team System 2008. I am continuing to build out the content and hope to be releasing new modules at the rate of 1 a week or so.

In addition, watch Pluralsight’s Screen Cast pages for smaller, focused tidbits. I will be covering “The Top 10 Team System Tidbits” in the free screen casts over the next few months. Any suggestions for what you’d like to see in the top 10?