Assurant Labs is continually exploring new methods to improve our process. In the past, we improved by attending conferences, creating office-wide book clubs, and participating in workshops. One of our past workshops involved learning the Jobs-to-be-Done method with Bob Moesta. Among other revelations while at The Re-Wired Group’s office in Detroit, we had the opportunity to chat with Ryan Singer via conference call. During the call, we learned how Jobs-to-be-Done impacted Basecamp. We left the workshop excited and eager to incorporate Jobs-to-be-Done into our process.
While Jobs-to-be-Done improved our user research process, it did not change the disturbances we experience while building software. So when “Shape Up: Stop Running in Circles and Ship Work that Matters” by Ryan Singer caught our attention, we decided to start a new book club. “Shape Up” is exactly as it’s pitched — a book that illustrates Basecamp’s process, outlines how teams can identify what work matters, and presents guidelines for shipping work in an effective manner. Basecamp’s “Shape Up” process is split into three sections: shaping, betting, and building.
During the shaping phase, our team gravitated towards gauging appetite, breadboarding, and pitch-writing topics. The idea of assessing the appetite for a project resonated because we rarely ask, “How much time do we want to spend?” or “How much is this idea worth?” Instead, we jump right into trying to find a solution and try to estimate how long the solution will take to build. This leads to overly complex solutions that we rush to implement. We found it refreshing that simply questioning our appetite for a given problem could change our perspective about what is enough to solve a problem.
Breadboarding was another theme within the shaping process that we found interesting. As a team, we are guilty of jumping into hi-fi mockups without understanding the entire background. This leads to creating multiple versions that eventually fatigue the team. Breadboarding could open up the conversation to involved parties before jumping into creating a solution.
Next, we loved the idea of pitch writing! Having a tangible artifact of an idea with scope guardrails and a defined appetite to reference during our build process could help keep stakeholders and teams in check and pointed toward a common goal.
The next phase in Basecamp’s process is betting. We were intrigued by the idea that stakeholders would gather to review various pitches and make bets on what teams would work on next. This creates a clear understanding of what work needs to be delivered and records expectations. This could help the team and stakeholders form common ground by understanding scope, potential rabbit holes, and appetite. We thought having a tangible document that is easily accessible during build and release phases could be really powerful.
We couldn’t believe that during the betting phase, Basecamp doesn’t spend hours combing through a backlog to decide what work would be next. Although we doubt we could drop our backlog like Basecamp, it did introduce the following idea. If it’s truly something important, it will come back as a reminder often; if it doesn’t come back, it must not be truly important. We plan to keep this simple idea in mind while prioritizing work.
Basecamp’s ability to work in six-week cycles was our next big epiphany. All bets are scoped so teams can design, build, and test a problem all within six weeks. This creates the ability to work quickly and make trade-offs to get the work completed. If the work extends past six weeks, it “breaks the circuit” and creates the opportunity to re-examine aspects of the bet before deciding if it should move forward. Assurant Labs works in two-week cycles and allows work to carry over to the following cycle which opens us up to scope-creep issues.
During the building phase, Project Managers at Basecamp are hands-off. Assurant Labs Manager’s appreciated Basecamp’s theory of hill charts. They didn’t need to badger their team about when something would be completed but could easily see on a hill chart when something wasn’t moving forward and could interject before a looming deadline. Designers and Developers liked Basecamps build theory because they were in full control to create tasks and solve the problem as they see fit while using the pitch for scope. While work is being completed by the team, Managers have time to create the next set of pitches.
Overall, we found the book to be informative and our book club created an environment for us to talk openly about our process. Most importantly, we learned that we were not alone. Basecamp went through some of the exact same issues that we experience and they were able to incorporate a process for alleviating those issues. However, we wish Ryan would have included information about Basecamp’s user research process. How do they leverage Jobs-to-be-Done and other user research techniques? Where does research fall in their process? Who does the research?
Although we aren’t entirely sure it would be possible to incorporate all of the Shape Up process, due to Basecamp having a different business model and company structure than our own, we plan to start incorporating some of the highlighted themes into our process. Lastly, we want to extend a big thank you to Ryan for providing a (Free!) look into what makes Basecamp successful!