When I first started programming in the late 1990s my toolset was comparable to that of a manufacturer a hundred years ago; we were forced in those early days of the web to build everything ourselves. Need web framework? PHPNuke was the best thing going. Need a server? Build them yourself or buy some. Need server automation? Build it yourself. Want to write tests? You’ll probably need to write your own unit test framework. Want to do a code review? Bust out the projector and find a room.
However, the Internet dramatically changed how software developers shipped software. No longer bound by boxed software delivery schedules, developers began iteratively shipping software as it became ready. In 2001, this change in approach was codified under the banner agile/scrum with the signing of the Agile Manifesto.
Fast forward to today and another shift in technology is causing a fundamental shift in the software development process. The programmatic nature of the the cloud world we live in, along with a more sophisticated toolset, have enabled us to ship software in real-time.
As a result, many of my colleagues and more than a few of Sprintly’s customers have dramatically changed how they ship software. The best outline I’ve seen on this newer, more-agile-than-agile approach to shipping software is Scott Chacon’s post on GitHub’s flow. This is the software development workflow that we use to ship Sprint.ly and the workflow that Sprint.ly most closely mimics.
I’m calling it Non-Blocking Development and it’s entirely based on the notion that shipping quality software quickly is a competitive advantage.
The core tenants of Non-Blocking Development (NBD) are:
- Invest heavily in automation. This means spending considerable time on implementing test-driven development (TDD), continuous integration (CI), DevOps, etc.
- All development is done via branches. This minimizes exposure to risk by keeping your master branch clean and isolating changes.
- Branches are tested and deployed automatically on approval. This keeps unfinished features from arbitrarily gating the deployment of completed features.
- Treat your makers as asynchronous threads. If Sally is finished with her story in 2 days, while Bob takes 5 to finish his, why should we arbitrarily wait 3 days for Sally’s story to ship?
Notice what’s not there? There are no sprints. No velocity or abstract points to track. No more iteration schedules. No dates.
What does this mean? It means that our workflow tools need to change. We need to focus less on attempting to control the messy complexities of human-driven workflows and more on cataloging and capturing what’s going on as it happens.
It also means we’ll need to take the notion of cross-functional teams to the extreme. Salespeople, business development, marketing, and PR will need to be more closely embedded into the software development process. It means us software developers will need to learn a lot more about how the business functions and how software can enable the business to operate more effectively.
As software continues to eat the world, I believe businesses will be forced to invest heavily in NBD. Why? Because businesses can’t afford to ship twice a month when their competitors are shipping twice an hour.
This post is based on a talk I gave titled “Couples Counseling for Software Development” at GROW Talks in Vancouver. The slides are embedded below.
