At Integral we work in one-week cycles, deploying every Thursday evening and planning the next cycle on Friday morning. This rhythm keeps our small team synchronized without meetings consuming our lives.
Most teams either plan constantly (daily standups, sprint planning, backlog grooming) or seldomly plan (just grab tickets and build). Both approaches fail for small teams that need to move fast.
What actually happens
Without consistent cycles, teams drift between reactive and proactive work. Monday you’re fixing bugs. Tuesday you’re building a new feature. Wednesday the CEO has an urgent request. Thursday you’re still working on Monday’s bug.
Nothing gets finished. Everything feels urgent. Progress is hard to measure because you’re always switching between different types of work.
Planning-heavy teams spend 20% of their time in meetings about the work. But small teams can’t afford that overhead when everyone’s hands-on building.
Why weekly cycles work
Weekly cycles are short enough to adjust quickly but long enough to make real progress. You can finish meaningful features in a week. You can’t lose focus for more than four days.
Deploying every week creates natural deadlines without the artificial pressure of arbitrary sprint boundaries. If something isn’t ready by Thursday, it waits until the next week (or gets hotfixed the next day)— no drama, no exceptions, no weekend heroics.
Friday planning happens when the previous week’s work is fresh in everyone’s mind. You know what shipped, what was blocked, and what requires attention for the next cycle.
Our weekly rhythm
Thursday evening: Deploy what’s ready. Everything gets tested and released while the team is online to catch issues.
Friday morning: Plan the next cycle. Review what shipped, identify what broke, assign the Guardian and Captain roles, align on upcoming priorities.
Monday-Wednesday: Build mode. Deep work on features, only necessary meetings, execute the plans.
Thursday morning: Deploy preparation. Code review, testing, documentation, deploy checklist. A quick internal demo for the Product & Tech team.
Thursday afternoon: Demo to the whole company, focusing on the features being shipped. Deploy to production, watch for issues, document what went live.
This rhythm works because each day has a clear mode directing focus and maintaining momentum.
What gets planned
We don’t plan sprints or estimate story points. We plan outcomes:
What ships this week: Specific features or fixes that will go live Thursday. Definition of done, as clear as it can be.
Who owns what: Guardian handles interruptions and bugs. The Captain drives the biggest features forward. Everyone is aligned.
What doesn’t ship: We explicitly defer work that isn’t ready. We believe it’s better to cut than commit to scope you can’t deliver.
Blockers and dependencies: What might stop you? What do you need from other people? What external factors could affect the plan?
When cycles break
Sometimes we have weeks with no meaningful deployment. That’s fine; not every week produces customer-facing features.
Sometimes emergencies require mid-week deployments. We deploy the fix, then get back to the regular rhythm.
Sometimes planning reveals you need two weeks for a feature. Plan for two weeks, but deploy a chunk on Thursday (even if it’s infrastructure or bug fixes).
Most of the time, when a small feature is ready and tested, it is shipped to production.
The result
Everyone knows what they’re working on and when it needs to ship. Deploys happen predictably instead of whenever someone remembers. Planning is lightweight but consistent.
Your team develops rhythm instead of thrashing between urgent requests and random features.
Consistency beats perfection. Weekly cycles aren’t optimal for every situation, but they work for most situations and they’re easy to execute.