We’re now about six months and ten projects into developing products using Shape Up as a primary framework. One of the chapters in the book is titled Get One Piece Done. We’ve tweaked our own internal process for getting one piece done throughout the projects we’ve completed. Some ideas went well, others not so much. This post is a look behind the curtain within the Explorate product team at our current process, and the lessons we learned along the way.
Before we get into our own experience, let’s look briefly at the literal ‘by the book’ reasons to get one piece done. Getting one piece done is about communicating progress and reducing the risk of failure. The communication piece happens by focusing on shipping an end-to-end user experience, even if it isn’t fully featured.
If anyone (with the right credentials) can test a new workflow and get a gut feel for how complete it is, there’s less need for onerous status updates and check-ins. Additionally, if there’s always an end-to-end experience that’s been shipped, even if we run out of appetite we know we can complete some fraction of our users’ needs. Contrast this with just shipping new APIs but no UI to interact with them.
Let’s look at how this played out within our teams. At a high level, our early attempts were pretty unstructured, we had some good outcomes but mostly by luck. The second batch of projects ended up being too prescriptive and had us shipping things to check a ‘we shipped on piece’ box. Finally our latest setup is focused around shipping a tiny version of that end-to-end experience. To make this happen we had to make a few changes to our deployment process.
Starting too wide
Starting with our first cycle, things we’re fairly free form. There was a lot we were getting used to in that first cycle and this one chapter was just as important as all the others. As a result, our pitches and the team’s plans ended up close to your traditional project based timeline. There was a lot of work in the early weeks doing things ‘behind the scenes’. New database tables, planning the ideal data structures and UI, putting in place new components and APIs.
In these projects we had trouble knowing how things were going without explicitly checking in. By the end I felt like a broken record and somewhat reluctant to ask how things were coming along. In the last two weeks of the projects we then saw a burst of activity. All of the pieces were finally ready and were put together. With our first end-to-end experience out the door users were able to test and provide feedback.
Luckily for us, these projects ended up working out well. The core of what we wanted to ship had been well scoped so we didn’t launch something nobody cared about. Despite that we ended those projects feeling somewhat like we’d run out of time. Now that these new features were in the hands of users we started to receive more and more feedback. This helped us realise where some of our assumptions were wrong and where we could tweak what we’d shipped to deliver better outcomes.
What was interesting about this feedback was that for the most part it wasn’t changes you would group into the category of ‘polish’. We always knew we would get minor feedback around UI or small features like customisable columns on a table. What we found however was new workflows or changes to processes that we could have found with even a very rough version of what we shipped.
By the time we hit week five and six we had run out of time to make these changes, partially because things were so polished and would have taken extra effort to change. After seeing this first hand we doubled down on ‘get something out the door early’ in our next batch of projects.
Becoming too narrow
To account for what we saw we made a conscious effort in our next cycle to call out what our ‘get one thing done’ goal would be. The mistake we made was putting that in the pitch. We incorrectly thought that if we listed some quick-win features that were proximal to our pitch we could get something useful out quickly. While we did ship *something* it turned out that shipping just anything didn’t give us what we needed. We had some new app features but weren’t any closer to a usable version of our end-to-end experience.
We ended up in a similar end state with this approach. Our first week or so was spent shipping these low hanging fruit. These features were useful in isolation so the product is better for having shipped them but we only then started on the core work for the pitch. The difference this time was we were already in week three having spent two weeks on low hanging fruit.
Once again we got to week five and six before we started to see the end-to-end experience take shape. Early feedback revealed some new requirements that had to be integrated into the project as we were fast reaching the end of our six week appetite. When the team wrapped up this project we didn’t quite have a full, usable, version out the door. We spent some time on this project in the first week of cool down but ultimately made the call that we needed to take the project back to the betting table.
Throughout this cycle we also started to more broadly roll out feature flags. We had been using them in small tests for previous projects but a project in this cycle made use of flags to allow a small subset of users to test new features. This particular project ended up shipping a lot more in one cycle thanks to early feedback from end users. Having feature flags meant we could deploy faster without risk to existing workflows. Watching this project unfold we realised that the developers on that team had found a way to stick to the core of ‘Get One Piece Done’.
The sweet spot (for now)
So where’s that left us? After those two cycles we took stock of what getting one piece done meant and tried to put some clear guidelines in place. Here are what we landed with:
- Whatever the one piece is, it should be a version of the end-to-end solution.
- It doesn’t need to be perfect. In fact, it almost certainly won’t be.
- If you can put it behind a feature flag and leave current flow alone, ship it as soon as you can.
- Start with one narrow flow and expand outwards, rather than shipping step by step.
- At the end of the day, these are just guidelines.
Our next cycle starts in about a week. To prepare we’ve not only tried to distil the process above but we’ve taken steps in the shaping process to help. First, we don’t claim to know what the first deliverable thing will look like. It should be the fastest to implement a sliver of the end-to-end flow. We can guess, but ultimately until developers start building a guess can be a distraction.
We’ve also taken care to remove any extra items in pitches that feel like they’re not quite on the golden path. It’s easy to look at an area of any application and come up with half a dozen small tweaks that feel related and could go into a pitch. We’ve found that adding those takes time and effort away from building the main thing we care about. We save small nice to haves for cool down, the occasional mixed bag project or things to add once we’re done with the main features.
No doubt this process and our definition of getting one thing done will continue to be refined. No framework or book can perfectly prescribe how to build products and, at the end of the day, the framework and process we use is just the guideline. The real value comes from the work that gets done within the framework, not from the framework itself. We try hard to make sure that we provide just enough framework to keep things from falling apart but not so much that the rituals and process become a time sink.
Leave a Reply