Getting Real ROI (return on investment) on ALM

As you come into work on a Monday, you find your team is about to start down a path whereby they are going to commit to significant architectural refactoring of the application. You talk to the senior developer and ask “why?” The answer you hear back is unsatisfying as it is obscure. Phrases such as “separations of concerns” and “single responsibility principal” are mentioned faster than you can actually drink your first cup of coffee. Scenarios like this happen every day. How do you validate that this is the right thing to do or not?

We founded Polaris Solutions because we were (and still are very) passionate about making the IT landscape a better place. We help our customers by providing advice, implementation, and knowledge transfer on the principals that help an IT team/organization be successful. As part of that process, we like to listen to our customers and truly understand how they are getting their work done before we set out to help any change. For us, we call that the “Assessment.”

An ALM Assessment is meant to (1) understand the current situation (2) identify any really good practices that can be built upon (3) find out any areas of investment that may result in increased maturity/success for that team(s). As part of the results, which do vary based upon immediate and longer-term needs – a roadmap can be created which consist of modifications to process, tools, and practices/people which should improve things. Most carefully, managers should take those assessments and apply an ROI paradigm to them. Questions like “Which of the following improvements should have a real positive ROI?” or “Which ones have the highest?” come to mind, and they should.

As an example, if it’s recommended that the team should adopt automated build or deployments, how much will this improve my team? As a suggestion, I’d recommend consider what the ROI on automated deployment might actually be. To get there, you can take a high level view on what the ROI should be – and then just like good computer scientists, divide-and-conquer that problem.

  • ROI = (Gain from Investment – Cost of Investment) / Cost of Investment

Implementing automated build and deployment can be estimated and priced. The gain from doing so is more difficult because it represents the removal of the cost of doing it the “old way.”

  • Gain = Cost of Manually Building Today + Cost of Outages from Manual Process
  • Gain = Cost of Single Manual Build * Frequency + Cost of Outages
  • Gain = Hourly Salary * Duration of Single Manual Build * Frequency + Lost Revenue * Probability of Outages

An example of ROI over simplified – for a single year.

  • ROI = (40K – 10K) / 10K = 3.0

If we spend 10K to remove 40K of costs to our company. This is a win. Should we do this first?

Maybe – it depends where this stacks up against other initiatives within the IT organization. Perhaps better requirement analysis or superior unit testing might have significant gains to the organization. One major point here is – it is very hard to feel like this is an exact science because some of the practices mentioned within this article are tough to quantify benefits. When doing an exercise such as this, keep in mind that no matter what – this is an estimate and not actual. So the first challenge is figuring out what your variables are, and then putting in assumptions in for them. I find this is an opportunity for analysis paralysis, but when you don’t know something, start making those assumptions and documenting them.

This exercise, I believe, is an important one. Unfortunately, few think about this in real practical terms. Phrases that truly are poor substitutes for this are that we all hear: “It’s faster” “It’s newer” “It’s more integrated.” They are good positioning statements, but ROI in your organization should start with these, not end with these.

Speaking at the Visual Studio 2013 Launch in Chicago

As you might already know, Microsoft is increasing the cadence at which they will release Visual Studio. And this year, 2013 is coming out. This year, I am really excited to be presenting up in Chicago with Jeff Fattic at the launch event for Visual Studio 2013. I will be talking about how to use Agile in the enterprise and making it scale for you. To register for the launch event, see the MS Events site: This will be on November 20th at the Drury Conference Center out near Oak Brook.

Efficient Testing Tour – Lab Management Slides for STL and KC

I just finished my portion of the Efficient Testing Tour with Microsoft. I want to thank everyone that came out to see us talk over the past two days in St. Louis and Kansas City. Overall, we had a great discussion in both places, and I wanted to make sure I shared my slides in case anyone wants to refer to them in the future. Here they are in Skydrive:

Be Significant

“They keep throwing me under the bus over email.” That’s a quote that I heard the other day from a friend and fellow consultant.

This is often unavoidable, but many times it is not. Although many will tell you that you need to manage the expectations when performing consulting services, you must always manage the relationship. When you’re the faceless robot without a story, it’s way easier to throw you under the bus.

Efficient Testing Tour – Indianapolis

Thanks again to everyone that came out to Carmel to see Angela and I present at the Efficient Testing Tour. In this talk, I talked about how to use Lab Management as a way to provision and scale environments to create Dev, QA, UAT environments with minimal friction. My slides can be found over here for those who want.

Speaking in St. Louis, Kansas City, and Indianapolis on Efficient Testing Tour

I’ll be touring the Midwest in the month of October speaking at the Efficient Testing Tour in the following three cities:

In addition covering how to get value through Microsoft Test Manager, at that event, we’ll be covering how to conduct automated/manual functional testing, and leveraging Lab Management through Team Foundation Server to automate environment deployment and management.

True North

I’ve lately had a few days where it literally does seem like a fire hose is being pointed directly into my mouth with the water turned full blast. With technology and the ways that people generally communicate with us – there are so many “channels” of demands/requests/communication flying at you sometimes. These can include, but probably not be limited by the following: your inbox, instant messenger, Lync, people dropping by in your office, voicemail, and phone calls. It’s amazing that we get anything done ever – on days like this. For me, this is the source of that dirty feeling at the end of the day: “It doesn’t feel like I did anything, but I know I was busy.”

A practice that I have really stuck to over the past few years, has been to keep a prioritized task list and consult with it constantly. I refer to this task list as my “true north” that whenever I’m not sure what I’m doing or if I should be doing it – go back to true north and get my bearings again. The problem with these things and adopting this practice is convenience and forcing you to get the habit adopted. This is what has worked with me:

  • Outlook Tasks is my True North – It has a due date and importance flag – both of which I use as my prioritization schedule. Also – Outlook is somewhere that I’m already using throughout the day. I don’t have to anything special or unnatural to get to my True North, and I think that’s important.
  • Keyboard Shortcut for Add items to the list – Outlook has a bunch built in for tasks as it is already.
  • Keyboard Shortcut for Consulting Truth North – I had to bind a special keyboard mapping to get this to work really well.


Details for this practice for me – in Outlook terms.

  1. Adding Items Easily:
    1. Outlook has the built in keyboard shortcut for “Add Task” as CTRL-SHIFT-K. I recommend getting familiar with all the other CTRL-SHIFT-<key> combinations within Outlook at the sme time.
    2. Quick Steps: Create one for “Create a task with the text of a message” – this lets me move an email directly into my task list. This is useful when I need to move things from inbox over to task list – so that my True North is accurate. Mine is CTRL-SHIFT-1.

  1. Consulting True North:
    1. I use Outlook Today as my view of my tasks. Any command that you add to the quick list at the very top: can be reached by ALT-# (where # is the item’s order in that list from 1 through n). Go bind “Outlook Today” to that list.


Now whenever I’m feeling like I need to refocus, I have a quick way to get back to True North. By making this easy, you make this far far easier to force it to be habit forming. I’m open to using things like TFS’s backlog management/etc., or some other pure task list management apps, and I have tried them out from time to time. Where I fail is that I’m not already in that tool. You can make it habit forming, but at least as far as I’m concerned, it was a hump that I haven’t jumped over successfully yet.

Speaking at Microsoft-St. Louis on Monday 7/29 about Visual Studio/TFS 2013

I’m excited to be speaking again at Microsoft-St. Louis during another product launch season. This time around, I’ll be covering a lot of the ALM features of Visual Studio and Team Foundation Server that are coming out for 2013.

Here are the registration details.

To secure your seat, click here to register with your Invitation Code 50BD3A

July 29, 2013 | Microsoft St. Louis Office | 3 City Place Drive, Ste. 1100 | St. Louis, MO | 63141

Using TFS to Build and Deploy during the Build Process with MS Deploy

Often on projects nowadays, having an automated build and deployment process is a must. Depending on the maturity of the environment there are actually a lot of different ways to achieve these goals, but this post is about one of the simplest ways to get going using a minimum amount of brittle batch/command line tools. For the purpose of this article, I’m assuming you want to use MS Deploy to deploy a web application to in house environments.

Ingredients (what you need):

  • TFS and Team Build
  • Web Deploy Installed on Target Servers
  • Comfort with a little XML editing.

Step 1: Install Web Deploy on Server

Using MS Deploy is extremely convenient – you can package up a website and send it to a server and have it installed with dependencies with minimal effort. Before following this post, you’ll want to install Web Deploy on the target servers.

Step 2: Ensure you have the proper “Configurations” to deploy with

Using Solution/Project Configurations. Typically when you create a new project/solution, you get two configurations: Debug and Release. If you’re using Team Build to perform the deployment, it can be helpful to create a configuration per environment: Dev, Test, QA, Production, etc. To do this, right click on the solution and select “Configuration Manager…” Then select <New> in the Active Solution Configuration. It will prompt you for a name and if you want to copy settings from an existing configuration (such as Debug / Release). Pick one of those.

Step 3: Edit your project file manually

Then you need to modify your csproj (or vbproj) file. Normally you’d expect to use the UI to make project property changes, but in this case, these properties have not been given places in the Visual Studio UI yet. Notice how the project file starts out with <PropertyGroup>s – one that is global, and several (one for each configuration). Find the first one in the file and add these lines of XML in the middle.

These settings will be set for all configurations, even “Debug” which is usually the configuration you use for local development. But because the “DeployOnBuild” property is set to false, msbuild doesn’t do anything with these values.

Next it’s time to modify the configuration that you plan to use for deployment. Look in that file, and you’ll find a line like the following: <PropertyGroup Condition= ‘$(Configuration)|$(Platform)’ == ‘Dev|AnyCPU’ >
assuming “Dev” was the configuration you want to deploy with.

Now, we just need to add two lines inside of that PropertyGroup:



DeploymentIisAppPath – this the “Web Site” name and virtual directoy path that exists within your IIS Server. Do not confuse this with physical file system path.

MsDeployServiceUrl – this is the name of the server – which is all you need in this case, MSDeploy automatically uses the default port of 1872 with SSL to connect and deploy this application.

Step 4: Modify your Team Build Definition

Edit the build definition, go to the “Process” tab. Find “3. Advanced” and you’ll find a place to specify “MSBuild Arguments” – just add the following on that line:

/P:CreatePackageOnPublish=true /P:DeployOnBuild=true


This approach is useful only when you need/can deploy and build on the same action. Some environments require build and deployment to be separate actions such that the compiled bits are identical between environments. This solution does not achieve that – you technically should have a build definition per environment in this case. It has the benefit of being very declarative, plays nice with web config transforms, and overall very easy to implement. Lab Management – a feature of VS/TFS is another way to achieve this – when virtualization can be used – and is relatively easy to set up in 2012.