Why we don’t follow agile, and why it works for us
When it comes to software development, I have come across a handful of teams who have truly made a process work for them. If you are reading this, you are probably curious about how your team can achieve the same balance—especially if the traditional approaches don’t seem to fit. At Assembly (joinassembly.com) , we have stepped away from conventional Agile processes and adopted something that works for us a stress-free, timeline-free approach to development.
We don’t follow strict deadlines or timelines. You may wonder, how can we possibly ship software on time or maintain accountability without these in place? The truth is, we do it by focusing on the work itself. While our developers estimate milestones, these dates serve as a rough guide, not a hard deadline. Software development is not always predictable—particularly when there is R&D involved, and our developers also have to juggle reviewing PRs, resolving customer issues, or brainstorming future features. With so many moving pieces, we have learned that enforcing rigid deadlines only adds stress and reduces quality.
Introducing "Proof of Work" Development
Our former CPO, Josh Gunning , introduced a model we now call Proof of Work Development. It is a system that has allowed us to build flexibility into our process while maintaining focus on the quality of the output. Here’s how it works: our developers post iterative demos weekly. These demos are then reviewed by product managers, designers, and other stakeholders, who give real-time feedback. It is a highly collaborative process, ensuring everyone stays on the same page, with no assumptions left hanging.
During this process, we capture feedback in Atlassian Jira or Slack Canvas, keeping everything organized and actionable. We have found that by engaging in regular reviews, we reduce miscommunication and ensure that everyone involved—whether it is the product team, designers, or test engineers - is aligned on how the software should evolve. We ship when everyone is satisfied with the quality of the feature.
The result? We work as one cohesive unit, where feedback isn’t just an afterthought but a continuous conversation that shapes the development. It is also worth noting that the only Agile element we have held onto is our standup meetings, which we now do three times a week instead of daily. This ensures that everyone stays connected without the overhead of constant meetings.
No deadlines? Here’s why it works
You might be wondering, “What about customer commitments?” Rest assured, we absolutely prioritize them. Urgent issues are addressed right away, while others are reserved for our dedicated two-day ‘Squash and Solve’ sessions. During these focused sessions, we tackle customer concerns head-on, while also fixing any engineering hiccups, ensuring that nothing falls through the cracks.
However, by not sticking to arbitrary deadlines, we have been able to create a process that allows developers to focus on quality rather than rushing to meet a date on a calendar. We learned early on, from blogs (shared below) about Parkinson’s Law, that tasks expand to fill the time available to complete them. Rushing only magnifies inefficiencies, and with so many facets to software development, those inefficiencies can have a significant impact.
领英推荐
Removing deadlines doesn’t mean we are not productive. In fact, it is quite the opposite. Before adopting this model, we used to ship around 3-4 major features per year. After switching to Proof of Work Development, we have managed to ship over 10 major features annually—and the best part is that it is been done with less stress and more agility (ironically, without following Agile).
Why this approach might be for you
If your team struggles with balancing quality and timelines, consider whether a traditional Agile framework is truly helping. For us, letting go of timelines and focusing on the work itself has allowed our team to thrive. This approach encourages developers to engage deeply with the product, work collaboratively with stakeholders, and produce higher-quality software—without the pressure of arbitrary deadlines.
I hope this article has given you some insight into why you don’t always need to follow strict Agile practices to ship great software. Sometimes, focusing on the proof of work and fostering a collaborative, feedback-driven environment is all it takes.
Further reading:
Actually a number of things mentioned by you has certain parallels in the scaled agile world. For eg., “The proof of work” concept you mentioned seems similar to ARTs (Agile Release Trains) with more frequency. However, any process requires a management which trusts and backs it along with a corporate culture open for innovation in execution frameworks. Eg., The no deadline concept you mention requires that you follow some flavor of lean budget concepts where sunk costs are not taken into account when planning future work. But a lot of corporates fall for the sunk cost fallacy and fail to do course corrections. That’s why any form of lean methods (including yours) require wider adoption and backing. Otherwise, it’s an uphill task.