Blog News and events about Polaris Solutions!

Promote the Bits or Promote the Code

by Chris Kadel on July 30, 2014

Release management in the enterprise has design patterns just like software has. A design pattern in the software design is a way to communicate recurring structures of code and logic in applications architectures. They help technologists in various roles communicate intent and structure in a succinct way. If both people are aware of a particular design pattern, then a huge short-cut in communication can be reasonably be taken. Invariably in my consulting career when doing a tools-focused engagement, we start to talk about how to do automated builds and deployments. One of the first decisions is whether or not to couple build and deployment and this is a "release" pattern that enterprise teams are choosing all the time.

Promote the Code.

This pattern was earlier defined commonly as "Source Code Promotion Modeling" – essentially having a branch for every environment, and create a build for every branch that would deploy to that environment. This can be represented by the diagram below showing the artifacts that would typically be created in this situation.

This has traditionally been less expensive to implement. It requires developer skillsets in branching and merging which are ubiquitous, and it requires very easy configuration strategy for builds. The downsides are two-fold: (1) Code is recompiled in each environment and therefore what was tested in a lower environment is not being promoted, but rather in best cases the actual source code was that gets recompiled and (2) Depending on implementation, even the same code cannot be guaranteed to be the same in the lower environments if reliance on merging with the possibility of two-way merging can happen.

Promote the Bits

In this world, the source code is compiled once, but released/deployed potentially man times. This has the result that the compiled binaries that were tested in a lower environment are identical to the ones that are being promoted to the higher environments. Typically, the application is just re-configured in each of the environments that are required. The downside has traditionally that this is certainly more sophisticated and thus more expensive to deploy in enterprises that are just adopting new patterns. What is changing however is the cost to move to this pattern has started to decrease in the Microsoft community due to Microsoft's entry into the market through "Release Management for Visual Studio." Having an anointed Microsoft solution, in reality, has pushed this scenario more and more into the mainstream of enterprise software development.

Neither of these concepts are new. Using Team Foundation Server and Release Management, both scenarios are fairly easy and cost effective to implement. I have found that these two phrases: Promote the Bits or the Code -- definitely have simplified the conversations with my clients and allowed us to move into the things that in fact do vary from client to client. If you're small and looking for some quick wins – Promote the Code can work. If you're subject to regulatory compliance such as SOX or other – Promote the Bits looks to be the answer.


ALM Lunch: Implementing the Scaled Agile Framework with TFS 2013

by Clint Edmonson on July 10, 2014

Organizations looking to go agile with Team Foundation Server often get the building blocks and infrastructure in place but struggle to achieve broad scale adoption across their enterprise.

The Scaled Agile Framework, abbreviated as “SAFe”, is a proven framework for implementing lean and agile methods at scale. SAFe provides prescriptive guidance for the individual roles, teams, activities, and artifacts necessary to scale agile and provide strategic alignment from the team to program to enterprise level.

The team of certified SAFe Program Consultants at Polaris Solutions have distilled the framework guidance into a custom process template that fully implements the Scaled Agile Framework within Team Foundation Server 2013.

In this free lunch time event we will provide an introduction to the SAFe, walk through the custom SAFe process template for TFS, and touch on best practices we have learned and applied while helping our clients leverage SAFe to take their agile teams to the next level.

Key Experiences:

  • Introduction to the Scaled Agile Framework
  • Overview of the SAFe Process Template for TFS
  • Tips & tricks for getting the most value out of SAFe with TFS

Complimentary lunch will be provided to registered attendees.

Seating is limited. Register Now!


Strengthening Your Team Through Vulnerability

by Angela Dugan on May 27, 2014

I go through phases where I devour books, usually when I am attending industry conferences where speakers are recommending books that have elicited “AHA!” moment for them. In many cases, it’s the same handful of books being quoted repeatedly. These 3 books in particular have been coming up a lot, and they inspired me to rethink how I work, and live:

1) Drive (which I am actually reading right now for a second time)

2) Five Dysfunctions of a Team

3) Getting Naked.

The first is a psychological study into what motivates people (hint:it’s NOT actually money in most cases). The last 2 are actually “business fables”, a genre that I hadn’t realized existed before now, and that I really enjoy. I am noticing a few themes common to all 3 of these books, that can have a tremendous positive impact on organizations. Yet in my experience, these themes rarely come up when management is discussing strategy for change, whether it be organization-wide or focused on a particular group. No matter how well thought out your processes and procedures are, or how “best of breed” your new expensive tooling is, one thing will always lay waste to even the best laid plans, is culture. Now, addressing corporate culture is nothing I can sum up in a single blog post, but one aspect of it in particular calls out to me as needing urgent attention. FEAR.

I am not suggesting the use of fear to control your team, quite the contrary. I am suggesting that to strengthen your team, you need to expose your fears, more specifically you need to show each other vulnerability. Does that sound a little odd to you? Are you thinking “how can I be a strong leader or teammate if I am showing fear, or appearing vulnerable to my team?” It seems a bit counterintuitive.

Many of the issues that prevent people from breaking old habits, from really making a difference, from moving forward, is guardedness. I see this not only on teams I have worked with professionally, but in myself in my daily life. I suspect many of us keep our guard up by default. We protect our calendars, our intellectual property, our reputations. But this often means we are effectively operating as a team of 1, and there is no real sense of understanding or trust between team members or between the team and its leadership. Adding to that, if there is an implied stigma (or explicit punishment) for saying “I don’t know” or “I made a mistake”, more focus and energy will be spent by people on protecting themselves, rather than on learning from their mistakes and improving.

For the team, it means admitting when they need to do some research before taking on a new project, admitting they need more time when their forecasts were off because they did not understand the full scope of a problem, or admitting when they have hit a wall and need some help to make progress. For management it means admitting your own mistakes to your own managers as well as to your team, trusting your team to do the right thing, and accepting mistakes as an opportunity for growth. If all of that seems overwhelming, start by sharing your stories with one another - a few basic facts like your least and most favorite subjects in school, your hobbies, the last movie you saw.  The simple act of sharing a few bits of personal back story with one another can really open people up, inspire a base level of trust, and even uncover common threads that bring a team closer together. It might seem trite, or overly simplistic, but you’d be surprised how differently you view your teammates when you find out they coach little league 3 nights a week where your kids play, or that someone else has also dreamed of being a concert pianist all of their life. Give it a try…

Until we all learn to be open, honest, and vulnerable with the people we work with, it will be extremely difficult to ever build up the level of trust necessary to truly improve and grow, both as individuals and as a team. And seriously, go to Amazon and pick up those 3 books right now.  It may just be the best $40 you’ve spent in a while.


Getting Real ROI (return on investment) on ALM

by Chris Kadel on April 30, 2014

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.

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.


Why ALM Matters

by Josh Gillespie on April 10, 2014

Why ALM Matters

I recently heard a podcast where David Chappell said something that piqued my interest. Paraphrasing, his thinking went something like this.

Given that...

  • Business processes support what the business does.
  • Those processes that give a competitive advantage are the most important.
  • Those important processes are always supported by custom software.
  • Custom software is the output of the Application Lifecycle Management (ALM) process.

We can assume that the success of a company is fundamentally linked to how well it does ALM.

That's quite a statement. My kneejerk reaction was to take issue with the third point; business processes conferring competitive advantage are always supported by custom software. However, I thought more about it and I've come around some. I still think "always" is an overstatement, but "often" or "usually" might be appropriate.

It took me more time than I'd care to admit that I missed the point. I was hung up on the wording and dismissed the core idea.

Looking at it from a different angle

Instead of David's set of statements, let's think about this assertion.

A company only writes custom software to gain a competitive advantage. Nothing else justifies the costs and risks associated.

Competitive advantage comes in two main varieties: comparative and differential. Comparative advantage is efficiency. Can you do something at lower cost than your competitors can? If so, you can undercut their prices or have a larger margin. Differential advantage means exactly that: Are you different? Is your company doing something no one else can do? Did you invent a new product? Is your customer service better?

So how does custom software create the advantage? Here are a few examples

  • You're writing an inventory app that will reduce stock on hand and speed delivery
  • You've created an innovative talent recruitment and retention system.
  • You're planning a custom application that will streamline a task that takes three off-the-shelf products.
  • You only need a small subset of features from commercial offerings and are writing your own to avoid reduce cost.

Moreover, creating competitive advantage with custom applications makes the advantage harder to copy.

Custom software is expensive and risky. It takes time to plan, develop, test, deploy, train, support, etc. Therefore, if it isn't giving you a comparative or differential advantage, it isn't worth it.

Why ALM Matters

So custom software is written to confer competitive advantage, but can only confer that advantage if it is delivered, functional, usable, cost-effective, and timely. Given that, organizations with quality ALM will gain more advantage and be more competitive those without.

That's why ALM matters. The success of a company is fundamentally linked to how well it can produce the custom applications that create an advantage. Failed software projects are failed attempts to better compete.



(Cross-posted from


Announcing Test Lab Management in Windows Azure!

by Josh Gillespie on March 17, 2014

Polaris Solutions is proud to offer an exclusive set of tools and services that allows testers using Microsoft Test Manager (MTM) and Lab Center to tap into the power and scalability of Windows Azure.

MTM has proven to be an invaluable tool to many enterprise testing organizations. Unfortunately, the overhead of provisioning and managing virtual machines to support the dynamic needs of testing teams has meant that the powerful self-service infrastructure features of Lab Center have largely been ignored.

Leveraging the cloud to remove this burden from organizational IT staff is a natural solution.The demand for cloud based testing facilities from our customers has led us to create this unique offering that fully integrates on-premises testers with self-provisioned test infrastructure hosted in Window Azure.

Key Benefits:

  • No on-premises infrastructure necessary
  • No dependency on IT operations staff
  • Testers start up and shut down their own cloud virtual machines.
  • Testers create new cloud virtual machines as needed, optimizing both time and cost
  • Testers can leverage a library of pre-built virtual machine images
  • Testers can provision new virtual machines from scratch - testing agents will automatically get installed and connected to your test controllers
  • Lab Center sees cloud virtual machines as standard domain network machines
  • Available today!

Contact Polaris Solutions to learn more about this powerful solution.


ALM Lunch: Achieving Agile Success with TFS 2013

by Clint Edmonson on March 03, 2014

imageWhether you are a small development shop just starting out with Agile or an enterprise IT organization seeking a full blown Agile transformation, Microsoft’s latest ALM platform provides a powerful and flexible toolset to help you successfully practice lean and agile software development. The combination of Visual Studio and Team Foundation Server 2013 bring valuable features and capabilities to agile teams through an easy, simple-to-use experience on top of a powerful, customizable platform.

In this free lunch time event we will go deep into the Microsoft tools that accelerate agile development. We will also touch on best practices we have learned and applied from helping our clients leverage these tools to take their agile teams to the next level.

Key Experiences:

  • Agile release & sprint planning
  • Kanban boards & WIP streams
  • Architecture in agile projects
  • Testing in agile projects
  • Continuous integration
  • Scaling agile in large organizations
  • Best practices & lessons learned in the field

Complimentary lunch will be provided to registered attendees.

Please join us for this special event:

     April 2, 2014      11:30 AM – 1:00 PM      Microsoft Office, Creve Coeur, MO

Seating is limited. Register Now!


An Introduction to SAFe and Why You Really Should Care

by Clint Edmonson on February 28, 2014

The Scaled Agile Framework, abbreviated as “SAFe”, is a framework for implementing lean and agile methods at scale. It was pioneered by Dean Leffingwell and fully described in his book Agile Software Requirements. SAFe provides prescriptive guidance for the individual roles, teams, activities, and artifacts necessary to scale agile from the team to program to enterprise level.


SAFe’s guidance is divided into three layers, each aligned to a level of abstraction matched to project scope within an enterprise. Actionable work is driven top down through cascading backlog queues and a simple, well defined taxonomy.

The Portfolio layer defines a framework for managing an enterprise project portfolio. The portfolio is implemented as a backlog of business and architectural “epics”, high level narratives aligned to strategic investment themes. Approved epics are delivered to the Program layer for further exposition and scheduling for implementation. 

The Program layer defines procedures for turning approved epics into proper product plans and is responsible for delivering a value stream to the organization. Activities include developing product visions, a backlog of high level “features” to be implemented, product roadmaps, and iterative release plans. Project features are batched up and delivered to the Team layer for implementation.

The Team layer prescribes a combination of Scrum management practices and XP technical practices to empower agile development teams to turn features into “user stories” and deliver working, valuable software in two weeks sprints.


Why You Really Should Care

So why am I raving about this? Agile has become the first choice for development teams building software, but true enterprise agile transformations are still rare. Adoption inside many enterprises has stalled due conflict with traditional waterfall business planning and budgeting processes. Here’s why I think SAFe can succeed at driving full scale enterprise agile adoption:

Simple. The epicfeatureuser story taxonomy is the heart of this framework and the key to tracing efforts through these layers to achieve synchronization, collaboration and business value delivery. Its simple to learn and easy to teach – a key ingredient to cultural transformation.

Comprehensive. The layered abstractions chosen for SAFe provide the just the right amount of focus at the executive, product management, and development team levels. The roles and procedures are well defined and cover the complete set of activities needed to manage a portfolio of enterprise IT projects. SAFe will educate and push agile up into the very heart of the enterprise.

Actionable. SAFe provides concrete procedures and detailed steps on how to get each layer up and running. It’s very real, very approachable, and very doable.

Well Documented. Leffingwell’s Agile Software Requirements book is in truth a playbook for enterprise agile transformation. It describes every detail of the SAFe framework and is one of the best written technical books I’ve read in years. Dean and his associates have also done an outstanding job documenting and “open sourcing” the framework through it’s public website –

Proven in the Field. The framework has been through numerous iterations, and has evolved through a number of large scale adoptions at real world enterprises, large and small. The latest version published on the web site (v2.5 as of this blog post) has been validated by these field implementations and all the major ALM software vendors have either adopted it directly or facilitate an implementation of SAFe within their product.

I honestly haven’t been this excited about a SDLC methodology in years (I read Dean’s book cover to cover in two days – a rarity for a technical book). I see SAFe as a natural and necessary evolution of Agile upwards into the enterprise to fill a missing void. I believe it will quickly become the foundation for many of our client engagements.

Note: Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC.


OpsHub and Polaris Solutions Announce Partnership to Drive Collaboration and Efficiency of Teams in the Software Development Lifecycle

by Chris Kadel on February 19, 2014

OpsHub and Polaris Solutions announce partnership offering software development organizations a comprehensive Team Foundation Server (TFS) based solution for quick and easy adoption of Team Foundation Server (TFS), driving collaboration and efficiency of cross-functional teams in the software development lifecycle.

Palo Alto, CA, Chicago, IL and St. Louis, MO— OpsHub and Polaris Solutions Announce Partnership to Drive Efficiency of Teams in the Software Development Lifecycle—OpsHub and Polaris Solutions are pleased to announce a partnership enabling easy adoption of Team Foundation Server (TFS) to drive collaboration and efficiency of teams in the software development lifecycle. With this partnership, OpsHub and Polaris Solutions can offer the industry leading Application Lifecycle Management (ALM) integration and migration platform with Team Foundation Server (TFS) expertise and best-in-class ALM implementation and consulting services.

OpsHub and Polaris Solutions are both Microsoft Visual Studio 2013 Launch Partners and have strong ties in the Microsoft partner and customer ecosystem.

OpsHub Integration Manager's broad ALM support addresses the challenges faced by larger corporations looking at Team Foundation Server (TFS) adoption within their heterogeneous ALM environment. Polaris Solutions has best-in-class ALM implementation and consulting services with expertise in Team Foundation Server (TFS) adoption for the most challenging environments.

"The OpsHub and Polaris Solutions partnership, provides great value to our customers, by helping them quickly adopt Team Foundation Server (TFS) within their heterogeneous ALM environments. Our combination of powerful integration tools and deep implementation experience will help drive efficiencies and collaboration between cross-functional teams working on multiple projects in the software development lifecycle." said Chris Kadel, Principal at Polaris Solutions.

"Our customers will greatly benefit from the deep TFS expertise and best-in-class ALM implementation and consulting services of Polaris Solutions," said Sandeep Jain, President and CEO of OpsHub, "and will be able to quickly adopt to Team Foundation Server (TFS) using OpsHub's integration and migration platform, reaping the rewards of Visual Studio that much faster."

OpsHub delivers their on-premise and cloud-based solutions to enterprises around the globe.

About Polaris Solutions

Polaris Solutions is an Application Lifecycle Management (ALM) consulting firm with offices in Chicago, St. Louis, and Denver. Polaris Solutions specializes in helping teams deliver high value software through technical leadership, process improvement, and software development expertise. Polaris Solutions provides industry proven expertise in software delivery and deep technical knowledge to its clients. It offers fresh insights and new directions to help companies take their next step forward with today's powerful technologies.

For more information:

About OpsHub

OpsHub is the leading provider of Application Lifecycle Management (ALM) integration and migration solutions for application development organizations. OpsHub creates a unified ALM ecosystem by seamlessly combining individual ALM systems, enabling agility at scale. 

The OpsHub solution provides the most comprehensive out-of-the-box integration and migration solution within the ALM ecosystem. Its span across ALM functionality, includes requirements management, source control, bug tracking, test management, release management, and customer support.

The OpsHub solution enables quick migration and seamless integration between leading ALM systems including those from HP, Microsoft, IBM, Accept, Atlassian, Rally, Serena, and more. OpsHub delivers their on-premise and cloud-based solutions to enterprises around the globe. For more information, visit

For more information, press only:

Jyoti Jain


For more information on OpsHub support for Microsoft Visual Studio 2013, visit:


Platinum Sponsorship for Chicago Code Camp 2014

by Clint Edmonson on February 10, 2014

We’ve just signed on as a Platinum Sponsor for this year’s Chicago Code Camp at the College of Lake County campus on April 26th, 2014.

Chicago Code Camp is a free, community-driven developer conference. Over 200 attendees and 17 sponsors filled the campus of College of Lake County last year and this year is shaping up to be even better.

This amazing event is completely free, so head on over and register now!