When an Agile team chooses an “out of the box” or third-party solution for a software project, it is a lot like you and your college roommates getting a dog senior year.
A crucial part of the work we do here at DOOR3 is to ensure our applications play nice in our clients’ IT environments. While we deliver custom solutions, we often use some sort of third-party product, either to offload some of the not-so-custom development work or to fit into our client’s broader technology ecosystem. Using established solutions, even when you are building a custom product, can save cost, time, and potentially de-risk certain aspects of a project, but whenever you are adding or changing a component in a business’ toolkit, great care must be taken. We see this choice as a building block for the value we add and, yes, there are a few ways in which it is like choosing to get a dog.
We all have great ideas about what it will be like to have one, each based on our own needs.
Fred likes a dog on his lap while he reads. Sue wants to play catch. Stan likes to socialize at the dog park. You can try to offload the decision to one individual or team, but everyone should be on the same page about their needs. List the requirements, features, and risks before you seek out a solution. Give them weight based on priority and do a grade matrix with the products you are considering.
No one wants to talk about who will take care of it in a year’s time.
Once your puppy is no longer cute and little, it will still require plenty of time and attention. Similarly, an Agile team can’t expect to be caring for the SaaS indefinitely, so consider who will handle support if a critical bug emerges related to the integration or if developer time is needed to expose a great new feature. Lean on the vendor’s resources. Cultivate a good relationship with the people who can help you in a pinch and take advantage of the support that’s in the contract.
No one thinks of how much training it will take.
The household budget really takes a hit when the dog eats all the furniture for the first three months. Plan on there being a ramp-up period and train everyone on the team on the capabilities and challenges of the solution. Don’t make one person “the guy” and count on that person to not get overloaded or ever take a vacation.
No one plans to pick up the poop.
We weren’t imagining picking up warm dog poop when we thought about getting a dog. Have a strategy for how to deal with problems. Identify risks related to the integration. Make a plan to mitigate them.
Everyone forgets that the dog has a mind of its own.
Fred finds out the dog is now too heavy for his lap. Sue learns that the bringing-the-frisbee-back and not-eating-it part of fetch is hard to teach the dog. Stan’s ex has a dog now too, and she is at the dog park with her new boyfriend all the time, so he no longer wants to go. No solution is a silver bullet and expectations rarely meet reality. Architect your solution so that you can replace the product in the future, if need be. During your quarterly and annual reviews, take a dispassionate look at whether it’s working for you—and don’t get lost in the Lost-Cost Fallacy.
While there are plenty of pitfalls to getting a new puppy, it’s also an apt metaphor for integrating third-party software. Hopefully we’ve given you a few things to think about and maybe even a chuckle. At very least we hope it is a starting point for the conversations you might have, not just with us, but with any other vendor you choose and even your own internal teams.
