Distribute features by executing in cycles
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.
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.
- Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer
A question? Let's connect.
Follow me on LinkedIn for daily strategies on SaaS, technology, remote work, and leadership. Send a DM if you have a question.
We can also enjoy a virtual coffee to get to know each other, talk about your challenges, and see how I can help.
Or if you prefer, you can ask my anything by email.
Recent publications on all platforms. Follow me on LinkedIn.
Who am I—a story on personal growth
I always been attracted by the concept of personal growth: getting to know yourself and working on it to reach your full potential.
Distribute features by executing in cycles
A straightforward product development approach builds around six-week cycles separated by two-week cool-down periods inspired by Basecamp techniques.
Building trust early with an introduction letter to my teams
A very honest attempt to be more transparent about me to quickly build trust with my teams.
Why I advocate working from anywhere
The story of how I came to advocate remote work and swore to solve its challenges as an entrepreneur through the prism of my recent family history and origins.
I decided to pivot my business
The world is crumbling under exponential complexity diverting and consuming people's attention for the worse and generating tons of process waste. A story on why I pivot my business.
The handbook-first approach
Remote teams must consolidate tribal knowledge into documentation. To solve this let me introduce you to the handbook-first approach.
Efficient remote engineering onboarding done in 6 months
When hiring in remote engineering teams having a cohesive plan for onboarding new hires sets a great start and gives all the information they need to perform well.
How to master asynchronous work
Asynchronous work is when collaboration is not done in real-time. Simply put it is when you send a message without expecting an immediate response.