We asked our team to reflect on 2020 and people overwhelmingly mentioned our switch from JIRA to Basecamp and Shape Up. I posted the changes we’re making and how we’re going to evolve in 2021.
4 Likes
In that first post I mentioned we’re integrating cool-down into our cycles. Here’s how:
Thanks for sharing! This is so helpful as a team that is just starting off with Shape Up - and moving to it from a weird version of agile and Jira.
Couple quick questions:
- How did you get buy-in to switch away from Jira? That’s been a sore spot for our team, and so we’ve stayed in Jira for now which introduces some weird adaptations to make everything work.
- One of our biggest problems is “scheduling” when cycle planning. The business team has a hard time allocated developer resources without accurate estimates, but estimates are almost always wrong and can very quickly turn into anti-ShapeUp workflows. We start getting into the scheduling Tetris to make everything fit.
- How did you land on 4week cycles? We started with 6 week but there’s been pushback on that since it feels like it’s so long to plan.
- We’re currently skipping the cooldown because there’s a sense that management feels like it’s lost time. We originally tried to have a team of devs outside of the Shape Up flow to handle bug fixes/tech debt type issues, but they quickly got a huge backlog handed to them. Do you find the 1 week cool down a good compromise?
1 Like
How did you get buy-in to switch away from Jira? That’s been a sore spot for our team, and so we’ve stayed in Jira for now which introduces some weird adaptations to make everything work.
It’s hard to answer this question exactly because there were a number of factors that went into this decision (I didn’t necessarily have to convince anyone but it was nice to convince the engineering team nevertheless) and the decision is more about Shape Up than Basecamp but basically
- Leaving all the JIRA backlog garbage behind
- Hill Charts
- Thoughtful writing - I’ve always been a huge proponent of thoughtful writing instead of what I call “Semi-Ephemeral Information” which is information strewn all over places like Slack, Jira Tickets, Confluence etc. I was already writing pitches as a way to describe goals for sprints and they’d get broken up into a bunch of “stories” and not actually equal the problem I wanted to solve. It was all imagined. Much easier in Basecamp where you have two things basically, announcements for long form messages and thoughtful responses, and to-do lists where you put the things you’ve figured out you have to do, could do, want to do
- Made everyone read Shape Up that was going to be involved
One of our biggest problems is “scheduling” when cycle planning. The business team has a hard time allocated developer resources without accurate estimates, but estimates are almost always wrong and can very quickly turn into anti-ShapeUp workflows. We start getting into the scheduling Tetris to make everything fit.
This problem is very specifically solved by Appetite in Shape Up, there are no estimates. The business is responsible for defining the problem they want to solve, roughing out a general direction for how they’d like it be solved, and their appetite for solving it (how much time/money they want to spend solving it). That’s usually done by the Shaper. Senior engineering leaders who have deep technical knowledge of your domain need to be involved in this process to understand what’s being asked of the engineering team. The engineering and design team are accountable for solving the problem given the appetite. We allocate people by product and then by project. All cycles start at the same time, engineers are afforded uninterrupted focus on the project they’re assigned during a cycle.
How did you land on 4week cycles? We started with 6 week but there’s been pushback on that since it feels like it’s so long to plan.
We were doing 2 week sprints prior to Shape Up and at the end of each sprint we were inviting the exec team to sprint review because they like to know what we’re shipping. When we started Shape Up we went to 3 weeks to give more room for discovery and making trade offs and handling larger projects but wanted to keep the cadence with the exec team. Then we went to 4 weeks with no cool down and finally 4 weeks with 1 week cool down. It was basically an exercise in getting them used to fewer updates aligning with our product cycles and the idea that those two things (cycles ending and business stakeholders getting updates) don’t need to aligned for any particular reason.
We’re currently skipping the cooldown because there’s a sense that management feels like it’s lost time. We originally tried to have a team of devs outside of the Shape Up flow to handle bug fixes/tech debt type issues, but they quickly got a huge backlog handed to them. Do you find the 1 week cool down a good compromise?
I’m slightly disheartened to hear “management” and “business team” and “pushback” haha so I’m sorry about all those situations, adopting Shape Up should really be a learning opportunity for everyone and it’s not a long term commitment that can’t be changed.
Cool down is essential. People deserve breathing room, they need to recover after sustained intensity and they need to taper before it. It’s about mental health more than it is the bug fixes and tech debt. We never prescribe what people have to work on during cool down, it’s their own time to be creative to solve the problems they’re interested in solving for the business before we ask them to go heads down again.
I do think it’s important to have principal level engineers that work out of cycle ensuring that the engineering teams working on projects have the tools they need and are building sustainable, future thinking software. I don’t think there’s any circumstance where developers should regularly be handed bugs that interrupt their day to day work, that should be a rare exception. There are categories of bugs and most of them shouldn’t be critical. One behavior I used to see in the area of bugs was people who aren’t responsible for engineering teams committing to software changes. That type of thing is a huge red flag. If contractual or other obligations are in the way of a shift in that type of behavior then there’s probably something context-specific that can be done to help
Wow! Thanks for the thoughtful reply. This is really helpful.Your point about appetite vs estimate has been the hardest to communicate, despite most of the team having read Shape Up (or maybe claiming to), we keep coming back to business team wanting quantifiable estimates from developers for planning purposes.
Unfortunately our “first” cycle started off as this weird hybrid of needing to finish existing work and then has this whole “estimation” spreadsheet bolted on, so we’ve drifted pretty far from the spirit of Shape Up. We knew the first one would be a mess, but now we have additional work to undo!
One other question: how long did it take for the team to “get” the Shape Up flow? My experience is that some of our developers see the value, but the others just see it as “6 week sprint”. Our business team feels like it makes the process too opaque and keeps them out of the loop. While that’s sort of true as far as no day-to-day standup or anything, to me it feels like it would be incredibly empowering to the business/product team because they can really guide the direction of the product through the betting process. However, that just hasn’t clicked for most of the team yet, so we’re being pulled between Shape Up and traditional agile and ended up with some sort of “Frankenstein’s monster” process!
This is bringing up a lot of PTSD flashbacks for me, @rossvz 
Had a very similar experience, and ultimately the majority of Shape Up practices failed, because management & exec leadership set it up to fail. They wanted 3 weeks cycles with no cooldowns (they viewed it as giving the team a holiday every few weeks).
Sadly, it sounds like management on your side is not bought-in enough on Shape Up to make it work. From my experience, they need to be for it to work, because leadership plays a critical role into it. They’re the ones making the bets and they are the ones who need to honor them.
The Appetite vs Estimate issue is odd to me. If the appetite is, say, 3 weeks. Then why can’t they view that as the estimate for whatever planning you’re referring to? In many ways, an appetite is an estimate that you declare up front, but with variable scope being the key to making it work.
Something you can try look at to help with this is to figure out what (if anything) wasn’t working for management, before you tried to adopt Shape Up? If they were happy with how things were working before (with regards to their own concerns), then it makes sense that they’ll be resistant to the changes. No struggle = no desire to switch to something else. But if they were struggling with things, then you can hopefully tie the solution for them to Shape Up. That might give them enough motivation for you to make a case to giving it a proper shot, without compromises, for at least 1-2 cycles and then see what they think.
Getting one or two success stories will help a lot with convincing them. But that will be impossible if they’re always (unintentionally) sabotaging it.
Good luck! 
2 Likes
Yep. All this.
Also regarding appetite vs. estimate, if estimates are always wrong then Shape Up gives you the tools to explain why - because at the point of the estimate the work is imagined and the scope is fixed. Appetite is about fixed time, variable scope problem solving. The commitment is to solve a specific problem within a time box if the business allows the team to focus. Most teams suck at Scrum because it requires imagining a bunch of tasks and then estimating them and committing to complete them. The estimate isn’t usually wrong, it’s what was imagined that was wrong. Committing to do things before you’ve figured out what to do is a problem.
how long did it take for the team to “get” the Shape Up flow?
It’s always a work in progress and we’re constantly critical of our own approach
Thanks for sharing @justin! We’ve been working the “Shape Up” way for probably about the same amount of time as you but without using Basecamp. Sounds like the Hill Charts have been a big help in your teams experience? We try to use them but they’re a clunky extra step in our process since it’s not embedded into GitHub which we use for everything.
Reading through your post it sounds like you have multiple people shaping projects, I wondered if you could share something about what that looks like? How do you split the work of shaping between yourselves?
Hill Charts are great for us because they give us transparency into the status of each scope in a project without having to analyze to-dos. What makes the feature valuable to me isn’t seeing the work laid out statically on a hill chart but to see how the scopes are climbing the hill chart over time. If I see that a scope is stuck for a period of time then I can investigate why it’s stuck. I can see whether there’s a difference in the success of projects using different methodologies like getting all the scopes up the hill first (my current recommendation - do the hard stuff first) or getting them to the finish line one at a time.
We have multiple people shaping projects only because we are building multiple products. There’s really no overlap in product teams so nothing particularly special is going on there. My message was just to the entire org, which encompasses all of product, engineering, and design
1 Like
Here’s an example of the use of a Hill Chart. Remember, we don’t assign any tasks, just the project. The team is responsible for discovering and recording any and all tasks they must do, might do, are viable alternatives, etc. This level of transparency affords the team more autonomy and fewer distractions.
Context: This is in a 4 week cycle small batch for a two person engineering team + 1 designer. There are 4 projects each with a 1 week appetite, so an individual engineer working on a single one (their choice within the project) has 2 weeks to complete it. We were almost up the hill after week 1, good progress, no need to intervene, I leave them alone 
. The project was completed today and since it’s small batch Roman will move onto the next hardest project. When all the small batch projects are shipped, if they have time they’ll come back to some of the nice-to-haves and choose what to work on across the 4.
This only really differs from large batch in that for a large batch project I give a team 4 weeks to solve one larger problem and they define the scopes. With the small batch they’re getting 4 weeks to solve 4 smaller problems and the scopes tend to just be reflections of the problems (but again it’s up to them to define). We track the 4 1 week problems in the same basecamp project so that we can make tradeoffs across them within the cycle since it’s the same team responsible for all 4
1 Like
Thanks for sharing such a detailed example!
I’m definitely sold on the benefits of the hill chart. Biggest challenge right now is how we adopt without having to adopt Basecamp. (Which I would happily use - but not sure the organisation is in a position to adopt another tool right now)
I think what’s really nice about the hill charts in Basecamp is how they’re so tightly integrated with the task lists. It’s not a completely separate thing to think about.
1 Like