At Autobooks we’ve done a number of projects using ShapeUp over the past year. The projects that have tripped the circuit breaker have mostly involved external dependencies.
A few months ago Ryan said to me, “you can’t place bets with other people’s money (resources/dependencies),” and that has stuck in my head.
Shaping and de-risking have helped us make a lot of progress with these projects:
We have a better understanding up-front of what our desired result is, and we don’t find ourselves halfway through a project discovering that we can’t achieve what we set out to achieve.
We use ShapeUp to force trade-offs and make sure we can cut scope as much as possible and still hit our objective.
The difficulty comes when we decide to place a bet. We’ve shaped the project and de-risked to the best of our ability. We place a bet that states, “if we achieve our objective it is worth investing 6 weeks of our time.”
We place the bet knowing full-well that the risk we can’t control is the external vendor that we’re working with and their ability to respond to questions, access requests (creds), bugs on their end, final certification, etc.
When we retro these projects we find that although we adhered to our method of execution and pushed the project forward (identify biggest unknowns up front, push things up the hill, …) we still trip the circuit breaker because we’re waiting on something from an outside party.
Has anyone found an elegant way to handle these projects? I’ve been trying to figure out some combination of shaping and de-risking up front, and then a kanban-style method of execution, but haven’t gotten very far.
Hey Chris,
we regularly have projects with external dependencies as well and in the past had issues with them blowing up our cycle rhythm.
However, they are usually of the nature that they have to happen - for example we’ll onboard a new supplier to our platform (big real estate holdings) and agree to some custom work for them in the process. Not sure if that fits well with your type of externalities.
In any case, since these projects happen regularly for us now, we’ve dedicated two developers at all times to a Kanban track where we move those projects. These projects carry estimates instead of appetites (they gotta happen more or less). And then we move smaller tasks that would be nice to happen to the Kanban board as well.
For us, it’s been a neat way to get in those small things that you wouldn’t write a pitch for and not risk the cycles getting blown up due to external dependencies.
For some context, we started this way of splitting the tracks into “Cycle” and “Kanban” two cycles ago. So far we’re happy with it.
Let me know if this helps and I’m looking forward to hearing others on the issue!
While we haven’t had to deal with external dependencies yet, I did have a thought for something you could maybe try.
If during the shaping stage, you’re able to identify where in the project you’ll likely have the dependency - e.g. waiting for partner to build an API - you could try breaking the project into small batch projects with those dependency windows as the split point. Then instead of betting the whole thing, only bet into the Cycle the small batch part that you’re more confident you can deliver without outside dependency (i.e. only betting with your money). Then you only bet the next small batch part of the project after the external dependency have done their part.
This might take longer, as you could end up doing the whole project over multiple cycles a few small batches at a time, but at least you would be de-risking up front. What do you think?
This is along the lines of what I’ve been considering, so it’s great to be talking to someone who is farther down the path than me.
Have you run into any challenges doing it this way?
Dev moral? Do developers aspire to be on one team or the other (kanban vs. 6-week bets)? Do you use it as an onboarding/ramp-up phase for new developers (something I’ve considered)?
Any problems managing the codebase? Kanban merging frequently and 6-week bets merging at different times?
I’m going to consider to ponder this, but I think the unexpected nature of the external dependencies make it difficult. One vendor will block on day one of development when one our devs says, “I found a bug in their code and they said they’re looking into it and they’ll get back to us in a few days.” One will block at the end when they need to certify our integration and tell us that they don’t have anyone to assign to our account for three weeks.
Maybe over time I can build up enough stories to be able to predict what kind of dependencies will block projects at different points, but I’m hesitant to build a system that depends on that.
Generally, I think all the devs do prefer to be on the cycle teams because that’s where the work that moves the product forward is happening. In our current setup, we’ve straight up asked two devs in particular if they’d be willing to be on the Kanban track for now. This had to do with existing knowledge of the context of the work needing to be done on that track at the moment, not at all with seniority. I think after 1-2 more cycles max they’ll likely want to switch it up.
I don’t know how I feel about the idea of using a Kanban track as an onboarding ramp for new developers. Haven’t considered it so far. But feels a bit like “You gotta prove yourself in team Kanban to be worthy of a cycle project”. If the nature of the Kanban work lends itself well to ramp-up kind of tasks, then this might make sense. But overall I’m a bit on the fence about this.
Eventually, what I’m thinking will happen for us is that we will end up with some sort of rotating system where maybe every other cycle, the two devs on the Kanban track are switched. Or maybe there’ll be times without any Kanban projects, where everyone will join in the cycles. I’ll let you know how things turn out!
Not really, but not due to the fact that one team is working Kanban style, but rather that the Kanban type of work is mostly concerning one of our apps that’s currently not getting much cycle work focus. Sorry I don’t have more general advice for you on this.
Let us know what way of working you all do end up implementing. Happy to talk further if questions come up!
An external dependency seems like work that’s impossible to shape, completed by a team impossible to manage. Would you ever pull work like that into a Shape Up cycle?
I have an analogy that may be imperfect but helped me think things through.
To me, an external dependency is a firecracker with no fuse. Would you give that firecracker to your delivery team?
Maybe. If it’s a tiny firecracker, worst case is a missing finger or two. Lesson learned … and that learning may have intrinsic value, e.g. “Yeah, let’s not use that vendor ever again.”
But, if a box of M-80s, boom goes the entire cycle. It may scar your team in ways you didn’t anticipate. Sure, it’s just six weeks lost. But that’s a cycle you’ll never get back.
The safest path? Keep the firecracker away from your Shape Up team. Give it to a 2nd “bomb squad” team instead (or if your delivery team is small, split it in two), who works on the firecracker independently until it’s safe to bring back to the betting table.
An ad-hoc parallel kanban team.
Because otherwise, you’re putting a great deal of pressure on the betting table to guess the blast radius of that firecracker, and pressure on the delivery team to adapt to the unknown, unshaped risk.
@chriscbs could you give an example or two of the kind of external dependencies you’re working with?
I think things like integration bugs we can’t foresee, client processes we can’t modify, or politics we can’t influence can probably all be addressed with some intentionality during shaping.
I don’t know if this fits your situation, but in our case we mostly address this by trying to replace recurring external dependencies with product solutions.
For example, we rely on local marketing partners to ramp up in new markets. Our integration with those partners is at the whim of their schedule and takes focused engineering time because it involves syncing data that each partner seems to want to provide in a different format.
And yet, on-boarding these new partners is mission-critical. As @david said, “it just has to get done” and it wasn’t going to get any simpler on its own.
So we shaped a 6 week project (and then a subsequent 2 week project) that standardized how we import that data. Now these partners format their data to our standard (instead of the other way around) and we’ve automated pretty much everything that was being done by a human in that process.
We were able to do this because the work to onboard a marketing partner didn’t need to be shaped. It was all a down-hill task - just a check-list of things that needed to happen. That may not be true of your situation.
