Don’t be afraid to change your mind.
Changing one’s mind is a part of human nature. In software development, shifting project requirements and added features are something any good developer shouldn’t be surprised by. After all, the more enterprise a client, the more ambitious the end goals, and the more cutting-edge technology, the more evolution.
The backlash to change, of course, is to put a label on it. “Feature creep,” “Scope bloat,” “Featuritis,” and “Changing Requirements.” We’ve read all the same scolding articles our clients have. Instead of admitting their team isn’t talented enough, agile enough, or staffed sufficiently to take on such a request, some software development companies put the onus back on the client. Fingers are pointed, condemning clients for supposed bureaucratic infrastructure or a lack of organization.
At Connamara, in over twenty-five years, we’ve never found ourselves in the client blame game. That’s because we’d rather see our clients feel comfortable changing their minds mid-project and be happy with an effective, innovative solution that lasts decades. Furthermore, through Connamara Agile: an approach to test-driven development, continuous integration, and the use of MVPs (Minimum Viable Products), we’ve built a simplified system that emphasizes time-sensitive and cost-effective collaboration.
What Causes a Change in Requirements or Features?
There are dozens of legitimate reasons a client must change requirements or features. New market research adjusts the target audience. A redefinition of the company’s brand. And there are always unknown unknowns. In fact, it’s Agile to anticipate new necessary scope. At Connamara, we encourage a 20% contingency at engagement for any additional effort.
For example, when Connamara worked with Harbor Capital on a custom-built Bloomberg (B-PIPE) dashboard, the investment management firm’s feature specs shifted over time. Our team got to work pivoting from a simple custom dashboard to one that could display large amounts of real-time data and dynamic conversion of foreign exchange pricing. Connamara engaged Harbor Capital in a weekly discussion meeting during handoff to ensure our client was confident in this change. (Read more about our Harbor Capital success story here).
Connamara has several ongoing flexible arrangements with clients to add features and functionality as needs change. Read more about the back office platform we built for Eris Futures and the engineering services we provide to global proprietary trading firms.
A Discovery Process That Helps Us Help You
We understand that clients may have evolving requirements, and we want them to feel comfortable changing their minds. That’s why Connamara’s discovery process is designed to adapt and accommodate your needs throughout the project.
Before we even begin drafting a solution proposal, our business analysts employ Connamara Agile for project management. During the discovery phase, our development team and business analysts work with the client stakeholders to create a prioritized list of features that defines the solution to be built. This initial feature list represents the current understanding of the client and the development team as to what the total scope of the will be. It is important to note that the individual features in the list are independent of each other. This means, generally, that the order in which they are developed can be changed. This also means that when new features are discovered, or the client needs to change direction, the new features can be inserted into the development queue such that the new features deliver the most value. Through this method, change is more easily accommodated than in other software development methodologies like Waterfall.
We Won’t Send Your Project To “Integration Hell”
At the heart of our development methodology is test-driven development. Feature and associated scenarios are expressed as a Feature Test via a human-readable language, similar to the example above, called Gherkin. Feature Tests are executed using the Connamara Testing Framework. The Connamara Testing Framework is based on the Cucumber testing framework. It must be noted that the Feature Tests are written before the code implementing the feature is written.
Once a test passes in our automated test environment, it is considered a regression test and must pass every time the application is built and tested. The major advantage to this approach is that a suite of system-level regression tests is created as the system is being developed and not as an afterthought once the system is “code complete.”
Continuous Integration (CI) is the development practice of merging all developer changes to the source code of a project several times during the day. This practice eliminates the “integration hell” experienced when development teams wait till the last minute to commit their individual changes to the main source code branch of a project.
A build is considered successful if all unit tests and feature tests that are identified to be “regression” have passed. At this point, Connamara considers the application to be deployable to a production environment and able to deliver the features described by passing regression tests.
Developer-created unit tests and the business analyst feature tests are run automatically with each developer commit to the source code repository. The benefit of this approach is that testing is done “early and often.” This catches defects before they can make their way into production and eliminates the need for manual, error-prone, and lengthy manual testing.
MVPs Do Less to Achieve More
An MVP is a stripped-down, quick-to-market version of a project that enables expeditious customer introduction and feedback. Connamara encourages customers to allow us to develop MVPs so they can have confidence in their products and a chance to add features or change scope—minimum Viable Products test core functionality while allowing internal teams to discuss the next steps.
At Connamara, we prioritize a streamlined approach to software development, guaranteeing that we never engage in “gold-plating.” For the uninitiated, gold-plating in software development refers to out-of-scope work (done on a customer’s dime) with diminishing returns.
We understand the importance of delivering software that aligns precisely with our clients’ requirements and objectives. Our dedicated engineering team is committed to thoroughly understanding your needs, establishing precise project requirements, and maintaining open lines of communication throughout the development process.
Focusing on essential features and functionalities ensures we deliver a high-quality product that provides tangible value without unnecessary embellishments. With Connamara, you can trust that your software will be precisely tailored to your needs, free from any gold-plating distractions.