Ryan writes that a small team doesn’t often need full fledges cycles and when there are just 2-3 people, you can shape for few days, work for some time and repeat - Adjust to Your Size | Shape Up
What happens when you start growing to some 4-7 or even 10 developers team size?
My understanding is that it is already a point where having fixed sizes and schedules is already helpful (so that you don’t run around in a rush when every few days some project finishes-starts) and how do you separate Shapers and Builders at this point?
I imagine that lead developer(s) wouldn’t be happy just doing Shaping and research for the whole cycle and there might be no need to spend that much on Shaping. What do you do then?
Do you still separate the Shapers as there is always something to shape?
Or do you let people build stuff and pull them to shaping once in a while (and shaping might need a couple of days for some proof of concept)? Even if it means they loose focus on the projects they were building?
From my experience, this ends up being a natural process depending on the individuals on the team.
I think you alluded to this by saying that the lead developer might not like to spend a significant amount of time shaping, and might have an inclination to another kind of work.
The second option you presented seems like a good default. The only caveat here is that you should continually monitor this, and make changes based on two possible things:
If someone shows enthusiasm and/or is very good at shaping, it might be worthwhile to separate them from the cycle and to give them some more room to see if they can improve even more
If taking people out of the building cycle is truly disruptive (performance is down or people complain) THEN it might be more reasonable to start separating the two kinds of work.
In my opinion, it’s always good to let systems and patterns emerge organically. Even if we think we know a certain “way of working” would be better for the team, it’s harder to impose that top-down, rather than nudge it carefully into existence by trial and error.
We are experiencing this, one person (developer) of the team started think more about the product and wanted to start shaping.
My approach was to ask them to write 3 major problems or ideas he wanted to pitch, after that I told him what I suspected would provide more value to the users, and he started to write a pitch.
I totally would go for the organic way, some other person in fact wanted to attack more reactive work than work on pitched projects.