Blog News and events about Polaris Solutions!

ALM Lunch: Agile Testing Success

by Clint Edmonson on February 24, 2015

If you are either planning to or are already practicing agile software development, Team Foundation Server (TFS) and Microsoft Test Manager (MTM) offer you a powerful platform to successfully plan, manage and execute agile testing.

During this free lunch session we will cover in detail the different testing capabilities offered by TFS 2013 and MTM for Scrum and Agile methodologies, and will share what we have learned from helping our clients as they implemented and matured their agile testing practices.

Key Experiences:

  • The evolved role of testing in Agile Projects
  • Iteration test planning techniques
  • Test tracking with TFS and MTM
  • Different approaches to bug management
  • Test automation Do’s and Don’ts
  • Testing metrics that are worth measuring
  • Exploratory testing strategies
  • Best practices & lessons learned in the field

When: March 24, 2015 from 11:30 am – 12:30 pm.

Complimentary lunch will be provided to registered attendees.

Seating is limited. Register Now!


clip_image002Alejandro Ramirez is a Software Quality professional and Senior Consultant with Polaris Solutions. He has over 17 years of experience working in software in development, testing, and IT governance. His experiences range from small businesses, startups and non-profits, to Fortune 500 corporations in a variety of fields. He is certified in ITIL and Lean. He is also a blogger, speaker, mobility champion, and helps companies incorporate ALM strategies to continuously deliver valuable software.


ALM Webinar - Continuous Delivery with Release Management

by Clint Edmonson on January 25, 2015

DevOps is an increasingly important part of application lifecycle management and is a growing area of interest as businesses need to develop and deploy quality applications at a faster pace. Release Management for Visual Studio is a continuous delivery solution that automates the release process through various environments all the way to production.

With Release Management in Visual Studio you can configure, approve and deploy your applications for any environment. Create automated deployment orchestrations for each environment no matter how complex the configuration. Delivering your software more frequently and easily to an environment allows your testers to get to work validating your system and keeps your stakeholders involved in giving feedback.

Please join us for this free online webinar to learn more about this powerful ALM toolset.

Key Experiences:

  • Overview of Release Management
  • Installation and Setup
  • TFS integration
  • Approval workflows overview
  • Release Template creation
  • Authoring and maintaining releases

When:   Thursday, February 12th from 1:00 PM – 2:00 PM

Register Now!



clip_image002Żaneta Surdel has been developing software for the last 10 years. She has worked on a variety of projects utilizing various Microsoft technologies and filled a number of roles – programmer, (human) release manager, ALM consultant. She holds a MCSD ALM certification and is a certified Scrum Master. For the last 4 years, she’s been a Senior Consultant with Polaris Solutions.


Minimizing Work in Progress within a Scrum Sprint is Important, too!

by Chris Kadel on January 03, 2015

How many times have you heard the following from the testers in a team attempting to be agile?

"There was not time to test at the end of the sprint. We just got most of the features on the last day of the sprint. How are we supposed to test those features?"

Frankly, I think it happens all the time. This is one of the reasons that some teams try to have the testing teams test features in a following sprint. The problems is that so many teams attempt to apply a variant of Scrum that can be called Scrumerfall. Basically, these teams are treating a sprint like a miniature waterfall project like the following diagram shows.

This team is based on a real scenario that I've seen. The team had three developers, on the first day of the sprint, they all took a PBI and drove it. But what happened? The variation in completion of requirements and development resulted in really squeezing the testers that were on this team. Sure they were working on test cases and test planning initially, and even participating in requirement meetings. Something obviously wasn't working very well. For instance, how well do you think Feature 3 was actually tested?

If that's all we do when setting up scrum teams, we've failed. We haven't allowed testing to happen sufficiently, and we haven't really built quality into the process. We have limited the amount of work in progress (on paper), but technical debt obviously is growing here no matter what.

An alternate reality of Sprint 23 above is executed by the same team, but we've set a WIP (Work In Progress) limit of 2 PBI at a time. Let's see what happens:

What's different here? The total duration of Features 1 and 2 shrunk a little bit because I had to double up the effort short term (we forced the team to collaborate on those features, rather than each going in their own directions). Feature three testing also grew in duration which illustrated it probably needed to get tested more even in the first case. Additionally, the team is often performing all types of the functions in there, from requirements, development, and testing throughout almost the entirety of the sprint. The team was increasing its design, build, deploy cycles and having many of those throughout the sprint, rather than just at the end.

At the end of the day, forcing WIP limits can increase the throughput and quality of features that are running through the system.


Platinum Sponsorship of the St. Louis Days of .NET 2014

by Clint Edmonson on September 19, 2014


The St. Louis Days of .NET conference is coming our way again this year and Polaris is proud to once again provide Platinum sponsorship for this amazing event. This 100% community driven event is an awe inspiring example of how much passionate technologists care about their craft, community, and industry.

This year’s conference takes place November 13-15, 2014 at the Ameristar Casino & Resort in St. Charles, Missouri. The standard price for the two main days (Friday & Saturday) is still $300, but if you act now, you can get an Early Bird discount, bringing the price down to only $200 per person.

We would also like to send congratulations to the stellar Polaris consultants who have been selected to speak this year: Josh Gillespie, Jeff Przylucki, Angela Dugan, and Clint Edmonson. Be sure to check out their sessions and drop by our booth for a chat if you get the chance.


Why Agile Transformations Can Fail: Sense of Urgency

by Chris Kadel on September 03, 2014

At Polaris Solutions, we work with a number of customers who are looking to become more agile in their software development practices. We often help them move in that direction through adoption of new practices, tools, and roles within their organizations. Scale (the number of people/teams affected) and Scope (the degree of change involved) are the two largest variables that go into planning such a change. The bigger the scope and scale together tend to require more effort in order to ensure that the change will be successful and our customers will realize more value. In order to be successful at agile transformations you need more than agile knowledge and experience, you need to be experienced at managing change.

Over the years, as we've been involved in numerous transformations, we've noticed several patterns for success and many anti-patterns. In this post, which is the first in a series of posts that I will write, I want to deal with one common way that these efforts can go sideways or fail: Not establishing any sense of urgency.

The first question to ask is – why the transformation is needed? Is it actually an urgent need? Does your team or organization feel compelled to change now or is continuing standard operating practices considered generally acceptable? Before a team or organization is going to change, they will need to recognize the pain of not moving. It has been suggested that human beings change behavior only in response to pain (either emotional or physical), therefore, the greater the actual perceived or actual pain, the higher motivation to fix it. This is true for agile transformations as well.

Providing strong focus and investment in "the case" for an agile transformation in the enterprise will pay off many times over. The following are some suggestions that we've gathered from our experiences:

  • Ensure Awareness – I've seen too many organizations hope to enact change after 2 weeks of training and never talking again about agile. There are many degrees of education and experiences you can provide a team to illustrate the value of moving to agile. Giving awareness and knowledge can help make the case for agile as it largely makes sense to most team members. "Early and often" is a good rule of thumb when communicating in larger organizations.
  • Identify Champions and Hold Outs – The United States military would like to ensure that it has overwhelming force when engaging in battles, and you should as well when endeavoring to change a company's culture towards agile. You have friends and allies that can be helpful – do not try to lead a change like this by yourself.
  • What Will Happen if We Don't Change – Answer that question for yourself and for your team or organization. Perhaps the answer to this is "quality issues are causing us loss in customers or contracts." You can use a combination of logic and reason and emotion to communicate this concept, but I have found that if it can be tied back to metrics and numbers – most people will understand and align with you.

None of these items really have to do with technology or agile in particular, but the people in our industry that help lead these changes need to consider these concepts if their engagements are to be successful.

Chris Kadel also blogs at


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