DEV Community

Weekly Dev Tips

Sprints Versus Continuous Flow

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.

This is episode 41, in which I'll talk about the difference between sprint and iteration-based software processes compared to continuous processes.

If you’re enjoying these tips, please subscribe in your app. You can leave a rating and better yet, a comment in your app, too. I also accept subscriptions to @WeeklyDevTips on twitter and comments and requests for topics there or in the show comments, too. Thanks for all of your support!

Sprints Versus Continuous Flow

Sprint and iteration-based processes are stepping stones on the path from waterfall toward continuous flow. In this episode we'll make some comparisons to build and integration processes to demonstrate this.

Sponsor - devBetter Group Career Coaching for Developers

If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. devBetter is a small group of motivated developers meeting every week or two, and staying connected in the meantime via a private Slack community. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com.

Show Notes / Transcript

I've been a fan of continuous integration, or CI, for many years. When I was first getting started in professional software development, CI was still new and unproven. Some of my first consulting engagements had me working on teams where there was a team member who was the designated integrator. Their job was to understand how to put all the components of the application together so that the app could be deployed. This was a major ordeal every couple of months when a deployment needed to be made.

In the 1990s, automated builds started to become increasingly popular. Tools like Ant, and later in .NET NAnt, were growing in popularity. Automated builds started to enable periodic scheduled integrations. Instead of having someone manually integrate and deploy the system every few months, these automated tools enabled weekly integrations, providing much more rapid feedback. Eventually, the frequency of these builds increased from weekly to daily (or more typically, nightly), and finally to the extreme of continuous integration. Continuous integration builds and tests the application every time a change is made to the application's source control.

It's hard to get much better than continuous integration, but there are still a couple of nice features that can and have been added. Today, I most of my projects use continuous integration, but continuous integration by itself doesn't prevent developers from breaking the build by checking in broken stuff to the main branch. Two features that tools like Azure DevOps and GitHub support now are the ability to run builds on pull requests and the ability to restrict merging pull requests so that they require a passing build before they can be pulled in. Adding in these two features eliminates the vast majority of broken build scenarios, ensuring the main branch of the application remains in a working state at all times.

So, what does this have to do with sprints? Before we had XP iterations and Scrum sprints, most software development used some kind of waterfall-like process. Iterations, such as they were, were quite long: months and sometimes years. Iterative development approaches popularized by agile software development recommended much shorter iterations, with many developer organizations shifting to 2- or 4-week iterations. Each iteration, the team would estimate the backlog, prioritize the work, plan out the iteration or sprint, commit to the plan, get work done, test it, try to deploy it, and potentially hold a retrospective about the iteration. It's not uncommon to look at iteration-based agile and compare it to a series of mini-waterfalls. The analogy from infrequent deployments to more frequent integrations is an easy one to see.

So, with integrations, there's an obvious spectrum of increased benefit associated with increased frequency. There aren't many dissenting voices crying out that continuous integration is a waste of time and we should only build software once a month. The feedback benefits of CI over even daily builds is quite clear. So, if you see a certain amount of benefit when going from long-term waterfall delivery to 4-week iterative delivery, it should be obvious that this benefit will increase further if you go from 4-week to 2-week. But most teams stop there. The reason why most teams never shorten their iterations below 2-week sprints is because of the pain involved in some of the required ceremonies that are tied to the sprint. I literally saw this happen last week, when a client initially planned on 1-week sprints but dropped back to 2-week sprints because there were too many meetings to make 1-week sprints work.

The issue is that the ceremonies eat into time to actually get work done. For instance, a reasonable retrospective probably takes an hour. Investing an hour every 2 weeks may seem reasonable, but what about every week, or every day? Estimating and prioritizing the backlog is a similarly painful part of most sprint plans - would it make sense to do it more often? This may sound crazy if you didn't listen to last week's episode yet, but give it some thought.

Here's the thing - these ceremonies aren't strictly tied to delivering software. You could increase or decrease your sprint cadence, and still have monthly retrospectives. The same is true for prioritizing work. You can still do it every two weeks while your sprints are one week long, if you want. You can even do it literally just-in-time as things are pulled from the backlog. Imagine how quick sprint planning sessions would be if they only had to choose the next item the dev team would start working on? You could do that 10 times a day with an email exchange if the product owner made it a priority.

Once you realize that really long iterations, like traditional waterfall, are not great, and shorter iterations are better, you should be able to make the jump to continuous flow pretty easily. If there are things that make this too painful, then listen to the last episode, and do those things more often. Or, realize they're not in the critical path to delivering software, and stop tying them to your software delivery cadence and schedule them on whatever cadence makes sense for your team.

Show Resources and Links

That’s it for this week. Next week we have a special guest as Robert "Uncle Bob" Martin will provide a couple of tips - be sure to check back for that. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Episode source