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.
Let's discuss building better companies.
You have better chances of finding me active on Twitter. I tweet about leadership, remote work, software engineering, personal growth, and systems. I also build my company publicly.
I'm also active on LinkedIn, where I post longer thoughts.
You can also contact me by email.
The handbook-first approach
Distributed teams must consolidate tribal knowledge into documentation. To solve this, let me introduce you to the handbook-first approach.
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.
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.
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.
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.
A system attempt for startup studios
One of the greatest force of a startup studio is the powerful intellectual property (IP) that it owns, which unlock startup scalability potential, engineer and customer high-quality experiences, and massive business technological strike capacities.