Nicolas Cava

Ship work in a sane way on six-week cycles

Ship work in a sane way on six-week cycles

Photo by Quino Al on Unsplash

Hey guys. This time, I want to introduce you to a sane and straightforward approach to product development build around six-week cycles separated by two-week cool-down periods. This entire methodology is inspired by Basecamp techniques. I hope you find it worthwhile for your time.

I describe an approach that can work very well with any company typologies, especially with those convinced by the virtues of asynchronous collaboration.

Six-week cycles and two-week cool-downs

Before entering a six-week cycle, projects have to be shaped to ensure the efficiency of these techniques. To give context, consider a small senior group of people who define a solution's key elements. They have to be concrete enough yet abstract enough that team members have room to work out the details. However, consider that the art of shaping will be dug down in another article. We will solely focus on the concept of cycles for now.

Cycles are long enough to do meaningful work from start to end. The complexity lies in being short enough to feel the deadline to let team members use the time wisely.

Most of the time, features are built and released in one cycle. Micromanagement has to be avoided at all costs (in general, but especially here), so don't count hours or ask how individual days are spent. Trust people into giving their best to put the solution in action.

Do not enforce daily meetings for status reports, and do not rethink the roadmap every two weeks. Six-week cycles have to be untouched. You commit to it for a given project and leave the team alone, entirely focused, and never disrupted.

Committing time and people is difficult if we can't promptly determine who's available and for how long. Working in cycles simplifies this problem. Cycles give project sizes both for shaping and scheduling.

Like in Scrum, two weeks is too short to get anything meaningful done, in my opinion, and are too costly due to the planning overhead. People have to regroup at the end of each cycle, which breaks everyone's momentum, and that's not worth it.

Scoping cycles using deadlines

Team members will make trade-offs when they feel a deadline approaching. When the deadline is abstract or too distant, teams will naturally wander and use time carelessly. Although deadlines are notoriously associated with putting a lot of pressure on teams. Is not that wrong?

I agree with the stress factor provided by typical deadlines. Still, people feel overwhelmed by stress when they perceive that they will be consequences through criticism or punishment if the deadline trespasses. Deadlines are a truly perverse tool used to put employees on overcapacity during a significant period, urging them to work at an abnormal pace. This leads to stress. If companies routinely use it this way, they attempt to counterbalance a problem rooted in their essence, which's bad for everyone. If you run on deadlines, you have to let people hammer project scopes; if not, they will feel trapped in an untenable position.

Deadlines that I speak of are not there to trick employees, and you have to be definite about it. They are employed to timebox investments in ideas and projects. Promote a culture of forgiveness, and team members will consider deadlines as part of the project scope; thus, they will uncover ways to fit into this scope by themselves. Suppose they fail to respect the time scope. In that case, that's ok. Deadlines exist to limit the expense, and the project will be cut off or betted into another cycle (if we think it's worth it). They will learn and discover better ways next time. If not, it's perhaps a performance concern, and you will find a solution collectively.

Take advantage of cool-downs to breathe

On a cool-down stage, time to breathe and think about what's next. The end of a cycle is the worst time to meet and plan because everybody is too engaged in finishing projects and making last-minute judgments to ship on time.

Cool-down is a space with no scheduled task where we can recuperate, meet as needed, and examine what to do next. Programmers and designers on project teams are free to work on whatever they want. They enjoy having a time that's under their charge. They use it to fix bugs, explore new ideas, or try out new technical opportunities.

What's next?

We just saw how valuable are six-week cycles and two-week cool-downs, how deadlines are a useful tool when rightly used, and how cool-downs are there to get our minds back on track.

But what about shaping projects? How do we venture on a project before opening a cycle? What about team sizes to tackle these cycles?

I recommend following me on Twitter to find out how I explore these themes in detail.

See you guys,


Go back to the home