Where Technology Meets Teamwork

Slipstreaming TFS2008 on Windows Server 2008

Steven Borg — Mon, 22 Jun 2009 20:06:23 +0000

If you’re installing TFS2008 using SQL Server 2008, you MUST slipstream your installation. However, if you’re installing on Windows Server 2008, and using SQL Server 2005, you do NOT need to slipstream.

However…

If you’re installing WSS 3.0 on the server during the installation process (such as for a clean install), then you really ought to to create a slipstream version of the TFS install with TFS SP1. Reason? Without the slipstream, you have to install WSS 3.0 with Sp2 on your own, and configure it. And it takes less time to create the slipstream than to install WSS 3.0 with Sp2.

So, create a slipstream and install it! You can find slipstreaming instructions all over the web, but here’s a good one from my friend (and TFS super-genius) Martin Woodward. You can access it at: creating a TFS 2008 SP1 slipstreamed install.

TechEd 2009: We’re #2 (And #3, and #4)

Steven Borg — Mon, 18 May 2009 05:56:19 +0000

We’re all finally home! Jeff Levinson, Shad Timm, and I spent last week speaking, listening, learning and playing at TechEd 2009 in Los Angeles, CA. Those who’ve been to TechEd, know the fire hose of information unleashed at the attendees coving developer topics from designing Azure cloud based application to Visual Studio Team System, not to mention all the infrastructure talks!

I won’t regale you with stories of the parties or the in-hall discussions, but I do want to highlight three talks, and our role at TechEd.
With all the votes counted, Northwest Cadence did well. In addition to speaking to great audiences, interacting with really smart people and meeting some new clients, our sessions apparently hit the mark and were rated highly by the attendees! Three of our talks deserve special mention:

Branching and Merging for Parallel Development, a talk by Jeff Levinson on the benefits and pitfalls or various branching strategies took 3rd place in the Developer Tools, Languages and Frameworks track.
Practical Regulatory Compliance and Risk Management, my talk on using Team System to help software development teams achieve regulatory compliance (as well as manage risk) took 2nd place in the Developer Practices track.
Metrics That Matter: Using Team System for Process Improvement, my talk on metrics took 4th place in the Developer Practices track.

For anyone interested in hearing or seeing these sessions, shoot me an email or leave a comment! I’d love to share them with you! We’re representing several of these sessions at our TechTalk: VSTS Firestarter event on the Microsoft Campus this Thursday, and we’ll be recording them.

A special thanks to those customers who generously allowed us to use your stories, and especially to those who went so far as to provide us with their data warehouse and cube. You guys rock! Thank you!
I won’t regale you with stories of the parties or the in-hall discussions, but I do want to highlight three talks, and our role at TechEd.
With all the votes counted, Northwest Cadence did well. In addition to speaking to great audiences, interacting with really smart people and meeting some new clients, our sessions apparently hit the mark and were rated highly by the attendees! Three of our talks deserve special mention:
• Branching and Merging for Parallel Development, a talk by Jeff Levinson on the benefits and pitfalls or various branching strategies took 3rd place in the Developer Tools, Languages and Frameworks track.
• Practical Regulatory Compliance and Risk Management, my talk on using Team System to help software development teams achieve regulatory compliance (as well as manage risk) took 2nd place in the Developer Practices track.

• Metrics That Matter: Using Team System for Process Improvement, my talk on metrics took 4th place in the Developer Practices track.

Finally, we spoke at the preconference. (Can I say “finally”, when it preceded all the other talks?) Of the 15 preconferences, our talk titled Improve Your Software Development: Real World Solutions with Team System 2008 ranked 2nd just behind the excellent talk on SharePoint planning and governance.
For anyone interested in hearing or seeing these sessions, shoot me an email at steven.borg@nwcadence.com! I’d love to share them with you! We’re representing several of these sessions at our TechTalk: VSTS Firestarter event on the Microsoft Campus this Thursday, and we’ll be recording them.
A special thanks to those customers who generously allowed us to use your stories, and especially to those who went so far as to provide us with their data warehouse and cube. You guys rock! Thank you!

New Radio TFS Episode on Adopting Team System with Steven Borg

Steven Borg — Wed, 01 Apr 2009 02:39:36 +0000

A few weeks ago during the MVP summit, I had the wonderful experience of hanging out with Martin Woodward of Teamprise and RadioTFS fame. We chatted for an hour on strategies for adopting TFS successfully, recorded the conversation, and it has just been released as this months episode of Radio TFS.

Have a listen: Adopting Team System with Steven Borg

We’re Speaking At Tech Ed!

Jeff Levinson — Mon, 16 Mar 2009 18:56:56 +0000

Both Steven Borg and I will be speaking for a combined total of 4 sessions and 1 pre-con. The pre-con session is PRC05: Improve Your Software Development: Real World Solutions with Team System 2008. We’ll be discussing solutions that our customers have found helpful in improving their software development efficiencies, quality and other measurable units of success. Whether you work with an agile process or a formal process, this session will provide you valuable tips for helping take your development organization to the next level!

Click the image for a link to Tech Ed! And be sure to drop by and visit us at the Team System booth!

Issues with Alerts in TFS

Jeff Levinson — Mon, 02 Mar 2009 19:30:54 +0000

Every once in a while we get customers who note issues with alerts. In some cases alerts are being duplicated, items don’t show up in the alerts editor, by default you can only see alerts for yourself, etc. This makes managing alerts difficult in some cases. There’s an easy way to identify and remove unwanted alerts.

CAUTION – THIS INVOLVES GOING INTO THE TFS DATABASE – DANGER WILL ROBINSON, DANGER

Okay, having given you that warning, here’s what you want to do:

Look in the database server for the TfsIntegration database. Run the following selects:

select * from tbl_subscription

select * from tbl_security_identity_cache

The first table gives you the list of subscriptions. However, the users aren’t displayed in the table, only the SID’s. Look in the second table for the SIDS. You can delete rows out of the tbl_subscription table without harm which will remove the alert.

Do NOT delete the first four alerts (which are not assigned to a user and don’t have a filter).

TAKE A BACKUP FIRST.

It never hurts

Northwest Cadence Attains Gold Certified Partner Status in Microsoft Partner Program

Sue Ferguson — Thu, 12 Feb 2009 23:00:56 +0000

Northwest Cadence Further Distinguishes Itself by Earning a Microsoft Competency in Custom Development Solutions and Learning Solutions

Kirkland, WA, USA - 9 January, 2009

Northwest Cadence, www.nwcadence.com, today announced it has attained Gold Certified Partner status in the Microsoft Partner Program with a competency in Custom Development Solutions and Learning Solutions, recognizing Northwest Cadence’s expertise and impact in the technology marketplace. As a Gold Certified Partner, Northwest Cadence has demonstrated expertise with Microsoft technologies and a proven ability to meet customers’ needs. Microsoft Gold Certified Partners receive a rich set of benefits, including access, training and support, giving them a competitive advantage in the channel.

Northwest Cadence provides consulting, coaching, and training on Visual Studio Team System and Application Lifecycle Management. With careful attention to both the present and the future, Northwest Cadence provides sound solutions that can be implemented, metrics that can be measured, and knowledge-transfer to ensure sustainable success. “This Gold designation helps tell the story of who we are. We are extremely pleased to be recognized as a Microsoft Gold Certified Partner. Although this Microsoft designation is quite an achievement, we are especially proud because it represents who we strive to be, every day” said Lori Borg, President of Northwest Cadence. “At Northwest Cadence, our mission as a team is to listen and be responsive to our customers and attaining this Gold status will enable us to continue to better serve our VSTS community.”

“Customers are looking for partner companies that can bridge the gap between their business demands and technology capabilities,” said Allison Watson, corporate vice president of the Worldwide Partner Group at Microsoft Corp. “They need to trust in a company that can act as an expert adviser for their long-term strategic technology plans. Microsoft Gold Certified Partners, which have certified expertise and direct training and support from Microsoft, can build a positive customer experience with our technologies. Today, Microsoft recognizes Northwest Cadence as a new Gold Certified Partner for demonstrating its expertise in providing customer satisfaction using Microsoft products and technology.”

As one of the requirements for attaining Gold Certified Partner status, Northwest Cadence had to declare a Microsoft Competency. Microsoft Competencies are designed to help differentiate a partner’s capabilities with specific Microsoft technologies to customers looking for a particular type of solution. Each Competency has a unique set of requirements and benefits, formulated to accurately represent the specific skills and services that partners bring to the technology industry. Within select Competencies, there are Specializations that focus on specific solution areas that recognize deeper expertise within that Competency. Serving as a specialized path to earning those Competencies, Specializations give direct access to the tools and resources that support that specific area of focus.

The Custom Development Solutions Competency is designed for technology partners providing custom-built solutions for clients that require value-added capabilities to optimize business opportunities.

“Our developer partners enable us to deliver high-quality solutions and applications to our customers,” said Nick Abbott, group manager in the .NET Developer Product Marketing Group at Microsoft Corp. “As the demand for applications built on the Microsoft platform continues to grow, there are more opportunities for providers of custom-developed applications than ever. The Custom Development Solutions Competency provides partners with a way to showcase their expertise delivering custom-built solutions to customers, to enhance partners’ revenue opportunities and positioning them for growth.”

Microsoft partners with the Learning Solutions Competency specialize in delivering high-quality training and full-service learning solutions to help customers maximize their investment in Microsoft technologies. Earning this competency identifies partner members of Microsoft’s premier commercial training and delivery channel, making it easier for partners to expand their scope of services and market potential. Microsoft Gold Certified Partners with the Learning Solutions Competency deliver a comprehensive range of information technology and developer training services, including skills assessment, technical training, student mentoring, and Microsoft Certified Professional exam preparation.

The Microsoft Partner Program was launched in October 2003 and represents Microsoft’s ongoing commitment to the success of partners worldwide. The program offers a single, integrated partnering framework that recognizes partner expertise, rewards the total impact that partners have in the technology marketplace, and delivers more value to help partners’ businesses be successful.

Northwest Cadence specializes in Visual Studio Team System and Application Lifecycle Management. Deeply committed to the VSTS and ALM space, Northwest Cadence is committed to ensuring its clients have an exclusive advantage based on the company’s product expertise and ability to bring it all together. Northwest Cadence is involved in the current and future Microsoft product development of VSTS and employs a team of consultants and trainers who are designated as Microsoft VSTS MVP’s, VSTS Advisory Council Members, and Certified Trainers. Northwest Cadence is proud to be a part of Microsoft’s respected VSTS Inner Circle program.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

For more information, press only:

Lori Borg, Northwest Cadence, (206) 947-0967, Lori.Borg@nwcadence.com

Compelling TFS Features to Upgrade from 2005 to 2008

Sue Ferguson — Thu, 29 Jan 2009 22:04:13 +0000

The following is an excerpt from “The Tempo”, Northwest Cadence’s monthly newsletter. This article was written by Jeff Levinson.

Compelling TFS Features to Upgrade from 2005 to 2008

The 2008 release of Team System provided several compelling features and upgrades over the 2005 release. Most of these were in the Visual Studio client editions. In fact, many people feel that Team Foundation Server itself did not see substantial improvements. I disagree.

I’d like to take just a few minutes to bullet point a few of the many improvements at the Team Foundation Server tier of the 2008 release. Some of these come from the October Power Tools release, which I consider a “must have” download!

· Team Build

o Multi-threaded builds

o Built in continuous integration and scheduled builds

o Dramatically simplified build creation

o “Toaster” notifications

· Version control improvements

o Windows Shell integration – perform version control operations directly from Windows Explorer!

o Destroy – permanently destroy version controlled files

o Drag and Drop from the Windows Explorer to the Source Control Explorer

o Search for specific files in version control

o Annotate – this shows who authored every line of code in a file, plus the date the line was added or modified and a direct link to the changeset containing the modification

o Merge improvements – big improvements in usability plus some long awaited improvements in baseless merge support (i.e., identical files no longer trigger a “merge”)

o Single click navigation between Version Control Explorer and Windows Explorer

· SharePoint 2007 support, including easily using an enterprise SharePoint portal implementation.

· Alert subscription UI to simplify the creation of advanced email alerts

· Work Item Web Access – a web based interface to TFS work items allowing people without Client Access Licenses (CALs) for TFS to create, track and update work items.

· Team Member view – information about the development team at a glance from within the Team Explorer. Find out who has what checked out, and what team members are working on.

· Instant Messenger integration – rapidly communicate with members of your team

· Team Foundation Server Manager – an improved tool for managing Team Foundation Server

· SQL Server 2008 support – rebuild indexes online, improved Reporting Services and Analysis Services, and a whole slew of relational database improvements

· Plus much, much more, including offline experience improvements, performance and scalability improvements, and Power Shell integration

If you haven’t upgraded to Team Foundation Server 2008, I encourage you to strongly consider it! If the above list doesn’t convince you, remember that you’ll need to upgrade to TFS 2008 to get to TFS 2010, even if only for a few minutes. So do it now, and get the benefits now.

To read more of this newsletter visit:

http://www.enewsbuilder.net/nwcadence/index000331069.cfm

Steve Borg Renewed as VSTS MVP

Sue Ferguson — Fri, 16 Jan 2009 16:21:22 +0000

What does it take to receive Microsoft’s Most Valuable Professional (MVP) recognition?

Steve Borg knows, for now - the 5th year in a row, Steve has been awarded this prestigious award from Microsoft. This award is given annually to outstanding members of Microsoft’s technical community and it is based on contributions made during the previous year. In order to receive this award, the nominee undergoes a rigorous review process. A panel that includes MVP team members and product group teams, evaluates each nominee’s technical expertise, community contributions, and commitment to the MVP code of conduct. This panel considers the quality, quantity, and level of impact of the MVP’s contributions and presents the award based on their findings. Not only has Steve undergone this rigorous review for the past five years, but did you know – he was in the very first group of MVP’s for VSTS announced the day VSTS was released!

Steve is part of this amazing group of individuals who are considered exceptional technical leaders in the community. And indeed, this is an elite group for there are only 3,500 MVP’s worldwide. Northwest Cadence is very fortunate to have Steve as part of our team. Congratulations!

Practical Process Improvement (Part 5)

Jeff Levinson — Sat, 27 Dec 2008 02:20:15 +0000

The first four posts (Part 1, Part 2, Part 3, Part 4) dealt with working through a process for handling bugs and improving that process. But what about preventing bugs to begin with? In this part I’ll talk about some preventative measures to help eliminate bugs at the requirements and development phase.

Let’s start with functional bugs. These are the bugs that really shouldn’t be in applications. Now, I am a realist and I understand that it is impractical to try to eliminate all bugs (you can do it but at what cost?) in most applications. This does not hold true for life-critical applications in which there is no margin for error. However, how do you eliminate all of the functional bugs? Testers are not the way to eliminate bugs. If a bug gets to the testing stage you’ve already introduced waste. You want to ensure that before the software gets to the testers, that there are no bugs.

Note: In Lean theory, there would be no testers (or “inspectors”) because all they would be doing is finding a problem that shouldn’t have been introduced in the first place. But in software development I believe this is impractical in most cases.

Let me pose this question to you (this is more applicable if you are a developer but if you aren’t, put yourself in the developers’ shoes): How does a developer know when they are done writing code?

Seems like a simple question, right? I commonly get five answers when I ask this question:

You’re never done coding a requirement, it’s an ongoing, evolving process with no end in sight.
When my code does what the requirement says it should do.
You’re done when the analyst says you’re done.
You’re done when all of the unit tests pass.
You’re done on the day the code is due.

The fourth answer is usually from groups doing Test Driven Development or heavy unit testing in a true agile process such as Extreme Programming (XP). I’ll address questions about methodology later in this book.

Looking at answers 1, 2, 3 and 5 you can almost feel the depression. Certainly answer number 1 is depressing – essentially you never finish and you can never know when you’re finished. Answer 5 means that the developer feels that maybe they don’t get the time to finish the way they would like to - again, depressing. Answers 2 and 3 are essentially the same (you hope anyway) but there is a major problem. As I’ve noted already, requirements are subjective which means that while you think you’re done you probably aren’t done.

Test Cases before Code

A better answer is: “I’m done when all of the test cases for this requirement pass.” Now this presents some problems. First, most organizations do not create test cases at the same time as they create requirements. Second, those organizations that do create test cases at this stage do not create repeatable test cases (a.k.a. flimsy test cases). Finally, I have not worked with any organizations that require the users to sign off on test cases the same way they have to sign off on requirements. It kind of doesn’t make sense does it? To have customers sign off on documents which are mostly vague but not have the customers sign off on documents that provide definitive proof that a requirement has been met.

So then, the solution to this problem is simple, assign testers to work with analysts and write test cases for requirements before the requirements are handed to developers. Sounds simple, right? This is where a cost justification comes in. You need additional resources earlier in the process which will save costs later in the process. It’s hard to prove a negative to management and get the appropriate resources and funding.

Another issue with this simple solution is that depending on the type of methodology you are using, it may be difficult to break people of old habits. The manners in which requirements are documented make a huge difference in the ease of creating related test cases. For instance, the best format (let me qualify this - in my opinion) for requirements in relationship to test cases are use cases. A sample use case is shown in the table below.

ID:	UC-POS-01
Title:	Enter Merchandise
Created By:	Jeff Levinson
Date Created:	7/19/2007
Last Updated By:
Date Last Updated:
Actors:	Salesperson
Description:	The salesperson enters items into the POS system
Trigger:	Customer wants to check out
Preconditions:	None
Postconditions:	The POS system has a list of items for purchase by the customer and displays the total that the customer owes.
Normal Path:	Salesperson logs onto the system System verifies identity Salesperson elects to ring up a new purchase System displays the new purchase screen Salesperson scans the item barcode System displays the items Title Description Price [Repeat steps 5 and 6 until order is complete] Salesperson completes the order System displays the total cost of all items, including sales tax
Alternative Path:	A1: Invalid logon [Branch at Step 1] System notifies user that the logon attempt failed User retries to log onto the system [After three tries the user is logged out and needs a manager to re-enable their logon] [Resume at Step 2 if logon successful] A2: The item does not have a barcode [Branch at Step 5] Salesperson manually enters the UPC code into the system [Resume at Step 5] A3: The item is not found [Branch at Step 5] Salesperson enters the UPC code System prompts the Salesperson for the following: Actual UPC code of the item Item title Item price Salesperson enters the appropriate information [Resume at Step 7]
Exceptions:	None
Frequency of Use:	Approx. 100 times per day.
Notes:	None

While you can probably find lots of other situations, alternate paths and exception paths, this serves as a good example for entering items you may find at any retail store.

The reason why use cases are the best starting point for test cases is because they already describe the interaction between the user and the system so you know what the user is supposed to be providing and you know what information the system is supposed to be responding with.

If you are using a methodology such as Scrum which advocates user stories there may be some difficulties. Not because there is anything inherently wrong with user stories, but you can’t write code from a user story. User stories are designed to note a high level requirement and describe the users’ use of the functionality to provide perspective and context for the developers. What many forget to do is to provide more detailed requirements (which can be in the form of use cases) which can form the basis of test cases (if you are going to write use cases based off of user stories, then the description would be the user story). In other circumstances there is no formal method for writing requirements documents which means the structure of each document is entirely up to the analyst who writes the requirements.

Let’s look at a sample test case which tests the use case in the table above.

Step #	Action	Expected Result
1	Log onto the system	System displays the main menu screen
2	Select the new sale menu item	System displays the new purchase screen
3	Scan an item barcode	System displays the item information

HOLD EVERYTHING! What’s wrong with this test case (besides that it isn’t complete)? This is the typical test case that I see when I work with customers all of the time. If you are a professional tester reading this you know the answer to this: This test case is not repeatable. Believe it or not, I have had to disabuse people of the notion that this type of test case is a good test case. But let’s see what the problem is here. In step 1 I log on as the user. Well, what user? It assumes that the logon was successful so that means I need to log on with a valid user. What user though? This is a test system and will hopefully not have production values in it. In step 3 I’m supposed to scan a barcode for the test. What barcode? Can I use the paperback book I’m reading at lunch for this purpose or maybe the barcode from the candy bar that I bought for lunch? Again, the system is supposed to display the appropriate information which assumes I’ve picked an item actually in the inventory. This makes for a poor testing and a poor coding experience. Let’s try this test case again.

Step #	Action	Expected Result
1	Log onto the system with username: Jeff and password: P@ssw0rd	System displays the main menu screen
2	Select the New Purchase menu item by pressing “A”	System displays the new purchase screen
3	Scan the book barcode “Gone with the Wind” (ISBN: 1416548890)	System displays: - Gone With The Wind - A southern love story - 11.55
4	Press the Total button	System displays the subtotal as 11.55, Sales Tax as 8.25% and the total as 12.50

Now this is almost a repeatable test case. What’s missing? There really is only one thing missing here (there are a few minor things but I’m sticking with the major issues) – the setup. How does the system know the tax amount is 8.25%? It can be different depending on where the machine is located. Test cases need to included necessary infrastructure setup and in this case the test would have to be run with different sales tax amounts (or no sales tax amount if we want to assume that maybe this is being used for internet sales in some cases).

In order to have a complete battery of tests this test case would have to be repeated with numerous different values. How many different scenarios do you test? What are the likelihood of the different scenarios occurring and what is the cost if they do occur and the software fails. In the above example, one may assume that you could simply ignore the situation in which the item isn’t found in inventory. After all, if the item is on the store shelf it had to have been received and if it was received it was scanned into inventory. Maybe the chance of this occurring is very, very low but what if it does occur? Without being able to manually enter the item you would not be able to sell the item to the customer. So the cost of this mistake is the amount of the item plus some of the stores reputation. This may be too high a price. It is critical to understand the importance of each of the scenarios when making the decision of what to test.

Well, why don’t we just test everything? The short answer is that it isn’t feasible (again, this does not apply to life-critical applications but it does apply to virtually everything else). The cost in time, resources and equipment to test everything has to be balanced against the ROI. I believe it is possible to make error free applications but at what cost? If it costs 10,000 to test every aspect of the alternate paths but those only become a reality once every 5,000 sales for low dollar amounts, does it provide a benefit? The answer is probably not. As with almost everything else, use the 80/20 rule. That is, 80% of the usage of your application is going to involve 20% of the code (we write an enormous amount of code to handle exception paths and alternate situations). Test that 20% of the code 100%. The other 80% of the code can be tested as problems are discovered or as time permits.

Now that you have a series of good test cases which concretely detail what the system must do, a developer can now answer the question, “When do you know you are done coding?” The answer is, “When the functional test cases I was provided pass.” This is the only right answer (but not usually the one the developers can use).

TFS Reporting Help

Shad Timm — Tue, 16 Dec 2008 19:07:42 +0000

What differentiates TFS and VSTS from many other products is the fact that it is an integrated toolset which funnels data into a single data warehouse which allows for the silent gathering of metrics around your software development process. Unfortunately, many organizations using TFS want to use the metrics and reports but push off spending the time to understand or even look at the built in reports. Beyond the issue of time, many organizations run into problems after customizing their process template and work item definitions which usually results in breaking the built in reports. This is a result of the TFS reports being hard coded to expect specific work items states and for specific states to be in a specific order.

Here is a list of useful links for getting started with TFS reporting and how to fix or get around some of the problems with customized work items.

Ben Day has a blog post covering the modifications needed on the Remaining Work report to show an additional state.
Our own Steven Borg has posted a video demonstrating the creation of the Remaining Work report within Excel which provides an easy mechanism for adding additional states.
A great list of links for more videos and reference material was also compiled on the Team WIT Tools blog.

However, a problem still exists as knowing how to technically create reports only removes the knowledge barrier and leaves the more difficult barrier of knowing what metrics are important. The metrics that each organization need to focus on can very greatly but you always need to start somewhere. You also need to set a baseline of your current status before you start any process improvement initiative in order to measure for successful and unsuccessful changes. A great way to start is with an ALM (Application Lifecycle Management) Assessment as it will point out where the main problem areas lie so that you can then focus your gathering of metrics on those areas.

This is really just a starting point for TFS reporting as well as the overall initiative of process improvement within your organization and in the upcoming weeks I will continue to discuss the metrics that are available out of the box with TFS and how to get to them within your reports.