I’m curious if anyone has attempted to apply Shape Up to Ops engineering, and what your experience has been like. I’m saying “Ops engineering” to broadly refer to engineering infrastructure, IT, DevOps, DevSecOps, Security, compliance, reliability/SRE, etc. My read is that the Shape Up’s methods should work because you would account for ops/infra needs during shaping and in the pitch. On-call rotations still fit into the model, etc.
Welcome, @highlytedious! I’m curious about this too.
My team uses Shape Up for well-shaped projects where we have enough say-so over the projects (i.e. no external dependencies) to confidently believe we can ship by the end of the cycle. On-call work is necessarily unknown ahead of time and represents a fat-tailed risk, so we’ve historically been managing these sorts of unexpected needs with Kanban, but it’s been the responsibility of a person also doing cycle work and that’s become a strain on that person for the week they’re “on-call” and jeopardizes their ability to ship on time.
It’s a substantial enough need that right now we’re considering dedicating a developer per cycle + cool down to a rotating role we’re going to call the Free Agent. If the person working that role during a given cycle ends up with a lighter-than-expected workload, we’ve got plenty of non-critical bugs and nice-to-haves out there for them to pick up.
Rather than trying to force everything into a Shape Up way of doing things, my take is to use it for what it’s great for and otherwise just call a spade a spade and make space for the unknowns, tailored to the needs of your business.
Thanks @kevinsmith
we’re considering dedicating a developer per cycle + cool down to a rotating role we’re going to call the Free Agent. If the person working that role during a given cycle ends up with a lighter-than-expected workload, we’ve got plenty of non-critical bugs and nice-to-haves out there for them to pick up.
Interesting. That’s sort of how I’ve approached on-call with scrum/scrumban in ops teams as well: by having an “interrupts” rotation on each team for each sprint, where the person in on “interrupts” is on-call and handles incoming issues and requests, on/off-boarding, etc. If they get free time then ideally it’s their own time to spend as they like. This “Free Agent” or “interrupts” cycle would have to taken into account at the betting table I suppose.
Rather than trying to force everything into a Shape Up way of doing things, my take is to use it for what it’s great for and otherwise just call a spade a spade and make space for the unknowns, tailored to the needs of your business.
Definitely my take also. Part of me wants the Shape Up book to have all the answers to questions like this but I also don’t think that’s the point. Any methodology is going to need to be fitted to your situation, and will probably be in a constant state of change if you are committed to continuously improving. There are, though, a set of notions in Shape Up that I find novel and very interesting (I really like the concepts of appetite and hill charts, for example).
We do not, the only team we have doing Shape Up is the “core” engineering and design teams. I think this is a detail that is unfortunately left out of Shape Up. Running cycles via Shape Up requires a certain level of product, software and design fidelity, maturity, and fluidity that you have to get from somewhere (either new product R&D or those other teams). You have to be able to “hand off responsibility” and let the team work and ship while you figure out what’s next and they need the time to focus.
I recently reached out to DHH to get a better understanding of how they handle this at Basecamp. It sounds like their operations teams (at Basecamp I believe they’re called “Research & Fidelity”, “Security, Infrastructure & Performance” and “Ops”) use the cycle cadence but work with looser deliverables - not a full production version of Shape Up. It’s also not product leadership primarily bringing pitches forward for those teams, it’s the senior leaders of those teams.
To me, the lesson here is context matters. You might take @kevinsmith’s approach with the Free Agent concept. I personally prefer the “principal engineer” concept for smaller product teams, which might be a bit of an inverse. Someone who writes their own pitches and works out of cycle to focus on longer term initiatives, R&D, code fidelity, etc. and helps out the core team as needed. It’s more of a way of “elevating” individual contributors who are strategic thinkers out of the autocratic nature of the production version of Shape Up