2 Week bookclub recap

Chapter 2 and 3 of ShapeUp recap.

What a difference a single chapter makes. In the past two weeks LoadUp Engineers have discussed Chapter 2 and Chapter 3 of ShapeUp. As a team we went from ending our discussion of Chapter 2 wondering how can we apply this 'shaping' thing to our process of ticket creation , to embracing the idea of 'shaping' our own shaping process. I know it's redundant, but it is what we are doing.

CH. 2 Principles of Shaping

The Principles of Shaping ends with a great synopsis of steps to shaping.

1. Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
2. Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
3. Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
4. Write the pitch. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.

As a team we weren't excited about the process yet after reading this chapter. We talked a lot about in our past experience the pain of having project requirements and wireframes that were too concrete. From the developer perspective being handed a picture perfect wireframe extended project timelines, and potentially led to poorly written code. Being handed the right level of detail that allows the developer to come up with a better fit solution brings a product to the table faster, and generally is more maintainable. Something none of us had encountered was the idea that a designer being handed work that is too shaped will have a hard time creating something innovative.

On the other side of things not taking the time to have a process that 'shapes' the work is equally a timesuck. On our team we err more towards the not shaped enough, and also don't have a strong foundation of who should be 'shaping' the work. This style of development is exactly what a startup needs. We are lean, agile, and work with Rails. In other words we get a lot done quickly. Fortunately we are growing out of the start up phase, and we are starting to look for the efficiencies we can gain by making sure our processes are fine tune. Just today we broached the subject again of specialization of tasks. I know it's corporate to think like Henry Ford, but it is true to nature that context switching, task switching, and in general jack of all trades is not as efficient as someone who specializes. The key is figuring out is it worth the investment cost to buy the new machinery when your current machinery can get the job done, albeit a bit slower.

If you are still reading I'm not going to talk about the idea of having two tracks here. It is mentioned in the chapter and we had an advocate for why this was important, but it wasn't until Chapter 3 that the team organically arrived here.

CH. 3 Set Boundaries

Drum roll, Light bulbs, and Developer teams making magic!

What a difference a single chapter, and single discussion can make. Really though we haven't changed anything yet, so did it really make a difference. As time progresses we will see if as a team we can begin to set Boundaries. The idea of not saying yes to a project right away, and taking the time to really understand it sparked rapid discussion that I will chronical for you.

1. We can now ask better questions
   By slowing down the process and setting a boundary as to when work is ready to start development we can ask better questions. When handed a task that isn't fully complete the looming deadline can prevent us from asking the right questions to really figure out what is needed.

2. Two tracks comes back!
   The idea of two tracks was talked about in the last chapter. Shaping of the work is completely separated from the actual development and design work. It was during our discussions of asking great questions, and discovering what the process looked like to do so that we ended up organically arriving at the two track concept. In our past we always had our developer mind on when asking questions, because we were thinking about our developer tasks. As Riaz put it we really need to be thinking more like a therapist when being asked to perform certain functions.

Case in point. The user(wife/husband) comes to us(developer/therapist) and says that the program(wife/husband) isn't doing the task it's supposed to be doing. Now at this point as a developer we start looking for bugs, checking the code, and coding out a solution to their pain point. The issue here is that the pain point ultimately was the the user wasn't communicating their needs to the program correctly. As a therapist you ask the questions of the surrounding situation. How was the user acting that day, what was the actual thing they were doing. This takes a different mindset, and is hard to do when context switching between developer and therapist. In the end it turns out that the User was doing something that could be automated and the solution written was a better long term fit.

1. Time Box the solution by it's value This one seemed to be a switch flip in our minds. Start the shaping process by asking how much time are we willing to invest in this idea. Really the question needs to be asked twice. How much time is it worth to shape this idea, and how much time is it worth to develop the idea. With those questions answered you can then ask what my opportunity cost is and begin the shaping process when it works for the company. The beauty of separating the two questions also separates the work. We now can work on development when it benefits the company. The shaping and development don't have to be coupled to each other anymore, and we can pivot our development epics based on new ideas and requirements.

The amount of time you are willing to spend will also change the solution that you are going to put out. If you have all the time in the world you will have the most feature rich, and probably bloated solution. If you are timeboxed you will only put in exactly what needs to get done, and can evaluate if the solution solves the issue or needs to be evaluated in how much time it is worth.

1. Lazy Evaluate like Functional James gets credit for this one. Taking the idea of a project being ready to develop and equating it to lazy evaluation. We have all these requirements and inputs and will start gathering them, but we won't start work until we have all the inputs our function requires. To us this means we can have the function of development waiting in the background as it is being fed inputs. Once it receives all the inputs required to start work it fires off and the development process starts.

The ultimate question at the end of this chapter is what are the required inputs to our lazy function? As a team this is something we are figuring out.

Stay Tuned, and as always we love the comments, questions, and discussion.