Blog News and events about Polaris Solutions!

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

by Clint Edmonson on September 19, 2014

image

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 http://chriskadel.com

 


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.

References

 

(Cross-posted from awaitwisdom.com)

 


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.

image

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 – scaledagileframework.com.

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.