How to Implement COTS in an Agile Fashion


How to Implement COTS in an Agile Fashion


multiple hanging lightbulbs

Most organizations do not develop 100 percent of the software that they use, nor should they.

A vast majority of the jobs they have to do can be satisfied with readily available Commercial Off the Shelf (COTS) software, or its more modern successor, Software as a Service (SaaS).

Why go through the pain of building something to address the same need that thousands of others have and that many developers have put in the effort to figure out already?

Yet, the organizations that primarily use software developed by someone else are the same ones that are now trying to become more agile, at least in their IT departments. Those folks look at the various frameworks for agile software development (primarily Scrum and SAFe) and say: “That’s great that you’re building software, but what if you primarily purchase and implement it instead?”

Here are some ways I’ve found to implement COTS and SaaS in an agile fashion.

The Goal Is to Get a Job Done, Not To “Be Agile”

I thought I’d get this one out of the way early on.

Being agile should not be your ultimate goal. Rather, your ultimate goal should be to deliver the right outcomes, which you can think of as satisfying your customer’s needs. Agile values provide a great mindset to have in place to accomplish this, but they are simply a means to an end.

Agile frameworks (such as Scrum) provide a starting point for your team to figure out how you’re going to approach work in a way that embodies the agile values and principles which will most likely increase your effectiveness in delivering the right outcome.

In the case of COTS and SaaS, you have a job that you want to get done that is similar to a job that many organizations have, and there are existing products that will help you get that job done more effectively than building something yourself.

Instead of asking how you can implement a COTS software in sprints, ask how you can implement this package in a way that delivers the most value for your organization and allows you to address the uncertainties you run into along the way.

Fall in Love With the Problem, Not the Solution

All too often, organizations implement COTS or SaaS products because someone with a great deal of influence or authority came across a “must-have tool” and began hunting for a reason to introduce it to the organization.

A better way to approach this is the from the opposite direction: start with the problem in mind and describe that problem in the terms of what value it has for the organization. I find that collaborating with impacted stakeholders to create a problem statement can help you build a shared understanding of the problem.

When you understand the issue at hand and want to identify possible solutions (some of which may not actually require software), you may find a technique such as Impact Mapping helpful.

Once you’ve identified desirable characteristics of your solution (hint: do not just look at the feature list of someone’s pet product and crib off of that), describe those characteristics in the form of user stories or job stories so that you can focus on the problems you are trying to solve. 

Pick the Right Solution

Now that you understand the problem and know what you’d like in a solution, you can decide whether it makes more sense to build or to buy. Using purpose based alignment can help you determine the right path. If your solution will differentiate you in your market, it probably needs to be unique, so building the solution is most likely the better choice.

If the solution is parity for your market, you may find that you can buy an existing solution.  Should you go this route, resist the urge to customize whatever it is that you buy. That is a sure way to blow your budget and timeline and probably fail at achieving your desired outcome. 

Instead, find the solution that is the most closely aligned with your desired characteristics, and revise processes or expectations in the small cases where you don’t have alignment. This is a parity activity. There is no value for you to do it more uniquely than anyone else.

Iterate and Increment to Learn

When most people think of applying agile to COTS or SaaS, they are trying to figure out how to fit the work of implementing the solution into sprints. There is certainly validity into figuring that out, but it’s essential to understand why.

You don’t iterate and increment for the sake of doing things in sprints. Rather, you iterate and increment in order to learn.

Most COTS and SaaS solutions require some amount of configuration, integration with existing systems and the transformation and loading of data from a current system. These activities provide great opportunities for an iterative and incremental approach. The two primary ways you can approach it are:

  • Gradually roll out functionality. Start using the new solution for limited purposes. Perform the configuration and integration to support just that functionality, deploy it and observe the results. Determine what you can learn from that rollout to apply to, configure and deploy subsequent functionality.
  • Gradually roll out to new users. Have a small subset of the total planned user base start using the solution and closely watch the challenges they run into and the feedback they have. Use that feedback to alter your configuration and approach to roll out to the next set of users. When you pick you first users, make sure you select people who are comfortable with change and adept at using products so that they can provide meaningful feedback.

You may find that in some situations you can combine both approaches, especially when different groups of users use different functionality. The key to picking the right approach for you is to select the one that will allow you to learn the most with the least amount of impact to ongoing operations as you make your transition.

And, if you must transition data or content from your existing solution to a new solution, do not wait until the last minute to transition that data over. Determine how you can transition it as soon as possible. If the data changes rapidly, you may have to wait until just before go-live time to transition that data over. If it rarely changes, move it over immediately so you can test your new solution in as realistic a setting as possible.

Agile COTS/SaaS Is About Value and Learning

When you implement a COTS or SaaS solution, figure out the problem you’re trying to solve, have a clear understanding of how the solution will help you solve that problem and implement it in a way that will help you learn along the way. Doing so will help you deliver the right outcome to your organization.

What experiences have you had implementing COTS and SaaS solutions? Did I miss anything? Share your thoughts in the comments section below.



 

Kent J. McDonald is the content curator/product owner for the Agile Alliance.

Learn More
comments powered by Disqus