Presenting Visual Studio ALM and Upgrading TFS 2010 to TFS 2012 In Production

i was actually a little surprised by one of my customers this week. i was there to help them finalise their deployment of tfs 2010 (that they were currently using only for source control) and to present the features to them and ended up upgrading them to tfs 2012 as well!

the first thing that they wanted was a management level presentation of the capabilities of tfs and how everything goes together. i have both a 2010 and a 2012 soup-to-nuts presentation so i though i would hybridise. with the visual studio 2012 release candidate being so recently launched and combining that with the knowledge that windows 8 needs to be in stores for christmas and the full production “go-live” licencing provided by microsoft it is a no-brainer to use visual studio 2012 team foundation server now rather than wait for rtm. in fact, if you are currently just using tfs for source control, or are in the process of deploying tfs 2010 now, i would wholeheartedly recommend jumping in with 2012. if you are using more features you will need to do a little more planning, but you should still consider it…

this particular company is a major utility company and i had little hope of convincing them to move directly to 2012, but as i am so convicted that tfs 2012 is the way forward, it would be remiss of me if i did not try. i presented on monday, and i upgraded them to tfs 2012 on wednesday. amazingly they immediately wanted to upgrade… no planning… just do it! not my usual method…. but…

from the products perspective this was a very strait-forward upgrade. from their environment, which i had no knowledge of to start with, it was a little more complicated. they were running sql server 2008 and would have needed to upgrade to 2008 r2 as a minimum, but the db was on a central all in one cluster so that was going to be a big deal.

so the we moved the db’s to a new sql 2012 on the tfs server. with a very long lead time for upgrades (they just moved to 2008) and a longer lead time for servers, this was the most realistic way forward.

we did run into a problem on our first go around on tuesday that the server was not service packed and we had to wait for their server management company to apply it. other than that there was only the normal issues that you get with a tfs environment that has been locked down after the last deployment… you know… no sysadmin on sql, locked down analysis services, remote sharepoint owned by another team…

so what does it take to convince your organisation to move to visual studio 2012 team foundation server?

so i had a full half day to present to their senior management so i talked about:

1. vision – what are you buying into with visual studio alm

   we looked at what tfs gives you out-of-the-box as well as some of the more recent additions. they had a minimum of premium for all of their engineers so they already had a foundation of features to start with.

   
   figure: visual studio alm

   even just his list of things can be a little overwhelming, so i stayed away from the three new russian doll models and concentrated on the breadth of capabilities from a high level. at this point i assess my audience and decide wither i need to bang the agile drum…

2. agile – we can do better

   although the war had been won and it is now accepted as fact that agile is a better way to build software than more traditional approaches there are still some hold outs. i talk about how “agile” is now so widely used that it is now just “agile” and like “waterfall” before it has become so diverse as to be more difficult than ever to pin down.

   
   figure: more folks are doing agile than ever before

   i am sure that in another 50 years we will still hear stories of the loan company sticking its head out of the sand and saying “what do you mean the war is over?”

   
   figure: the chaos manifesto

   you are just more likely to succeed with agile… so lets accept things and move forward on that premise.

3. tractability in team foundation server

   this is key to most companies and is true of both 2010 and 2012. the crux of the argument is that everything in visual studio alm is interconnected and that gives us the ability to trace from every line of code written through the tasks to the pbi (requirement, user story, bug) that elicited tat change.

   
   figure: visual studio 2010 tractability

   better than that we can then relate our requirements to builds, and the icing on the cake is full test case tractability back to the builds. awesome…

   
   figure: visual studio 2012 tractability

   then we can hit the 2012 features and add tractability for customer feedback to pbi’s and for full integrated code reviews of every check-in.

   this one premise in the main killer feature for any company that has auditors…

4. process improvement

   at this point i really need to introduce the reality that tfs is just a tool…and a tool does not solve your problems. it may help, but it can only improve your process as part of a concerted effort to…well… improve you processes.

   
   figure: tfs can be use to improve you process

5. continuous value delivery

   i then finish up with lots of demos on the various areas tfs and visual studio depending on the audience. in this case it was mostly managers and execs so i stayed in storyboarding, work item tracking and feedback.

   
   figure: delivering value is the key

so if you are presenting tfs to your management there is a lot for them to like. so much so, that if done right you should have no trouble convicting them that tfs will provide them with value. you do however need to remember that if your processes suck then tfs will not magically make them all better unless you also change your processes.