Why the new blog? Why the new web site? Why the new name? Let me explain.
Over the past several years, I’ve dedicated my professional life to Visual Studio Team System. I was involved from the very first betas, contributed chapters to one of the first books on VSTS, wrote training content, contributed bugs, reviewed books, worked through the rough spots, and came to know and love Team Foundation Server. I’ve seen its flaws, worked around newly discovered ‘features’, and seen it’s “version 1.0” warts. But I’ve also seen it sing. I’ve seen it help turn a development shop from a disorganized collection of individuals into an effective software development team. I’ve seen it rescue firms from bloated, ready to crash version control systems that took so much maintenance they were seriously impacting work. It’s a great tool. And these past few years I’ve focused on knowing as much about the tool as possible, while teaching others to use it effectively.
But I’ve seen it misused.
I’ve seen it implemented improperly.
I’ve seen it fail.
It doesn’t have to be this way. The technology is there. It’s scalable, performant and well designed. But, like any technology, it can be used in ways that end up depending on the weakest areas of the tool. Or it can be used wisely, exploiting the strengths of the tool, and avoiding the weaknesses. For the past few years, I’ve tried to lead people down the latter path. But I’ve run into problems, and the problems really aren’t centered around the actual technology. TFS is great! However…
Implementation is another matter altogether. It’s so easy to install TFS (relatively), but so difficult to get the actual implementation right. And it takes more than just the technical knowledge. Knowing how to create work items, use the version control system, branch and merge code, and even extending the core functionality of Team System isn’t enough. The human factor is the overwhelming factor in TFS implementation failures. And the vast majority of those failures are not at the developer level, but one and two levels higher. Team System doesn’t just impact the dev teams. That’s the point! Yet, far too many organizations treat their TFS implementation project as either 1) a technical detail, or 2) restricted only to the development team.
So, new beginnings. I’ve tried to simply teach the technology, hoping for people to grasp the implementation details, either on their own or through a series of PowerPoint slides. It doesn’t work the way it should. To truly gain the benefits of team collaboration takes more than a spare server, more than the developers, and more than some teams are willing to plan for. In the past few years, I’ve focused on training people to use the technology and the tools, but haven’t focused on working with teams to effectively leverage those tools.
New beginnings. It’s time to focus on the overall implementation of an Application Management Lifecycle, and how TFS fits into the overall picture. It’s time to focus not just on the development teams, but on the management teams as well. It’s time to focus on creating the right ALM strategy for a particular organization, tailored specifically to their needs or organizational constraints. And it’s time to bring overall software development best practices to the entire organization, not just Team System best practices to the development team.
So, a toast to new beginnings!