Shaping Up

A few months ago, scrolling through my LinkedIn feed, I noticed a listicle of "Must reads for Engineering Managers" which mentioned "shape up". Intrigued, I clicked and started reading the free online book. The concepts, for the most part, were brand new to me. Before even getting all the way through the book my mind was running ahead with plans on how to start taking some of these new ideas into use in Naveo.

While I would have loved to take my team and jump in headfirst, the timing was not right for us. We are still aligning on processes following a merger and the ongoing pandemic has meant our grocery ecommerce platform is seeing a huge increase in demand. The combination of these factors meant that playing around with a new process, no matter how exciting, was simply be too disruptive to be on the cards. Not willing to be dissuaded I opted to take a hobby project of mine off the shelf, where it had been stagnating for the best part of a year, and apply the shape up method there (as much as possible for a 1 man project). Today, moments before sitting down to write this article I published the MVP version of that project.

Triathlog - The triathlon workout tracker

In October of 2015 I packed my bags and boarded a flight from Australia to Finland. With that, my days of daily ocean swimming were over. Finland has a lot going for it, warm water is not one of them. In Newcastle NSW I lived 5 minutes from the beach and even in midwinter the Pacific Ocean was warm enough for swimming. Conversely, the winter sea in Helsinki is frozen solid and ready for cross country skiing or ice skating. Even at the peak of summer the water would best be described as bracing. It took several years of gradual acclimation to the bitter cold of Finland, but by 2019 I was ready to literally and figuratively dive back in. I took first to the lakes and then later to the sea, and I loved it. The serenity of swimming out in the vast expanse of water, in total isolation from the rest of existence, is wonderfully meditative. It quickly became part of my routine once again (albeit only in summer). I never found much appeal in swimming inside, up and down the same crowded 50m lane, with shouts and speaker announcements echoing off the walls, and so as the autumn cold drew in I packed my goggles away for the year.

When a colleague suggested trying to do a triathlon, I was instantly onboard. It was a new challenge and would provide me motivation to keep exercising through the winter. I started running again, and even bought a second hand road bike. I would track my workouts with the strava app on my phone, placing it in a floating dry-bag trailing behind me on swims. For brick training (triathlon speak for two sports together) this was a bit fiddly, I would get out the water and change out of my wetsuit into running or biking gear but also have to fish my phone out of the bag to stop the swim tracking and start the bike/run. This sparked the idea for Triathlog, an app to let you plot your workout route with different sports and transition zones. Then everything gets recorded automatically, the gps signal sees when you start, when you switch sports and when you get to the finish.

As with so many ideas, I never got round to building it. I thought about it a great deal, adding more and more cool new features in my head, which is what made it the perfect candidate for shape up. A quote from the book that really jumped out for me was this:

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.

Both professionally and in my personal projects I have been a victim to the blight of scope creep, and even if the scope is zealously safeguarded, its easy to lose motivation for the work when it feels so far from completion. I have worked with SAFe (Scaled Agile Framework) in a couple of companies where we have a rigid 6 or 8 week plan. In SAFe you are filling up on 6 weeks worth of work that often doesn't constitute a tangible release. Shape up was about picking a thing you want to build and figuring out how to get something worthwhile done in 6 weeks.

There are three parts to the method

1. Shaping - Figuring out what to build to solve a particular problem
2. Betting - Deciding which solution to build / which problem to solve
3. Building - Getting something shipped

The betting section was least applicable to my independent project although there were still some useful takeaways to apply. Shaping was were I could really dive into the method.

Shaping

The concept of shaping is to give a design and implementation team enough information on what should be built to be able to make trade-offs in the development, without giving them something so concrete that there is no room for creativity.

I have seen both extremes, often within a single company, and sometimes even coming from the same source. I have been in rooms where a supervisor has given a complete mock up for a feature with exact specifications on how many pixels of white space are needed between this button and that, only to then turn around and tell another developer to build a "scheduling calendar" without an ounce off context. The pitfalls of both these approaches are self evident, but I'm yet to work in an environment where the perfect middle ground can be consistently found. Maybe shape up has the answer.

We borrow a concept from electrical engineering to help us design at the right level of abstraction. A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.

The concept is fairly simple. Map out the things you need to do the job without concerning yourself with the details of the finished product. The book gives a more detailed explanation but I will just walk through an example of where I used breadboarding in the development of Triathlog.

Here is the breadboard for the functionality to complete a workout. The underlined words are views, what kind of view (new screen, a tab, a pop up etc) is an implementation decision. The lists underneath each are actions that can be taken from the view, and again the method for accessing those actions (buttons, sliders, gestures, etc) are implementation decisions. The arrow show where the different actions take you. This breadboard diagram demonstrates what is needed whilst giving the freedom to implement however the designer and developer determine to be best. Even in the case where I am shaper, designer, and developer combined, I still found the separation in thought process to be invaluable.

Breadboarding is something I felt able to fully utilise in my project. By not having a real business environment, I was limited in how much I could explore "appetites" but I will mention it purely because it resonated so strongly with me at a conceptual level. The idea is that you assign how much time you are willing to spend on an idea and then shape the scope to fit your appetite. I have never seen this fully applied. More often than not, it goes the opposite way round with a design resulting in an estimate which then determines the budget. The key point here that differentiates appetite from just a deadline is that it cannot be moved, only missed. So if you commit 6 weeks to an idea and 6 weeks later it's not ready, then you don't keep going. You chalk it up as a failure, the shaping wasn't good enough so the development team were not able to build the solution. But the appetite has been used up so you move on, If the idea is still seen as valuable, or the problem still an issue it can be reshaped, or a different solution shaped for the same problem and then that can compete for an appetite again further down the line. This, to me, sounds incredible. So incredible in fact, that the sceptic in me questions whether any company can be genuinely doing it.

Chapter 3 in the shape up book is titled "Set Boundaries", nothing in this is particularly new, its basically the same concept as MVP. In software development the term MVP is bandied about with careless abandon. In my experience the so called minimum viable product always gets padded with bells and whistles.

Without a time limit, there’s always a better version.

With Triathlog, Re-reading the chapter in the context of the scope of the app I had, it was immediately obvious that I was adding numerous bells and whistles. In the interest of my experiment I ruthlessly out-scoped anything that wasn't absolutely essential. Functionalities that would be nice were dropped until I got to the three essential aspects comprising the core flow of what I wanted to build.

1. Create Routes
2. Record Workouts
3. Analyse Workouts

The out-scoped ideas were not abandoned for ever, I just made the decision that I could launch without them, gpx import, sharing workouts, registration and login, backup of data, strava integration, stopping workouts form the notification bar, changing settings for analysis are all features I can add later in follow up releases. I could get user feedback to inform the priority of these items and also get new ideas that might be more important than those.

Tooling

Basecamp, the authors of the shape up method also sell a software solution design for implementing it. It would have been ideal to play around with in that, but I couldn't really justify putting the money up just for my own curiosity.

Instead I used pen and paper for breadboarding, and Asana to organise the tasks. Asana provided all the functionality I needed in an easy to consume way. I was really impressed and will definitely be using it again. Below is a screenshot of the Triathlog Asana board. You can see there are sections for each of my three core aspects which can be collapsed and expanded. Within each section I break down the work into smaller tasks. To each task I assign a priority with high priority equating to MVP scope. I can sort or filter by priority and by done/ not done. Meaning I can quickly see the overall picture of what is left to reach the MVP scope.

Originally I had intended to write Triahtlog in Swift for iOS, but in order to expedite releasing something, I built it for android first since I am far more proficient in Kotlin. I also used android architecture components from jetpack with an MVVM architecture, essentially all the steps I could take to minimise the time to production and be able to verify the concept.

Release

Once I had completed all of the MVP tasks I had a working app, I tested it out with a few runs and rides (the onset of winter meant it was too cold for swimming by the then). There were a couple of bugs I considered critical and spent time fixing For the non critical ones I just recorded them to the Asana board to be fixed later. Then all that was left was to create the graphics/content and submit the release to google play.

When it comes to next steps, I am at least keen to address the bugs in the app and add a couple of the missing features that I pushed out of the MVP. How far beyond that I will take the development of the app really depends on whether anyone else wants to use it.

With regard to the Shape up method, I can see a few ideas and techniques that could potentially be brought into Naveo. Breadboarding is something that could easily be applied in a limited setting to evaluate. If it goes well and I get buy in from others then I believe could be of real benefit to our processes. The full scale idea of setting appetites may be a step to far for all our stakeholders but perhaps some of the notions could be applied, for example having a pitch for each product functionality might give us a helping hand with backlog prioritisation.

I set out to explore this new approach to developing a product because the idea got me excited. Now after giving it a go I am still excited, I will certainly take these principles in my next hobby project and I hope in future to be able to explore them more fully in a professional setting.