In a recent end-of-engagement meeting, I asked our client why he continued to work with Quick Left. His answer was that “we don’t want to crowdsource our bug hunting.” He went on to compliment the delivery team on consistently writing test-covered code in a well-structured format within a consistent process. We wrote code that creatively solved his problems and could be understood by the next developer to spin up an environment. New pull requests triggered well articulated tests and led to less scrambling upon deployment to put out unnecessary fires.
There are those in the marketplace that loathe process and shed it at every opportunity. That energy is an important force to balance the process heavy, newly minted MBAs trying to run development organizations but it ought not be treated as an intrinsically valid methodology. Process, like software, should be approached leanly, as a series of iterated MVPs under the constant scrutiny of the users it serves (Quick Left calls this “Adaptable Agile”). It is foolish, however, to cut “process” from the budget in favor of a “wild west” approach. Here’s why:
Bad Code Breaks:
Let’s say you contract two different vendors to build the same MVP application: a group of freelancers and a “fancy” shop. In the context of the three months it takes to build, the resulting application may feel the same to the user and the freelancer version may cost 40% less than the fancy shop! In the context of the next three, six and twelve months, however, the costs incurred to maintain, refactor, and re-learn code created in a vacuum will eclipse any short-term savings it provided.
Process-driven Code Scales:
Building with the future in mind and building a minimum viable product are not inherently contradictory concepts. In fact, the ability to achieve both is a hallmark of process-driven development. When the development team understands the business goals, the user personas and the ROI metrics, they can build beyond the acceptance criteria and prepare for the future.
Transparency Drives Accountability:
A professional development environment offers clients myriad windows into the architecture decisions and productivity of the development team, increasing accountability and agility. You, the client, should have control over the pace of the team and the quality and scope of the work that brings your vision to life.
Developing a web or mobile application is like building a house: you don’t see the “guts” and, when constructed professionally, you are rarely aware of the plumbing, electrical wiring and insulation. When those critical systems fail, however, the resulting floods, re-wiring and heating bills become annoying and expensive.
Should you buy a Lexus when a Honda will do? No. Should you buy new or certified pre-owned instead of a beater from Craig’s List? When you’ve got a 40 mile commute to a job that values punctuality, yes you should!
Your application needs to stand the test of time. It should be architected well enough to facilitate quick updates and constructed systemically enough that new developers can jump right in. Does your development team need to have enough process to run a multi-national corporation? No. It needs the minimum viable product version of process to ensure stability, scalability and accountability.
Want to experience Adaptable Agile for yourself? Contact Quick Left anytime at hello(at)quickleft.com.