Credo

Good teams share a common set of values. These are the values that make Sparkfish...

We are healers

We don't shy away from the daily struggles and pain points, and we don't turn a blind eye to them. We embrace these, as the mother of innovation.

We tear down walls

Organizations achieve their best by tearing down the boundaries that separate business objectives from technical solutions. An organization can't solve its problems until they overcome hierarchies and integrate the experience, knowledge and a clear mission throughout its organization.

We value open source

We all benefit from open source software. We also have a duty to sponsor and contribute, which benefits the common good.

We are family

We enjoy breaking bread together. We build strong relationships among ourselves, which is the best way to ensure that we all thrive and stay committed to each other.

We share common goals

Leadership begins with the individual embracing the mission and goals of the team, then setting forth to achieve them. It is the team’s responsibility to ensure that individuals have the opportunity to learn, grow and take ownership of these common goals.

We walk in your shoes

We win by solving your problems. That starts with seeing problems through your end users' eyes. We don’t just work for you; we partner with you to ensure mutual success. To us, collaboration among peers aimed at the same goal is beautiful and inspiring.

We solve problems

Life is too short to have to deal with the bureaucracy that stalls real work from getting done. We value cutting to the chase, rolling up our sleeves, and getting started. To us, this isn’t just a business. We are talented individuals who take pride in crafting quality software that solve real world problems.

It started with a spark...

Journey of the Industry

The war was against overdue and over-budget projects that 70-hour work weeks couldn’t save. As part of these endless battles, we (the software industry) tried to improve testing practices, improve code quality and find other ways to make projects more maintainable. The measure of success was evolving our ways, so that the projects could survive long enough to enter production.


Well before Agile was a thing, we were struggling to solve the big challenges the industry had wrestled with all the way back to the days of “The Mythical Man Month.” Our lineage began in organizations with significant accomplishments like SEI CMM Level-5 assessment, projects developed solely using object-oriented modeling tools with 100% code generation, and projects with multiple releases on time to the day with no overtime. We were around to experience the victories in some of the 1990’s software battles, but the war raged on. These process-oriented approaches, however, were often just illusions. Projects may have appeared to have been on time and budget; however, by not meeting the true requirements, which are often impossible to know in advance, these projects would eventually fall short of success or the ultimate promise of software development to rapidly and efficiently solve business problems.


By 2001 and the birth of the Agile Manifesto, we were still engaged in the big war, but the goal of our battles had shifted from trying to master the art of engineering great software on-time and under budget (a process-oriented approach) to that of building great agile teams (a culture-oriented approach). Looking retrospectively, we can proclaim victory in that the 12 agile principles have stood the test of time and many great agile teams have been assembled and have created a lot of great software, but we still haven’t won the war.


We haven’t encountered any credible person or organization who is “anti-agile” or who isn’t still striving in some way to meet the ideals of agile. The only people who come close to this are the ones who have said they had been doing agile for years or doing agile under a different name. However, these people have missed the mark. You don't do agile. You are agile.


If we've reached a conclusion yet, well into the second decade of the agile revolution, it's that the promise of agile has only been fully realized for small teams. Larger organizations have found that agile is difficult to scale without losing the intended benefits. They treat agile as yet another process, as you must when managing projects in large organizations. The problem is, however, that Agile can't be treated as steps; it's a philosophy and an approach to problem solving.

Our Journey

We have built one of the great agile teams, bringing together a wealth of experience from individuals with journeys of their own, all of which centered around a commitment to problem solving and building great software. We have backgrounds in working with large government contracts and alongside monolith consulting firms. Businesses struggle to carry the overwhelming weight of bureaucracy and lose the hunger and ability of a startup to innovate. We've operated a small team approach to solving big problems for more than a decade. In this situation, we are motivated because we are closer to the problem than our fellow teams in the larger organizations with layers and distance between themselves and the problems they are trying to solve.


However, when we found ourselves being distanced from the problems that needed to be solved and that distance between our end users and daily work was growing larger, we knew we had to branch out and reignite our passion for building great software, improving user experiences, and to help other businesses free themselves from the shackles of bureaucracy.


Sparkfish was born from our desire to build software the right way, restoring the reputation of software as a profession tarnished by the industry trend toward seeking cheap solutions and to provide high value to you, our customers.