Project-based cells

Ticket to log time: SE-4874

When I mentioned fluid cells, I was thinking in terms of how I’ve seen other consulting shops (IBM, Accenture, etc) do it. Roughly speaking, you don’t join cells - you join projects. And for the duration of the project, that’s all you focus on. (In those companies it’s horrible projects like SAP customization, but you get the picture.) The overhead is only as big as that particular project itself.

What happens when the project is over? You sign up for (or are transferred to) another one.

To try and translate this into OpenCraft terminology, this would mean that instead of joining cells, we’d join epics. Total, 100% focus on one client and/or project. No firefighting things you have little context in. No distractions, a lot less context switching. And if the project ends and there’s no new one available immediately? No sweat: join one of the accelerated epics.

The thing is… this would work well for large(ish) epics, probably not so much for small ones. We’d likely have to ditch small customers altogether - which may or may not be financially feasible. (That it works for IBM does not mean it’s possible for us.) We’d also have to ditch sustainability per cell - likely the cell concept altogether.

Anyway, just a thought.


Having both very big and very small epics can be a problem. But we can usually solve it by grouping what would be smaller epics together into a single epic, like SE-1693 Small Projects & Customizations or SE-1690 Hosted Sites Maintenance.

That could work. Though I’d give that epic (project, cell, group, whatever we’d call it) the whole of Ocim, minus (as SE-1690 itself says), customization/consulting work.

It would be a nice solution for Ocim/Grove, IMHO. You get a team that’s always working on it, fixing issues and moving the platform forward regardless of cell sustainability. The only question would be how many people would be working on it at any given time - which would probably be dictated by company sustainability.

@adolfo It’s an interesting idea. It sounds appealing, but it also raises a lot of questions about how this would work, exactly. There would still be needs for things like firefighting rotations, vacation coverage, etc. Wouldn’t that result in “project cells” that are too small?

The best would be to try to dig into the idea concretely - would you take a task to draft a handbook PR? That would help figuring out the impact on the current processes, and see if that looks doable, and desirable?

Sure thing. This will likely be a big one if it is to tackle all foreseeable problems and corner cases, so I’ll try to do it piece-meal, fleshing it out some more each sprint. Somewhat like I’ve seen you do with recent big changes, but with less resolution up front. That way, I/we can investigate important questions I haven’t thought of from the start, without also wasting time trying to think of everything.


What @adolfo is proposing is sounding a lot like subteams which is what we had back when I joined. Might be worth looking at the documentation from that time about why we moved away from that.

1 Like

Sure – have a look at MNG-82 and the Spillovers: Thoughts & Solutions doc linked there.

Other useful historical threads:

1 Like

TBH this looks like a promising solution but I am really not sold to either extremism i.e being rigid on basis of epic or being rigid on basis of cells.

One of the major benefits that cells have is when an epic demands more work the whole-cell kind of comes together and gets things done which would be impossible if people are subscribe to an epic.

I don’t know the solution yet but I would want to find a middle ground for this to work. The current solution that we have with cells would work and was working till we hit few edge cases. A few of them were:

  1. When a cell’s epic doesn’t have enough work, a cell starves.
  2. When a cell doesn’t have enough capacity and more work, it gets overwhelmed.

I might be totally off here but these are few things I noticed apart from the “metawork” problem that we are discussing. If we get to a point that we are anticipating the above scenarios cells should have the ability to help the corresponding cell, either by absorbing the cells in them for some time or lending some of their members(meiosis or mitosis).

This is based on the limited experience that I have seen for the past 1 year and probably it doesn’t have enough data points so I can be terribly wrong.

NB: I have moved the discussion about your proposal/idea @adolfo to a dedicated thread.

Any objection to make the thread public? It was part of a private thread, but I don’t think there is anything private to a client here. If no one objects in the next couple of weeks, we would make this thread public.


Thanks for the historical info, @jill and @kshitij. After a brief perusal I can see there’s a lot of valuable info there. I’ll try and propose something that skirts the pains of the past, while also trying to soften the pains of the present.

Chief in my mind right now, though, is that the LabXchange project seems to have been from the start what I’m thinking of - first as a subteam in Serenity, then later as Falcon, for all intents and purposes a LabXchange “project cell”, where the epic and client were owned by @usman, who then managed a dedicated team of something between 4 and 6 developers.

To my eye (correct me if I’m wrong) it was doing fine right up until the LX budget was cut, Usman announced he was leaving, and members started to have to diversify: at this point the burdens of having to tackle different projects raised the overhead to a point that started burning people out, which made the problem worse and worse.

Also in my mind is the time I spent as a temporary contractor working in the Serenity/LabXchange subteam (before it became Falcon). For many months I got to spend all my time focused on coding in the same codebase, which made me a very efficient and happy codemonkey. No management except of my own time, little client communication, and only a ticket or two to worry about every sprint. Sure, there were periods of stress (particularly close to v1 delivery), and Usman will certainly raise that it was anything but easy, but that’s just a fact of life in software development. I look back upon that time as my best at OpenCraft.

The point is that I’d like to see if this can be made possible for all core members that want it. From the looks of it, most of us would enjoy it as much as I did.

1 Like

Wouldn’t a group of epics become a cell?

My understanding is that the point of these is reducing context switching to a minimum to get peak developer efficiency, right?

This makes absolute sense, I’m just trying to understand how we could get all developers in that place. There will still be fires, someone will have to handle client communication and project management. Did you explore these?

Sorry, I should be more clear: it’s not a group of epics, it’s just one “normal-sized” epic (e.g. “Small instances hosting”) taken by combining other projects that would otherwise be too small to be epics on their own (“UBC Support” for example). The resulting epic has only one epic owner and may have only one other person involved (the epic reviewer), so it’s not really like a cell.

I imagine client communication would continue to be primarily the epic owner’s responsibility - but not exclusively. Referring back to my time as temp, I would occasionally engage with the client directly, but only as it pertained to the issues I was working on.

And while we’re on it, I see the epic owner in this context more and more as a scrum master. Pretty much exactly as you suggested earlier, @paulo. Not a lead, not a manager, but a facilitator.

The big issue to solve will be firefighting, indeed. I’ve been pondering this on and off ever since I joined OpenCraft. I’ve made it no secret (to anyone that asked, anyway) I think the current system needs improvement. Not just so we fight fires better, but also so that whoever’s handling them is properly equipped to do so.

But as @kshitij has pointed on several occasions to me in the past, the problem with decreasing cell size - which is implicit in project cells - is increased firefighting duty. And yes, I’ve seen small project teams go crazy in the past in part due to this very issue.

I don’t have a proper proposal, yet, but I do have some past experience with the issue. With varied success, companies approach this dillemma via support levels and support teams. As in, a dedicated 24/7 team that handles basic or recurring fires, and for anything complex, new, and/or undocumented, the problem is escalated to developers. We’ve been dancing around specialization over the past few weeks: @Fox went to sales, @tikr is becoming project manager, @nizar is likely to start a full-time developer advocate role. Maybe have a team - a project cell - that is in charge of level 1 (or 2) support? If we end up hosting everything on Ocim/Grove, for example, it might even make sense for that cell to take on the brunt of this work.

Again, I haven’t thought this through properly, yet. I’m sure there will be plenty of issues and corner cases raised in response. But I’m throwing it out there sooner rather than later: I can think of a couple of problems myself, but y’all will certainly think of many more. :slight_smile:

Oh, makes sense now.

Nice, makes absolute sense!

Thatś what I thought, fires might need a sudden increase in capacity a small cell cannot handle.

Yeah, Iḿ just asking questions to help formalize it, I think itś a great idea :wink:

No objection was raised, so I’m making the current thread public.


Good news, everyone! After a not insignificant amount of work between @antoviaque and me, we finally have a project cell proposal worth reviewing.

Because it’s taken so long, and because we want to get the first implementation going as quickly as possible, I’m about to create individual tickets for all core members so you can have some time next sprint to review it.

It’s the usual deal: any questions, comments, or concerns are welcome. Thanks!


I’ve been going through the proposal and will continue to do so, but I do have one major concern so far. We are taking one of the most expensive, time-consuming and disruptive things we do at OpenCraft and expanding on it so that it potentially happens more often?

Projects are generally supposed to be a lot shorter-lived than cells, and one of the reasons the whole cell creation overhead is worth it is that it’s permanent. It sets up a new permanent team.

I’m wondering if it’s possible to accomplish these goals in a different way. For instance, we already have a mechanism for scoped vacations. What if you could have a similar concept for an entire team inside a cell, or even the entire cell?

What I’ve seen with many major projects is that sometimes they need time to ramp up, they definitely need time to ramp down, but also that it’s possible that at times you need more than 100% capacity. In a cell, this is easier to accomplish since you have a buffer of people.

Let us consider first the situation in which we can even take up a large project that would need its own cell:

  • The project is starting soon, and we already have the required capacity in a single cell
  • The project is far enough away that we can hire new people in the meantime.

In these situations, what we can do instead is:

  • If we already have the capacity, then let the cell just take on the project and start hiring. While the project is ramping up, so are the newcomers. When the cell reaches sufficient size, it splits as normal and one of the cell focuses on the single project, while the other keeps the rest of the clients.
  • If we need to ramp up capacity, then first start ramping up, take on the project and as the project ramps up we can split off a new cell when there is enough capacity.

In this situation, the single-project cell isn’t a project cell, just a regular cell, but a cell that can have cell-specific rules about focussing on one project, and about how firefighting works, and can choose to not take on new prospects and newcomers until needed.

I’d just like to avoid the unnecessary metawork of cell creation (and now cell closure) unless it already aligns with situations where we would create a cell in the first place.

On a side note, I think we need to really roll back with the metaphors here. It’s fun and I don’t mind that kind of language when we’re discussing things here, but when committed to the handbook, let’s be very clear and use non-metaphorical terms like:

  • Cell creation
  • Cell dissolution/disbandment/closure
  • Cell merger/recombination
  • Cell split

That is a good point – it’s definitely something to watch for, the cell splits are indeed very disruptive. The suggestions you make make sense to me, though maybe it would mean that there would be a longer delay between the arrival of the project and the time at which the people working on that project would be able to focus solely on it? In any case, we could see how it goes for the upcoming LabXchange cell, and see if taking a more progressive approach would help? Or would it already be useful in the current case?

There may be, but not really, I feel. If there isn’t enough work in the project yet for 5 people to focus on it, then they will need to work on other stuff anyway, right? However, the epic/project owner can start focussing on the project, and the number of people focusing on the project can increase within the cell at least until there are enough people focussed solely on that project that you can split the rest out into a separate cell.

I’ve lost track of the LabXchange project by now, so I might be wrong, I AFAIK, it did go through phases of intense development and lulls in development. If this was the only project the cell had, this would mean ramping down the cell and then hiring again. I think, even in the current situation, it might be good to consider making the cell a general cell as the work ramps down instead of disbanding it.

I don’t think we need to change anything for now, but just not waste the work done to set up a new cell. Once the work is ramping down, the cell can just start picking up other kinds of work and transition to a general cell.