Shorter cycle lengths? Variable cycle lengths?

:wave:

I’m curious if anyone is doing shorter cycle lengths than six weeks?

The Adjust to Your Size appendix says:

Six weeks might not be the exact time frame for your team.

We’re a small(ish) startup with five engineers and one designer. For our first cycle, none of the pitches had an appetite of more than three weeks, so we decided to make our cycle length three weeks with a one week cool-down.

That feels right for this first cycle, but I also feel like it boxes us into an almost-sprint-like time frame. What if we have a legitimate six week appetite for a project in the future – do we adjust the length of each cycle as necessary?

We used to do 3 weeks with 1 week cooldown (this was due to the CEO wanting to “go fast”) and ran into the exact issue you are worrying about. Bigger projects simply don’t work in this cadence and then the cooldown actually gets in the way.

Also, for the product team, we found this still wasn’t giving us enough time to do discovery/shaping of more meaningful work.

Just because you have a 6 week cycle, doesn’t mean you always have to have projects with a 6 week appetite. You could fill the 6 week cycle with multiple 3 week projects. But at least then you’ve got opportunities for bigger things in the future, and you’re giving your shapers more space/time to work/think. Good luck :slight_smile:

1 Like

Thanks for your input, Aylon! You bring up some good points.

That’s what we’ve done even at three weeks – we have five projects ranging from three days to three weeks. At first, when we were still thinking of doing a six week cycle, we had 12 projects (!), which felt overwhelming. Do we slice them all up at once at the beginning, or do one-at-a-time? And how do we coordinate resources so no one is blocked? It just didn’t feel right. Five projects in three weeks felt more manageable, which is why we went with that.

But maybe we’re just thinking about this wrong either way?

We’re facing them same thing, @jstayton. It feels like the projects we have are just too small, and if we set aside a whole 6 weeks, we’re gonna have to fill it with a dozen small projects of various sizes. At that point it’s just a grab-bag, and I’ve been down that road before.

It seems like this is an upstream problem, that we need come up with more substantial projects before we even get to the shaping stage. So I’m not sure it’s something Shape Up itself can solve.

Is this where Jobs to be Done comes in, @rjs?

It seems like this is an upstream problem, that we need come up with more substantial projects before we even get to the shaping stage.

Shape Up with the six week cycles is designed to help make progress on substantial projects. If you only have small things to do all the time, and you don’t have any trouble shipping those, then some other approach would probably work fine, like a kanban or ticket-based system.

My question would be what kind of progress you are trying to make on the product and whether you are trying to accomplish bigger changes, from the leadership level.

If you feel like bigger changes are needed but don’t know what they are, then yes Jobs To Be Done is a good flashlight to use to look around in the dark. Then with more clarity on where people are struggling you can frame meaningful projects.

2 Likes