At Sprint.ly we’re big fans of shipping. So much so that we militantly remove anything that stands in our way of shipping, including process.
“You can’t ship process.” – Ethan Kaplan, VP of Product at Live Nation
Our approach, which we call Non-Blocking Development, isn’t so much a methodology as it is a pragmatic approach that optimizes for shipping working software over everything else.
As far as the Agile Manifesto goes, we’re in total agreement that the priority of software development is to ship working software, but we disagree on two key aspects:
- Invest heavily in automation vs. “Individuals and interactions over processes and tools”
- Treat your makers as asynchronous threads. vs. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
The agile manifesto was written years before the modern automation and DevOps movement really got under way. The cloud didn’t exist. Servers and services we rely on weren’t ephemeral in nature. If you’re not heavily investing in automation and tools, you’re exposing yourself to risk in the cloud and hindering your technical team’s ability to ship software.
Another very anti-agile pattern in NBD is that the business should move entirely to asynchronous communication. While we agree that face-to-face communication is the most efficient and effective method of communicating, we do not believe it’s pragmatic in today’s working world. Globalization is happening at a frenetic pace. Businesses have teams dispersed across the globe. Strictly adhering to this principle would, in fact, have the opposite effect on businesses.
The realities of managing knowledge-based workers dispersed around the globe are leading many of us to re-think our approach. Strictly adhering to process dogma won’t fix inherently human problems like timezones.
“You have to be agile in your approach to agile.” – John Quinn, VP of Engineering at Gilt Group