When Agile's "Deliver Working Software Early" Doesn't Work

One of the pillars of agile methodology, is in advocating that software is released and delivered early & often, to users and stakeholders. The premise is that by having the software in the hands of one's intended customer base early on, affords the startup with the ability to find /changes early, when they are easier to make/, according to Stellman, Andrew. “Head First Agile.”

Founders and Product Owners are tasked with finding the optimal time to validate functionality and features, and agile breaks user stories modularity into a scrum or Kanban board, with an arbitrary delineation as to when they can build and send to uses. While the notion of working on a specific feature collection as part of a scrum for instance, designing it and coding it, before sending it makes a lot of sense in theory, the practicality is lost.

Accepting this standard agile philosophy from an engineering perspective encourages technical debt, it encourages half-hazard architectural decisions that either overcommit, or under-commit, but either way engineering work as well as design work is potentially wasted. As Stellman rightfully suggests, engineers would push back against pivoting and changing, as /they’ve spent many months working on a feature, changing that code can be a slow, painful, and error-prone process/, the author wrongfully suggests that the developers should change their mindset, rather than the founders.

One reason is that when teams do rework (that’s when they change existing code to do something new) it almost always leads to bugs, often ones that are really nasty and difficult to track down and fix.”

I am of the firm belief that tech debt can be prevented, even in early startups, and this is a perfect example of such, even if it's done in sprint sizes instead of more complete deliverables. The solution is, not to have engineers commit code.

That is, through high-fidelity prototyping like InVision and Sketch, users can get their hands on a rich prototype without code being completed. Granted, it won't be able to provide an as-rich user interaction, due to its limitations, at least the very concepts and features can be articulated well enough. It is a good trade off in my opinion in lieu of engineering effort and architectural effort that could potentially be wasteful.

Ideally from a sprint planning perspective, the design exercise should commence first with the development phase to follow with some lag, to allow for design completion and validation. Adopting a design-first approach gives developers greater assurance that they won't have to code pivot, whilst maintaining the goal of getting your app to people's hands, just not necessarily the software, but sufficiently, just the designs.