Version Now
I have been guiding companies who are looking to get Team Foundation Server up and running within their organizations to support their Application Lifecycle Management (ALM) process since the pre-release (Release Candidate Go-Live) versions of version 1 when it went by a slightly different name – Visual Studio Team System. There have been some 20 or so different releases of the on-premise product since then and many, many more releases to the Online features since it first came back online back in August of 2012 (See Release Archive).
The first thing to understand about the above timeline is that it became super clear to those of us who are deep on these tools that the “feature list” anywhere along the spectrum did not tell the whole story. The feature list in no-way meant you were in purgatory until the next major release. First of all, we learned early on that “Service Packs” (e.g. SP1) was definitely “not our grandmother’s” understanding of the term. In the VS/TFS-world, the service packs were less like a doctor visit that addressed maladies from the RTM (Release to Manufacturing) release,
and more like Christmas in that there were a bunch of shiny new features under the TFS tree that were fixing usability frustrations or giving us wonderful automation abilities that we had accepted as necessary tedium of an otherwise wonderful job. That coupled with an impressive extensibility story, made even the SP/CU quarterly release cycle nothing to fret if your favorite feature was further down the backlog than your situation would have put it. If there was a feature, we didn’t like, there were growing numbers of us that would just write a workaround and share them as an extension, or Microsoft or their Ranger teams would publish power tools that provided the feature “out-of-band” as they say. There have always been plenty of options to hold team’s over until the next official release – which has gotten progressively shorter.
On the other hand, the concept of a “major” release with this tool has not been our grandfather’s notion of a bright-shiny-new application. Because of this redefinition of terms, service packs got renamed to “updates”, but major releases had not such renaming clarification.
In the new world, a “major” TFS release became increasingly less like Christmas because many items in the “new features” list were already previously incorporated in “service packs” and power tools, 
and more like “Tax Day” (for the self-employed who does not suffer the withholdings of Software Assurance earlier). It was time to pay up Microsoft for the prosperity you have enjoyed. In the “Ultimate” days of the Visual Studio SKU, taxes went up considerably, but today, they have trended down significantly in the VS-TFS space for both Visual Studio and TFS CALs — in a number of cases to nothing— so at this rate — Tax rebates are right around the corner!
Of course the metaphor is tongue and cheek and the truth lies somewhere in between for both updates and new releases. My primary point is that the hackneyed old adage of “Not until Service Pack One” which self-deemed “sages” of IT infrastructure too often live by – is just not applicable or helpful with this product at least. If I am a thought leader in my company and have serious influence in these areas, and I regularly trot out this adage, I most likely need to reassess this filter when it comes to Visual Studio and TFS. Am I saying this as a dodge because I, as an “X” method/tool expert am uncomfortable with method/tool Y – and even though Y is proving itself to be better at tackling/accomplishing Z, I don’t want to feel like a novice again. I also may need to make an effort to at least grasp the cost-benefit of suffering through work-around B at the price of getting awesomeness AA. Sometimes delay philosophies serve a company well, but more often than not these days (depending upon the business of course) this approach can really get you and a whole organization you influence behind the curve.
By the way, the “curve” metaphor only makes sense to me when I think of the “bell curve” (because of the hill we are left climbing while others are enjoying the ride down – or our highest goals fall between grades F and C rather than C to A).
I think our baseball gurus talk about working a “delaying mechanism” into your swing or your decision window to adjust to a curve ball – so being “behind” in that case is not a bad thing! Anyway, it’s one of those metaphors that’s been around long enough that you stop picturing the metaphor and just hearing the meaning – “behind the curve” = “bad” = “has-been” = “shame” = “so-80’s” = “dinosaur”. Hey, wait-a-minute, the 80’s made a comeback!!??
Anyway, in today’s world where heroes become has-beens in months, and mistakes can permanently damage a reputation, we need to get really good at sorting through what to get excited about; what to jump on a new band wagon about; and what to stay the course about. My next series of articles around TFS 2015 is an attempt to fill the gap in that space rather than just rant about shiny “new” when it is really just a recycling of the “old” or maybe even misses the mark — and draw appropriate attention to the features that really are important advances.
Here is the rating system I will use :
And in the name of transparency, here are some biases of mine when it comes to this ALM TFS feature-evaluation process. I have lots more, no-doubt, but I will try to be upfront about the ones I know of so you do not feel duped by my rating system and/or you can adjust my rating accordingly to have value in your system. I have grouped my biases that tend to have a mitigating effect on each other — without being contradictory.
- Proven agile techniques and proven engineering principles, planning, and patterns should not be enemies. Neither are going away so let’s respect their wisdom and use them prudently where appropriate.
- Prefer the goal to “technology du-jour”. Shiny new techniques need to prove themselves if they do not make life easier and would put our current productivity at risk to accomplish essentially the same goal. However, if this is “iteration one” of the practice, why not use “technology du-jour” if it best meets our goals?
- Curb your excitement about new features until you try them. Too often the feature’s marketing title means what I want it to mean rather than what it really does.
- Stay ahead of the curve and pay sweat equity as early as possible on trends that are not fads.
- Do not fear change because in this world of technology, we need to hold loosely to our specific technical expertise. Our meta-skills (which must include the ability to change – are way more valuable [in the big picture] than any trendy-technique that has made you a guru – or even the better technique which has lost the mass-adoption opportunity). Be thankful for the adulation and its benefits while it lasted and enjoy the new ride.
- Today’s productivity is paramount rather than waiting for the next release. Adopt vNext as soon as it comes, but let’s not paralyze today’s productivity because tomorrow’s tools are right around the corner.
- Prefer standards where differences are arbitrary. Whether I call a two-week development cycle a Sprint, an Iteration, or a Jog is barely worth talking about and certainly not worth the price of customization— and staying with the most popular makes your team much easier for outside experts and new-hires coming in. On the other hand, tracking actual work and remaining work are real choices to make – with real consequences of course.
- Do not fear customization because the productivity today far outweighs me having to work through a few potential gotchas with upgrades in the future. (It is the power of extensibility that has me currently favoring On-premise TFS for shops who are not infrastructure poor.) While I will argue strongly that organizations should customize for good reasons, and yet I look suspiciously at whether customization requests move us closer to the proven standard or further away. If there is a productivity need, is there an almost equal way to accomplish.
- A tool’s ability to collaborate with our other tools is a huge feature to be taken into account. If a non-integrating (or painfully integrating) ALM tool is chosen because it has better features, make sure you properly weigh this against the weighty feature that an integrating tools give you. Duplicate entry overhead is a major day-to-day price to pay on team morale and productivity, but at times the latter may still win with an acceptable integration compromise.
Stay tuned for my next article which will cover bugs on the backlog, task board, or both.
