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.