Why not Agile for COTS?

Is it just me or does it seem like COTS implementation is perceived as incompatible with Agile? I just don’t understand why that should be so. After all, much of the up front product conceptualization is already complete when you implement a Commercial Off-The-Shelf (COTS) software system, isn’t it? As you will see below, this has proved true in my experience.

Please note that in the interest of brevity, I assume some familiarity with Agile terminology and methods.

If I were to start a custom software development project from scratch using Agile, I would lead my client through a Product Vision exercise where we would gamestorm our way to a clear concept of the product to be developed culminating in a Product Roadmap. We would then workshop all User Stories for each user role of the roadmapped product, again using (incredibly fun and productive) gamestorming techniques, to create a High-Level Prototype. Next comes User Story estimating; then Release Planning, including User Story priorotization, followed finally by Iteration Planning and the execution of each iteration.

I submit that if a COTS product is properly analyzed and selected to fit the majority of the critical business requirements, then the Product Vision, Product Roadmap, High-Level Prototype, and even some User Stories are already complete. I see applying Agile to COTS as an ideal fit given that, in the worst case, the Product Roadmap will exist by default before you even start your project.

Don’t get me wrong, there are plenty of requirements to understand and implement in a COTS project. However, there should be no argument that there is a head start in satisfying *all* the requirements. If there isn’t, then a better fit COTS solution should have been selected or a custom solution developed from scratch.

So, let’s say that you have selected a COTS product. What would implementing it using Agile look like? Here’s a high-level description of how I structure my COTS implementation projects.

User Stories & High-Level Prototype

As described above, the Product Vision and Product Roadmap should be well understood for a COTS product. Although that frees us to begin work on the requirements that aren’t satisfied “out of the box” by the COTS product, we still must document *all* of the business requirements. How is that saving any effort, you may wonder? Many of the requirements should be at least partially satisfied by the COTS product, assuming it was well selected, so our effort will be saved in Iteration Planning and Execution. More on that below.

A COTS implementation User Story Workshop is no different than a custom development one. All User Stories within each user role of the Product Vision and Roadmap must be defined, culminating in a High-Level Prototype.

Because this exercise is typically more detailed than the COTS selection process, it is likely that some User Stories will be specified that are well outside of the scope of the initial COTS implementation. These “gaps” should be tracked as future feature enhancement requests for the vendor. Even though a story may be out-of-scope, it should be estimated as a customization because it may be assigned a high priority by the Product Owner.

User Story Estimation

This is where the COTS and custom development paths begin to diverge. All User Stories must be built from scratch in a custom development project. With a COTS implementation, many of the stories will be satisfied “out of the box”. No matter how you decide to estimate your COTS User Stories (t-shirt sizes, ideal days, etc), it is absolutely critical that the COTS vendor development resources be active participants. After all, only they know what it will take to configure or customize the product to satisfy a story. In some cases, the vendor may identify a story as partially or completely satisfied by some element of product functionality. This must be estimated (could be zero if the story is completely satisfied “out of the box”) and documented in the User Story so that tasks for the story can be accurately defined during Iteration Planning.

User Story Prioritization

This is no different than for a custom development project. Armed with estimated User Stories, the Product Owner prioritizes each story.

Release Planning

Again, there is no change from a custom development project. The team, with a now prioritized product backlog, can sort stories into releases by priority and according to the Product Roadmap. The team must also establish an iteration length and an initial iteration velocity (I’m assuming some form of time-boxed iterative methodology will be used).

Iteration Planning

No change again in terms of decomposing user story release backlogs into iterations. As the team places a User Story into an iteration, it breaks that story into deliverable tasks as normal. In the case of COTS, and as described above, there should be stories that are completely or partially satisfied. Completely satisfied stories that have achieved their “definition of done” are still assigned to an iteration based on their priority. They would not count for the team’s iteration velocity as they would have been assigned an estimate of zero

The rest of the project can be executed as a normal agile project with stand up meetings, daily work, retrospectives, continuous improvement and the delivery of working, user-valued functionality.

I hope the above has convinced you that Agile and COTS do play together, assuming you needed convincing in the first place. In my experience, they do so quite well so long as the COTS product has been selected with rigor to satisfy as many business requirements as possible. If it has, your Agile COTS implementation project should have quite a head start. If it doesn’t get a head start with many already satisfied User Stories, you should consider that a statement about the quality, or lack thereof, of your COTS selection process.