Shape Up Forum

Value of Integrated Scopes (in R&D and elsewhere)

We’re reaching a debate on our team on the value of integrated scopes.

Product Managers (who are the strategists and shapers in our org) believe that working in integrated scopes actually slows the team down in the long run and aren’t feasible in practice.

Any individual engineer on the team generally also prefers to NOT work in integrated scopes (our engineers largely divide into frontend/client/mobile engineers and backend engineers).

However, my head of engineering is totally bought in on integrated scopes, as am I (head of product).

The main sticking point is this: how important is shipping in integrated scopes in R&D mode? Does this philosophy hold the most value in production modes? For instance, did you strive to ship integrated slices as you worked in the R&D phase of HEY @rjs ? What if an entirely new backend architecture is required to build the new feature(s)?

Can you define “integrated scope” for us @levinelson ? I’m not sure if you’re referring to Integrate One Slice and the importance of that methodology or something else?

Yep, that’s it. The idea of moving with frontend+backend+design together on discrete chunks of work, vs all the backend engineers working on backend, all the client engineers working on frontend, and gluing it together at the end.

I’m especially curious on those long R&D multi-cycle type projects with LOTS of backend work. Should the backend engineers be thinking of architecting the whole system, or focusing on delivering integrated slices alongside their client/design counterparts?

Okay that’s what I thought. I have a couple of thoughts on this that are kind of broad reaching so apologies if the organization isn’t great.

The multi-cycle type projects with LOTS of backend work is alluding to at least one difference between your company and Basecamp which might require your approach to be adapted. They have a philosophy of monolithic, html-over-the-wire application architecture on Rails, which I’m guessing you don’t have. So Integrate One Slice, in a practical sense for many of their cases, probably means implementing the smallest model change + smallest controller change + smallest view change that equals something new working, and repeat. Specifically, as an engineer is going to be able to make some progress on a specific slice at the same time a designer is discovering options for the final front end deliverable.

I think what makes sense here is to figure out a better definition of your slice. Here’s an example from one of our products. It consists of a web application that handles some administrative tasks and an electron application that is more “user centric”. We’ll sometimes do a project that touches both applications. Integrating slices in this case, because of the actual separation of concerns in the different applications, might mean that one engineer takes a scope slicing up the work related to the web app, and one engineer takes a scope sliced only on the electron app.

One final contrast, at least for us, you said backend engineers, we specifically avoid a situation where engineers become specialized. One of the reasons my team specifically is encouraged to follow the slicing methodology is because it gives everyone experience with everything and doesn’t pigeon hole them into a specialty.

All that to say, it’s definitely possible that you’ll need to adapt your definition of slice to the actual context of your products.

There’s something to be said about “R&D Mode” and “Shape Up”. Shape Up is about shipping work at the end of a fixed time variable scope project. In order for Shape Up to be valuable in R&D Mode, you have to decide what it means to ship work, and whether your analogy is getting you the feedback you need in order to continue shaping and iterating.

If you don’t have any customers you’re not iterating, you’re just building!

Okay, theory aside (but not speculation), my default opinion with more context on the product, short term goals, and business strategy is going to be that you and the head of engineering are right. My bet is that the engineering teams don’t like that approach because they’re already pigeonholed into specialty roles and hearing about working on all the things is scary.

For mobile and backend the generalized software engineering role is sometimes not practical. Assuming backend means “APIs”, I’d consider shaping backend work as if the mobile team is the customer. So integrated slices will still mean shipping something to the mobile team. The mobile team then shouldn’t be working on projects that depend on the backend work of the same cycle since they’re dependent on API work.

Sorry for rambling, interesting dilemma!

Thanks Justin! It’d helpful to remember that yeah, Basecamp is a monolith which makes integrated scopes a bit easier. We’ve got a Rails backend that largely drives a React.js and React Native front-end.