Discovered vs. Imagined Work and a Real Team’s Shape Up Retrospective
If you find this post interesting, let’s continue the conversation on Twitter!
In 2020 my company switched from JIRA to Basecamp and more importantly from some weird Scrum variant to Ryan Singer’s Shape Up. It is the best “process” change we’ve made since I joined in 2016. Near the end of 2020 we posted a message in our company HQ asking everyone to contribute a brief retrospective of the year, talking about what went well and where we could improve. Most people, unsurprisingly, mentioned the shift to Basecamp and Shape Up. Here’s an example (and my absolute favorite):
While this approach to our work is still a WIP, we took big steps in the right direction, and I think we will all be better at our jobs because of it. This philosophy requires a really strong talented team that trusts one another, and care more about productivity vs. process. Shittier teams would have failed almost immediately.
There were also a few concerns we needed to address and a new year is a perfect opportunity.
Feel like the Basecamp process is still something to get right.
It wasn’t clear initially on how to address the technical dept. We collect the bugs and ideas in separate projects (small batches) but we still have things that were postponed for months, due to things with higher priority. There is a plan for a cooldown period, where we could choose to work on those things that are of lower priority, and hopefully, that will fix this issue in 2021.
After reviewing over a dozen retros and 20 projects over 7 4-week Shape Up cycles, we made some minor changes and I thought I’d share the specific feedback and changes we’re making going into 2021. This is my exact Basecamp announcement. It was originally titled “Discovered vs. Imagined Tasks and Trade Offs”.
Hey Everyone,
The 2020 Retrospective surfaced some really interesting points about the progress and pitfalls we’re making as a team. I specifically wanted to take some time to summarize and address one of the overarching themes of the retrospective, our switch from JIRA and Scrum to Basecamp and Shape Up. It seems like there is a need for some practical guidance on a few topics.
The feedback we received regarding the switch was overwhelmingly positive! Engineering and Design teams have more autonomy and creative freedom. We’re not bogged down by infinite backlogs and never ending Epics. The general feeling is that when a project is going well, Shape Up works! On the flip side, we seem to be struggling with a few basics that I’m hoping to address here in more practical terms to shore up our approach. Specifically, I want to talk more about Imagined vs. Discovered Tasks and Trade Offs. I think the first couple of times these were discussed was too theoretical, so I’m going to include more examples now.
The “Rules of Engagement” for Shape Up are simple. As everyone knows, starting in 2021, our cycles for projects are 4 weeks long followed by a 1 week cool down period. All projects in a cycle must be shipped to production within the 4 weeks and cannot spill over into the cool down. The cool down is for the Engineering and Design teams to work on whatever they’re interested in related to their products, as well as in some cases to spend some time with Charlie, Adrienne, Sergio, and myself shaping the next cycles’ projects.
The point of laying that out in such explicit terms is so that we can address the obvious question, “What if we can’t complete the work within the cycle?”. If we can make the right trade offs early enough I’m confident we can complete our cycle work. Yes, there will be times when what we shape is too big for the cycle. Yes, there will be times when something in production causes some code red situation and we lose time doing something else. Yes, there will be times when people decide last minute to take a week vacation (let’s try to avoid that). On and on.
When we first started Shape Up we basically said as long as there are scopes in the hill chart and they’re up to date then we could address concerns as we go. For example, if a hill chart didn’t move for a week, that was cause for concern. After reviewing a lot of the projects and the todos that are going into the scopes in Basecamp we’re going to walk this back slightly and be a little more specific about a new “rule of engagement”. Todos in Basecamp must represent discovered work for the project.
During the course of any creative work that any of us is engaged in on a day to day basis there are usually two lists that we’re tracking (hopefully not just in our heads). Things that we need to do and things that we might do. As we do these things, we discover more things to add to each list. Adding these things as todos in Basecamp is the first step to being able to make better trade offs. Not only this, but if we’re holding these things in our heads instead of writing them down, this approach will give us more room in our brains to do actual creative work and think. This also goes for work we discover that other people probably need to do. Writing something you’ve discovered in a todo list in Basecamp doesn’t commit you to doing it. So, if you’re already tracking your project work then there shouldn’t be any complaint doing it in Basecamp instead, and if you’re not tracking your project work and keeping it all in your head then get to it!
Discovering tasks and writing discovered tasks into todo lists is fundamentally different from imagined tasks, which is the approach we used to take in JIRA. We used to try to come up with all the things we needed to do in order to implement some story without actually doing any discovery first. This causes two problems — the imagined work didn’t add up to solving the problem, and there was work outside of the imagined work that we discovered we needed to do that eventually got reported as “added scope” because we forgot to imagine it. When we start a Shape Up project, we don’t start by adding imagined todos and scopes to a list. We start with an empty list and everyone gets to work on solving the problem put forth in the pitch. As each person figures out things they have to do or could do in order to solve the problem, they add things to the list.
When we originally said that scopes moving along the hill chart is good enough what we should have said is that the fidelity of the scopes and the todos in Basecamp is up to the teams and that there is no right answer. The ask right now is the greatly increase the fidelity of the todos to the point that there is no question whether we have an accurate representation of the known work for a project. Here’s an example from a Basecamp project in which todos capture real work.
Here’s another great example.
How will this new behavior help us make tradeoffs?
When we have a real list of high fidelity discovered work in front of us we can start to cut things out and mark them as “nice to haves”. We can surface unknowns and complex approaches much easier. Here’s a specific example. In our last IDEx project we had a problem we needed to solve which surfaced information about a diagnostic without requiring the user to switch contexts (open a new tab). In order to solve this problem the team decided on a hover preview feature. Now, when we had this discussion, it was brought to my attention that the preview should necessarily show a summary of the overview of a diagnostic, but the diagnostic summary could be complicated, it could have images, rich text, etc. and that the preview we designed was too much work. We only had a few days until the project was over and of course we needed to solve this problem and ship by the end of the cycle. This is exactly a situation where discovering work instead of imagining it can help the team understand the trade offs that need to be made. In this particular situation we were lucky to figure out that we could extract and truncate just some initial number of characters from the text of the overview for the preview component. But at what cost? Had we done the discovery and surfaced it up front, we might have had an opportunity to make to other trade offs in the project. In this case our hand was forced.
One last thing — this probably doesn’t need to be said but there is no situation in which we should be making trade offs which have a net negative impact our users’ experiences with our products or degrade their stability. Trade offs are specific to the ways in which we decide to solve the problems we’re presented. Sure, in some cases we’re going to inevitably have to introduce some new complexity to the user because it greatly outweighs the cost of solving that complexity on the engineering side. Practically, a lot of what I’m seeing is that we’re in fact designing in a way that doesn’t fit into our current project, or we’re reintroducing design concepts from previous projects that were never implemented as a way to solve new problems, and then we’re forced to make trade offs against those specific designs. Design is part of the project, the designs we produce also need to fit within the appetite for the project. I don’t want to see separate “design” lists in the Basecamp projects!
The products mentioned in this post that we develop can be found at https://pubhub.help and https://idex.ai