One thing that is recommended in Shape Up is that each mini-project should not have external dependencies for the team to be “in control of their destiny”. I feel that Basecamp is solving that mainly by keeping the company small.
But imagine that you would use Shape Up in bigger companies that work on some huge products like Gmail, Slack, or software for Tesla. You have tens of teams that are working on the same product. Obviously, the dependencies between teams are way more often, and orchestration of all teams is harder.
So, I would be curious if there are some concrete tips & practices for such an environment or at least principles that would help you to use Shape Up on this larger scale.
I feel that the 6-week cycles actually help because you have at least a given timeline for the teams when will who deliver what. But I think that the shaping phase should be much more oriented on discussing those dependencies across different teams. Also, I know that @rjs doesn’t like Product Managers, which I get, but I feel that their main job on products of that scale should be exactly dealing with those dependencies and untangle them. Which is easy to say, very hard to do…
Anyway, I would be interested in any ideas, tips, principles to follow…
I was thinking a little about this. In our case, some of the bets are straight off the table, because our data infrastructure is huge. I don’t know how to define these features in a way that will work with 6w cycle, maybe I am somehow keeping wrong angle on this.
On other hand, for features build on top of the big data we already have, I’d try a value stream approach. We already do that in Scrum, having teams aligned by value stream make the discussions about features easier, because the use case is well known and the team understand persona they are developing the features for.
I’ll try that in our company and write some update here. On sidenote: @janmikula - not sure how technical your product people are, but we had a problem with product people untangling dependencies, as they don’t understand the inner work of their product well (nor they are supposed to). We leave that on developers now and it works better in our case.
Yeah, in our case it depends. Some PMs are very technical, some have minimum technical knowledge. Especially for those cases, I think it’s very important to use the cool-down for PMs to consult things with devs and maybe devs should do some initial technical exploration, and then they should participate in creating the pitch.
Dependencies are a design problem, not an organization or scale problem. Orthogonality (the opposite of dependency) is something that technical people consciously build into the design. Software people call this “separation of concerns.”
I’ve seen companies smaller than Basecamp with 10x as many dependency problems.
Product Managers aren’t the ones to fix it. They can just work around existing dependency problems by trying to align people. The deeper fix happens when the technical leadership, the people who actually design how the stuff works and is built, make trade-offs to increase orthogonality.