Beyond Sprints: A New Approach to Efficient Software Development

By: Alon Cohen & Grok

Date: June 9th, 2025 (published two days later)

In my earlier blog post, "Do You Prioritize or Multitask?", I examined the drawbacks of rigid prioritization and the necessity of effective interrupt handling in software development. I argued that an obsession with "first priority" tasks often leads to tunnel vision, where developers neglect broader team needs, slowing down the entire organization. Since writing that post, I’ve observed another common practice that exacerbates these issues: the sprint-based development model, or as some call it, a religion. While sprints are a cornerstone of Agile methodologies, my experience suggests they can hinder efficiency, extend project timelines, and create silos within teams. In this post, I propose a new approach to project management that replaces sprints with a continuous task pool, emphasizes daily releases, and prioritizes organizational collaboration over individual task completion.

The Problem with Sprints

Sprints, typically spanning one to two weeks, are designed to focus teams on a set of tasks to deliver incremental value. However, in practice, they often lead to unintended consequences:

1. Undercommitting to Tasks: Developers, wary of overpromising, tend to select fewer tasks than they can realistically handle. This cautious approach stems from a desire to ensure all tasks are "completed" by the sprint’s end, but it reduces overall throughput. As Parkinson’s Law suggests, work expands to fill the time available, meaning tasks often take longer than necessary simply because they’re constrained by the sprint’s artificial timeline.
2. Resistance to Interruptions: Sprints discourage handling unplanned work, such as fixing bugs reported by other teams or addressing customer issues. Developers, focused on their sprint goals, view these interruptions as threats to their deliverables. This creates friction between teams, slows down responses to critical issues, and ultimately harms the customer experience.
3. The "First Priority" Trap: As I discussed in my previous blog, the phrase "first priority" is often weaponized to justify ignoring broader team/company needs. In a sprint-based system, developers usually use this excuse to avoid collaborating with other teams or assisting colleagues, thereby further isolating efforts and reducing organizational efficiency.

These issues compound over time, leading to delayed projects, frustrated teams, and a culture where individual task completion takes precedence over collective success. There has to be a better way.

A New Model: Continuous Task Flow and Daily Releases

To address these challenges, I propose a new project management model that eliminates sprints, fosters collaboration, and aligns development with the organization's overall needs. Here’s how it works:

1. Continuous Task Pool: Instead of locking tasks into fixed sprints, maintain a prioritized pool of tasks that developers draw from continuously. Tasks are categorized by urgency and impact (e.g., customer-facing bugs, new features, technical debt, revenue generation). Developers select tasks based on their skills and the organization’s immediate needs, ensuring flexibility and responsiveness. This approach eliminates the artificial boundaries of sprints and encourages a steady flow of work. There is also no need to include time buffers.
2. Daily Releases (When Possible): Aim to release code to production daily, or as frequently as feasible. Daily releases enable QA teams to test and perform regression testing incrementally, catching issues early and reducing the risk of large, error-prone deployments. This aligns with the principles of Continuous Integration and Continuous Deployment (CI/CD), ensuring that code is always production-ready and customer feedback is incorporated quickly.
3. Prioritize Organizational Efficiency: Redefine a developer’s "first priority" as helping the organization function at its highest efficiency. This means assisting other teams with urgent bugs, mentoring colleagues, or addressing customer issues, even if it temporarily delays individual tasks. By fostering a culture of collaboration, teams break down silos and ensure that the entire development pipeline—from coding to deployment to support—runs smoothly.

Benefits of the Continuous Task Flow Model

This model offers several advantages over traditional sprint-based systems:

• Increased Throughput: Without sprint boundaries, developers work at a sustainable pace, selecting tasks that match their capacity and the organization’s needs. This reduces the tendency to undercommit and ensures more work is completed over time.
• Faster Issue Resolution: By prioritizing collaboration, teams respond to bugs and customer issues promptly, improving customer satisfaction and reducing bottlenecks across the organization.
• Improved Quality: Daily releases and incremental testing enable QA to identify issues early, increasing coverage and thereby reducing the likelihood of major defects slipping into production. Regression testing becomes a routine part of the process, rather than a last-minute scramble.
• Enhanced Team Cohesion: When developers prioritize helping others, silos dissolve, and teams work as a unified whole. This fosters a culture of mutual support and shared accountability.

Implementing the Model

Transitioning to a continuous task flow model requires careful planning and a cultural shift. Here are some steps to get started:

1. Set Up a Task Management System: Use a tool like Jira, Trello, or Linear to create a centralized task pool. Ensure tasks are clearly prioritized based on business needs and tagged with relevant metadata (e.g., urgency, team, skill set).
2. Establish a Release Cadence: Work with QA and DevOps to enable daily or near-daily releases. Invest in automated testing and CI/CD pipelines to streamline the process and minimize manual overhead.
3. Redefine Success Metrics: Move away from measuring individual task completion or sprint velocity. Instead, track organizational metrics like cycle time (from task start to production), bug resolution time, and customer satisfaction.
4. Foster a Collaborative Culture: Encourage developers to view interruptions as opportunities to contribute to the organization’s success. Reward team members who go above and beyond to help others, and celebrate collective achievements.
5. Iterate and Improve: Start with a pilot project to test the model. Gather feedback from developers, QA, and other stakeholders to refine the process over time.

The Continuous Task Flow

The continuous task flow model builds on the idea of removing the rigid structure of sprints and empowering developers to make dynamic decisions about what to work on next. It is also encouraging focused work on one task at a time, but remaining open to helping others when needed.

Conclusion

Sprints, while well-intentioned, often create inefficiencies that slow down development and fracture teams. By adopting a continuous task flow model with daily releases and a focus on organizational efficiency, we can create a more responsive, collaborative, and high-performing development process. This approach aligns with the realities of modern software development, where adaptability and teamwork are critical to success.

I’d love to hear your thoughts on this model. Have you experienced the downsides of sprints in your own work? What strategies have you used to improve development efficiency? Share your insights in the comments below, and let’s start a conversation about building better ways to deliver software.

Sub-Optimal A/B Testing - Why?

By: Alon Cohen Jan 14, 2018, updated: Dec 18, 2020

A/B testing is the primary tool marketing people use to optimize conversions in the digital marketing world. It’s a method to find the better converting version of a webpage or an ad.

The way A/B testing works is that you randomly present page A or page B to your website visitors and check which version of the page converts more visitors. Some tools (like https://www.optimizely.com) make that process relatively straightforward; however, it takes time to collect sufficient evidence to make a clear decision about which page performed better.

So why even bother?

The problem with webpage design is that it is hard to get it right the first time. A designer might think that the call to action button is in the way and move it to where it becomes ineffective. Color schemes and market trends affect how people perceive, understand, and operate a page.

Statistically significant results from an A/B test can help validate a webpage design assumptions and improve on them.

What can go wrong?

If, for instance, you did not assign a 50/50 impression between the A & B versions of the page, you might think that one page performs better. 

In many cases, unless one page is horrible, the other will perform pretty close to the first one, and the statistics can change week after week. You must wait a sufficiently long time, sometimes a few weeks, to get a decisive answer. 

Picking the wrong page will reduce your conversions.

Since you usually use multiple channels to target customers, changes in one medium might affect the A/B test results. Even though A/B testing could be helpful when your two pages are almost similar in performance, it usually takes a lot of work to get conclusive results, and ongoing testing is required.

So what is going on here?

Say you have used the best tools for A/B testing. You waited and got some slight statistical confirmation that one page is better. Why? Because one page was suitable for some people and the other was helpful for others.

The audience is not homogenous. When the results are close, half of the audience liked version A, and the second half liked version B. The sad product is that your bottom line stayed the same despite all your optimization efforts and patience.

Let’s say that 50% of the people like Red and half like Blue to explain it better. If you make the page Red, more red-liking people will convert. If you make the page Blue, more Blue liking people will convert. So it does not matter if the page is Red or Blue; conversions will not improve. 

Is there a solution?

Ideally, you need to have a different version of the webpage for each visitor or at least a separate page for various market segments or buyer personas. Only then could you see improvement in your total performance.

Unfortunately, I have yet to see helpful marketing tools that can tell you (the site) in real-time which version of the page to render to which user. The hope is that such a tool or an API will enable correct personalization of the webpages and drastically improve the conversion. 

It is not about knowing the visitor’s name. It is about understanding the visitor’s social or behavioral profile and displaying the correct page for each visitor’s characteristics.

In simple words, you need a way to show red-loving people the red page and the blue-loving people the blue page. This way, you can improve the total conversions and move from a "local" maximum on the optimization graph to a more "global" sales process optimization.

 

Thoughts?

Have you heard of such a tool or an API? Let me know.

Corona - Silver Lining?

By: Alon Cohen

We are social distancing and working from home. We learned that it is possible to live and work that way, maybe even work more efficiently as we spend less time on social gatherings and save the daily commute. As one who worked from home for many years, I can say that it works even better when everyone is working from home.  

From the technology perspective, people finally discovered video conferencing and learned how to use it better with the benefits and the few problems it presents. Many even learned the importance of good lighting and an impressive backdrop.

Engineered or not, the virus highlighted the upcoming international battlefield. I wish these were not needed, but I hope that we will have an increase in the research budget for developing protections against such biological weapons. As a by-product, I hope it will help find cures for health problems that plague our society.

We suddenly discovered that developing Vaccines should not take ages. Hence the cost of development “as it usually takes ten years” being the usual excuse of the pharmaceutical companies will no longer be valid. 

Pharmaceutical companies need to stop wasting time searching mostly for medications to sustain life. They rather find ways to actually cure or prevent diseases using vaccines, regenerative medicine, and genetic-medicines. 

Given the ability of those genetic technologies to cause disasters on a global scale, it might be necessary for nations to own the IP (Intellectual Property) for drugs and vaccines by financing and directing the research. 

That emphasis should be on finding cures for diseases. A cure by its nature is a less lucrative outcome for the pharmaceutical companies because once they find a cure, the disease could be vastly eradicated. 

By directing and financing biological research, governments can legally leverage that new IP in the upcoming biological warfare.

Interestingly we may have created and proven a new business model where Phramacustical companies get paid a lump sum for a product that prevents disease, a vaccine. (Operation Warp Speed)

Maybe we can extend this model, and regulate pharma so that if they want to sell us non-generic drugs, they must introduce at least one preventative or curing medication per year (as opposed to life-sustaining medicines). Once they present such a cure, the pharmaceutical companies will get paid handsomely, upfront, because it will be worthwhile for the economy to get those newly cured, healthy people, back into the workforce.

We also learned that volunteers are willing to test new vaccines to save lives to help test them faster or as they call it one day sooner. Those people are heroes in my book.

I think we learned that as a nation, we must invest more in quantum computing as it holds the future for faster material and medicine research that would otherwise take years to achieve with standard computers.

I think we realize that when the doctor says, “you contracted a virus, there is nothing we can do...”, he is probably wrong. 

With the correct focus, we can defeat viruses from Herpes to the Common Cold, maybe even Influenza. By doing so, we contribute to the economy vast amounts of money that today is being wasted on hospitalizations and lost workdays. 

We used to say that trains, then the aviation, then the Internet made the world smaller, we now realize that infectious viruses make it even smaller. A Virus does not require infrastructure or energy to travel - just abondance of people. 

Internet communication can be blocked, intercepted, manipulated, and fire-walled. The Coronavirus showed us that viruses could jump any border and if we embed data in the virus DNA we can pass information in a direct person to person manner in a way that might be intercepted but not blocked or censored.

It means that a virus can be useful as a communication chanel. A virus can be “developed” as a data carrier. We can use the virus to broadcast information with, hopefully, positive ideas, maybe even a complete version of uncensored Wikipedia, and use them to circumvent even the “Great Wall of China” or thair firewall in today's term.

###

From Hardware to Serveless

By: Alon Cohen, Phone.com EVP/CTO, Sep 3, 2018

(As published on XplorExit.com)

Amazon AWS, Google Cloud, and others are now chasing each other to see who will win the Serverless revolution. Amazon calls it Lambda Functions, Google named theirs Google Cloud Functions, and Microsoft calls it simply Functions. The generic name is Serverless Architecture.

The idea is simple to understand: instead of buying a physical server and placing it in the data center, or buying a virtual server instance, configuring the server, installing the needed software and hoping that it will hold the expected load, a developer can now split the traditional monolithic code to a defined set of business logic tasks that can be invoked by a URL, and invoke those tasks as many times as the application requires without thinking about scale, load balancing, networking aspects and more.

It sounds simple, and it is, once you get the hang of the Dashboard provided by Google or Amazon to manage, monitor and define the proper components you need in your solution, and the component access rights. When the configuration is done, all you need to think about is how to break the monolithic process you had in the past to a nimble set of small tasks.

In fact, there are few programming paradigms that you need to leave behind in order to take full advantage of this new architecture.

In the past developers used to build large data objects to hide information from other tasks and yet provide unified access to the object state and properties. This approach in most cases dictates a large monolithic application with nested data structures that are hard to maintain, requires long release cycles and long regression testing. Every change you make affects large parts of the program and requires you to go through rigorous version management and re-tests.

To mitigate some of the above issues, people built a service-oriented architecture where different layers abstract different functions and allow the developers to make changes in one layer without affecting other layers. However this approach, as clean as it might be, still keeps the dependency of each layer on the other layers and so a change in one layer requires a unit test but also yet again requires the QA to go through a full regression testing of the whole system prior to every release. All of that translates to long release cycles.

Serverless for the open-minded opened up new opportunities. You still want to make sure you write a service once, but if you work correctly you can remove the global dependency of the code on a version of any specific function. In other words, in the monolithic architecture when you change a function, that change also affects every part of the code that calls that function, object or service. That dependency is the key problem. So how can we change that?

Instead of creating abstraction layers or services that depend on other services, you create a shared library of global functions. And here’s the key: when you pack a Serverless Task you include the latest version of the shared library code, test that small Task, and deploy. None of the other serverless Tasks that are running and using that Shared Code are affected. The other Tasks are using the version of the function code they were tested with. In fact, they do not even have to be taken down as you update other Tasks. Most likely, if you built it correctly, a Task will be completely independent of any other Task in the system.

If you adhere to that flat architecture, you will now enjoy rapid bug fixing. You will have a very small blast area, meaning that a bug in a newly updated Task affects only the availability of that Tasks and may not disrupt any other Tasks in the system. You also do not need to maintain a Master Branch for the whole app, but rather manage each Task version independently. Since the program is split into small Tasks, there is very little need in merging code managed by a few people. Most Tasks are written by a single person. And, by maintaining a good set of Code Style conventions in the organization all developers are now fungible, meaning any developer can understand and fix other developers’ code.

How much does it cost?

At Phone.com we used to handle call events in our Core API in a traditional data center. We needed about four instances and two load balancers between the API service layers, to support a barrage of call state events coming from our telephony servers, millions per day. Once we moved the event handling to our serverless environment, where you pay on a per Task invocation, we reduce the cost by a factor of 10.

Amazon AWS also offers a serverless database called Aurora, which is still in Beta. I cannot wait to see how they price that in comparison to other database options. In the instance-based architecture, one will pay about $70 per month for the smallest database instance before data has even started collecting.

There are more interesting aspects that contribute to system stability in case of a crash. If a Task crashes it affects only that Task, the next request will launch a new instance of that Task and will run the Task again.

Is it Secure?

Security aspects are handled by creating a Virtual Private Cloud isolated from the outside. By using an API Gateway module, you allow public access to specific functions. The API gateway lets you define your own authentication and authorization mechanism.

Additional Gains

Instead of Cron jobs, you can now tell a function to start at given intervals. If you need to run a large report that normally takes a long time to generate, you can create a recursive structure where you split the report to hundreds of small segments each one spawning the same Task all running in parallel. As the Tasks finish they aggregate the report segments back to one large report. All that happens in seconds without the need to consider scalability aspects. An overnight type report is now being produced in seconds.

Once a function finishes it lingers a bit, for free, to allow for faster start time and if not invoked for a while they just die and release AWS resources.

Reduce OPS overhead.

Source: https://specify.io/concepts/serverless-baas-faas

Phone.com is still in the midst of that transformation, however, we have already harvested the benefits in the form of happy customers sending our employees huge edible arrangements of fruits and thank-you letters of appreciation for the quick turnaround off almost any request they come up with.

###