I’m writing from a perspective I’m very familiar with – Sales. I reference the concept of a Sales Lifecycle Management (SLM) strategy as a parallel to help explain the value of ALM. As you read on, I’d invite you to use “[you fill in the blank] Lifecycle Management” to help bring relevance to you.

Why should a non-technical executive care about ALM in their organization?

We spend a lot of time and energy investing in our sales organizations to make sure they are performing. I’d encourage you to spend a little time and energy on investing in your ALM strategy for equally impactful results. There’s more in common with your development teams and your sales team that you’d think…

Skeptical? Read on!

ALM Defined

Let’s define ALM so we can get to the meat of this post. Application Lifecycle Management is exactly what it sounds like: the management of an application’s lifecycle. ALM is the end-to-end process a development team or organization has decided to follow when building software.

Why do you care?

Before starting Northwest Cadence, I ran the Sales organization for a technical training organization. For those who have worked with sales people, you know that some of the best tend to be maverick-cowboy-types with strong wills, colorful personalities, and a certain level of do-it-my-way when it comes to reporting, forecasting, and following company processes. Sound like any software developers you know?

Like any Sales Director, it was in my best interest to help support the great sales progress of my rock stars, figure out how to replicate their success, and gain an accurate read on their sales projections…all while making sure I didn’t stifle their motivation or empowerment.

A few of the common problems that occur if a well-defined process and strong team environment aren’t in place:

• Stuff is being sold that you can’t deliver

• The wrong stuff is being sold

• You don’t know what’s being sold

• Nothing is being sold

So, in effort to feed the eagles and support the teams’ growth, I did what many of you might do. I conducted a thorough evaluation of our organizational Sales Lifecycle Management(SLM) to determine what was broken, where we excelled, and what metrics were important for me to have a pulse on so I could effectively forecast various things. Once the evaluation was completed, we moved forward with a comprehensive, end-to-end SLM strategy that included the following components:

• Step 1: Define the Process. First things first. We needed to define what would become our new sales process. I collected feedback, used my best judgment, and asked some experts for guidance. Once the new process was baked, it was time to move to Step 2.

• Step 2: Get buy-in from the team: This was the most important piece. It was also the most difficult. By helping the team see what’s in it for them – how this process will help make their lives better and produce them more results – we can more easily get buy-in. If you haven’t already, do your homework. Find out what makes your team tick and where their pains are so you can bring relevance to their lives on the positive impact these changes will make.

• Step 3: Train the team. We trained the entire sales and marketing teams on our new sales process. This was important to level-set our organizational sales style. A forecasted 60% in the sales pipeline is no longer a subjective percentage, and there’s now a common distinction between a sales lead and an opportunity. You get the idea. After team training, the team started speaking the same language so the members could be in lock-step, learn from one another, and work collaboratively. All important keys to team success.

• Step 4: Choose tools wisely. It’s important to identify tools that integrate with your process and accelerate your newfound efforts. We determine how to best leverage the tools we owned and decided on what tools we should buy. Employ your tools! Get them working for you; don’t find yourself in a position where you’re bending over backwards to work for your tools.

• Step 5: Measure results, make small changes of improvement, proceed iteratively…

Results?

By creating a well-defined process and improving the team environment, we realized results better than we imagined. The team was happy, collaborative, supportive, and surpassing their sales targets! The collective knowledge base and skill set was increasing at a greater pace, and the revolving door of sales people stopped.

Simply put…

Great process means happy people. Happy people means more productivity. Couple happy productivity with great process to get bottom line results that will make you proud and happy that you showed an interest!

Get Involved!

In your position of leadership, I suspect you are quite familiar with the impact strong sales revenues, wide margins, and a happy sales team has on the overall success of your organization. You can see equally strong impact on your business by spending some time focusing on your software development teams and your ALM strategy. An organization’s ALM strategy is cultural and systemic. It spans your organization and reaches your bottom line. You need to be involved in the ALM discussions, even if it’s just to ask some hard questions and understand what’s going on. You will be surprised what you learn, and excited about the possibilities you uncover!

The easiest way to start is by downloading an existing process template from
a TFS 11 server. This will provide you with the files you need and make it so
you can easily copy and paste the important items into your process template.
The rest of this post assumes that you have done this as I’ll refer to specific
files from an existing process template (the MSF for Agile process template in
this case).

After you’ve done that, it’s time for the simple changes:

• Change the system.description field from PlainText to HTML

When you upgrade, the system.description field is automatically converted to
HTML (finally)! However, if you try to make a change to the template without
changing this field, the next time you run witadmin importwitd it will tell you
that the import fails with the reason that system.description is HTML and cannot
be converted to PlainText. This will just save you some grief.

• Add storyboard tab whatever work items represent your business requirements
  (User Story, Requirement, Change Request, etc)

Add the following XML:

<Tab Label=&amp;quot;Storyboards&amp;quot;>
  <Control Type=&amp;quot;LinksControl&amp;quot; Name=&amp;quot;StoryboardsControl&amp;quot;>
     <LinksControlOptions>
        <WorkItemLinkFilters FilterType=&amp;quot;excludeAll&amp;quot;/>
        <ExternalLinkFilters FilterType=&amp;quot;include&amp;quot;>
          <Filter LinkType=&amp;quot;Storyboard&amp;quot;/>
        </ExternalLinkFilters>
        <LinkColumns>
          <LinkColumn RefName=&amp;quot;System.Title&amp;quot;/>
          <LinkColumn LinkAttribute=&amp;quot;System.Links.Comment&amp;quot;/>
        </LinkColumns>
     </LinksControlOptions>
  </Control>
</Tab>

Action states are what changes the state of tasks as you drag tasks (or other
work items, but tasks in the out of the box templates) in the My Work pane in
the Team Explorer tab of VS (Figure 1).

Figure 1 – My Work pane, Team Explorer

• To add the action settings, use the following:

In the TRANSITION element from Proposed to Active

<ACTIONS>
  <ACTION value=&amp;quot;Microsoft.VSTS.Actions.StartWork&amp;quot; />
</ACTIONS>

In the TRANSITION element from Active to Closed

<ACTIONS>
  <ACTION value=&amp;quot;Microsoft.VSTS.Actions.Checkin&amp;quot; />
</ACTIONS>

In the TRANSITION element from Active to New (or Active to Proposed)

<ACTIONS>
  <ACTION value=&amp;quot;Microsoft.VSTS.Actions.StopWork&amp;quot; />
</ACTIONS>

• Add the Code Review Request, Code Review Response, Feedback Request and
  Feedback Response to the work items xml file

Copy the four files from the downloaded process template to the
TypeDefinitions folder and add the following lines to the workitems.xml file in
the WORKITEMTYPES element:

<WORKITEMTYPE

    fileName="WorkItem Tracking\TypeDefinitions\CodeReviewRequest.xml" />
<WORKITEMTYPE

    fileName="WorkItem Tracking\TypeDefinitions\CodeReviewResponse.xml" />
<WORKITEMTYPE

    fileName="WorkItem Tracking\TypeDefinitions\FeedbackRequest.xml" />
<WORKITEMTYPE

    fileName="WorkItem Tracking\TypeDefinitions\FeedbackResponse.xml" />

• Update the categories.xml file (in the WorkItem Tracking folder)

Add the following boilerplate XML under the cat:Categories element:

<CATEGORY name=&amp;quot;Code Review Request Category&amp;quot;

    refname="Microsoft.CodeReviewRequestCategory">
  <DEFAULTWORKITEMTYPE name=&amp;quot;Code Review Request&amp;quot; />
</CATEGORY>

<CATEGORY name=&amp;quot;Code Review Response Category&amp;quot;

    refname="Microsoft.CodeReviewResponseCategory">
  <DEFAULTWORKITEMTYPE name=&amp;quot;Code Review Response&amp;quot; />
</CATEGORY>

<CATEGORY name=&amp;quot;Feedback Request Category&amp;quot;

    refname="Microsoft.FeedbackRequestCategory">
  <DEFAULTWORKITEMTYPE name=&amp;quot;Feedback Request&amp;quot; />
</CATEGORY>

<CATEGORY name=&amp;quot;Feedback Response Category&amp;quot;

    refname="Microsoft.FeedbackResponseCategory">
  <DEFAULTWORKITEMTYPE name=&amp;quot;Feedback Response&amp;quot; />
</CATEGORY>

<CATEGORY name=&amp;quot;Hidden Types Category&amp;quot;

    refname="Microsoft.HiddenCategory">
  
  <WORKITEMTYPE name="Code Review Response" />
  <WORKITEMTYPE name="Feedback Response" />
  <WORKITEMTYPE name="Feedback Request" />
  <WORKITEMTYPE name="Shared Steps" />

One cool new thing (maybe I’m just a simpleton) is that you can create types
but then hide them when end-users select New Work Item in a menu (such as no
longer showing the Shared Steps work item type).

• Add a new folder in the WorkItem Tracking folder called “Process”

Copy the AgileConfiguration.xml and CommonConfiguration.xml into this folder
(get these files from the downloaded template)

• Update the AgileConfiguration.xml file

There are really only two items you need to look at in this file and they
will be specific to your process template. The first is the columns that show up
on the Product Backlog and Iteration Backlog pages in Team Web Access. The other
item is which fields show up on the Product Backlog “panel” (Figure 2).

Figure 2 – Product Backlog add panel

Edit the AddPanel section to add any fields which are required for any of the
work items which are in the Requirements Category of the categories file. This
may not always be possible but it will make it faster to enter work items –
otherwise when you click Add, the work item form itself will open to allow you
to fill in required fields that do not show up on this panel. You can also add
other fields which are not required but the point is to keep this as uncluttered
as possible!

• Update the CommonConfiguration.xml file

For the most part you won’t need to make too many changes to this file but
there are a couple of things to look out for:

• If you use a field other than StoryPoints or Estimate, change the field here
  (it is the field that is of type “Effort”)
• If you have additional states on your work items, make sure you map them to
  the appropriate meta-state. This is a new concept in TFS 11. So, for example,
  say you are using the MSF for CMMI process template which has the states
  “Proposed”, “Active”, “Resolved”, “Closed”. The meta-states for these are
  Proposed = Proposed, Active = In Progress, Resolved = In Progress, Closed =
  Complete. This allows things like the task board to handle any number of states
  and know when you haven’t started working on something, are working on something
  or have finished something. You set these states per
  category.

That’s about it. I’ll add two more caveats: 1) Version control your process
templates and 2) I have made every effort to ensure there are no typo’s in these
instructions and these instructions apply to the Beta version only and I will
not take responsibility if you added something without thinking it through. The
best way to avoid this situation is to just copy the XML from the downloaded
templates!

Enjoy!

This is just cool. I don’t think I’ve ever had a book translated into Chinese. Nothing more to say here. Just cool!

1. Remote in to the TFS Application Tier (this has to be done on all tiers if you have multiple app tiers)
2. While probably not required, I stop the web site on the application tier to perform this operation
3. Open Windows Explorer and go to C:\Program Files\Microsoft Team Foundation Server Dev11\Application Tier\Web Services\_static\tfs\11\_scripts\TFS
4. Copy the file TFS.Requirements.Feedback.Models.min.js and put the copy someplace safe – you will need it for servicing purposes (more on that in a moment)
5. Edit the original file (the one that is still in the location in Step 2)
6. Press Ctrl+F and find “INSTALL_FEEDBACK_TOOL_URL”
7. Replace the default value that is listed here (“http://go.microsoft.com/fwlink/?LinkId=230568”) with a value of your choice. Note that if this isn’t a website but a file, you still need forward slashes and not back slashes. The value I’m going to use for this example is “file://nas/software/images/dev11beta/vs_feedbackclient.exe” – note the direction of the slashes when you see the resulting e-mail
8. Save the file to some other location (because of administrative permissions you’ll need to copy it back rather than saving over the existing file)
9. Copy the newly saved file back to C:\Program Files\Microsoft Team Foundation Server Dev11\Application Tier\Web Services\_static\tfs\11\_scripts\TFS
10. If you stopped IIS, restart it now

Some final thoughts

Running Unit Tests

Debugging a Failed Unit Test

Code Clones

Analyze for Code Clones

Search for Code Clones

Code Coverage

Run Tests After Build

Conclusion

Visual Studio 2010

Visual Studio 11

Test List Editor

Test Impact Analysis

Conclusion