“There’s always been this kind of unwritten rule at Basecamp that the company basically exists for David and Jason’s enjoyment,”
This quote from the last paragraph of this article . Changing context from the one the article was written in to talk about Shape Up.
I think this is one of the biggest challenges we are trying to reconcile with Shape Up. First, I think Shape Up is working for us. Second, this challenge is a hard one.
Shape Up helps us ensure we are all aligned on the highest value strategic work. However, despite best intentions, the impact of some of the systemic forces of a “Betting Table” lure team members into perceptions/mindsets like the one stated above.
We have attempted to find the right balance of multi-cycle decisions being made clear in Shapes and at the Betting Table. Leaving in-cycle decisions to the team.
Probably worth noting that this quote comes from a disgruntled employee, so I’m sure there are other factors at play here. And by itself, I’m not sure it helps much to understand the struggle your team is having.
Could you add some more detail for us? When people have raised issues, what are they saying is the problem? Do they feel the projects are overly prescriptive and don’t allow enough freedom to make necessary judgment calls within the cycle? I’ve found the degree of prescriptiveness needs to be intentionally tuned to the particular project and the team working on it. Maybe the shapers are being too specific in how the builders are supposed to implement it, and it’s cutting against the builders sense of their own abilities.
If the problem is more strategic (e.g. “we don’t think these projects are what the company should be doing”), then that’s a different problem entirely.
Would be helpful to know the actual struggle your team members seem to be facing.
It’s not really a specific issue. It’s the overall mindset that is forming – an “us” vs “them”. We aim to align everyone around delivering customer value as empowered product teams.
It’s a good point about trying to tune this to each project and team – or even individual team members (as we have some jr team members too).
I could’ve better outlined my challenge as Shape Up forces us to work in Project mode. Even if we have Product Teams. I’m hoping to combine Shape Up’s benefits with the benefits of empowered Product Teams.
For some definitions of project vs product (for anyone interested):
What hit me with the quote was that is similar to some background conversations I’ve surfaced that are saying the same thing about how the betting table works in general – it’s disempowering for shaping teams and building teams.
For shapers, they have to make sure what they shape are projects that will pass the betting table.
For builders, they are feeling rushed or pressured to cut too much scope. Because we ultimately want to ship some piece of value at the end of cycle.
For both groups, the biggest loss ends up being that everything being cycle-length has allowed us to keep changing direction. Every two months there’s new strategy/logic. This strategy logic is sound and agreed upon. But it’s just too much change for anyone to really get into for themselves before the next cycle.
Ah, yes. I remember reading the first article and the predecessor to the second article (Article: Product vs Feature Teams : Silicon Valley Product Group) a few years ago. “Product-mode” is pretty close to how I run my own side projects, and I can see how it would work well for a very small company where people need to wear lots of hats. If the team includes enough polymaths and the business can support dedicated product teams, this does seem like an awesome way to work.
The difference between these modes of working ultimately seems to be the level of autonomy and responsibility that are expected of the build teams, and which one is appropriate is going to be different from one company to the next.
In my mind, Shape Up helps solve a problem that my team used to have and that I’ve seen rampant in my corners of the software world: there’s a manager/product owner/scrum master who takes requests to change the product, comes up with an overly specified solution themselves, and divvies up the work into concrete tasks that they hand out to their developers. Developers do exactly the work specified in the task, commit it, and pluck the next one off the backlog.
In this context, Shape Up does a tremendous amount to empower teams. They don’t have the responsibility to come up with the entire solution themselves, but they do have wide latitude on how to implement the solution. Shape Up draws a clear boundary between product strategy (i.e. what do we build and when do we build it) and building.
Even greater autonomy would require the teams to be responsible for product strategy as well, and I’m sure that works well for some teams. But it’s worth noting that not every team of developers even wants that level of responsibility.
What struggle was your team experiencing that you were hoping Shape Up would solve?
Sure, that makes sense. What’s behind the complaint here? Are there too many shapers compared to the number of projects that get selected for each cycle? Are none of the shapers also involved in deciding what gets selected?
Are the projects too ambitious to actually be accomplished in the cycle? Or do the shapers get too prescriptive with implementation details, leaving the build teams feeling like they don’t actually have the freedom to make the necessary judgement calls to do what’s necessary to ship on time?
Can you tell me more about this? I’m not sure I totally follow the problem here. You don’t have to change strategy every cycle. If that’s not working for your business, just don’t do it.