It seems like we have come to a milestone in the weekly book club. We finished up Part 1: Shaping, and the verbiage from the book has infiltrated our daily language. I wouldn't say this is necessarily a bad thing, as we all now have a shared language to communicate our pain points, and our successes.
Chapter 4 Find the Elements
I'll be frankt, and say that the discussion for chapter 4 Finding the Elements wasn't invigorating. That isn't to say it isn't a valuable read, but for us it was an easy thing to say this makes sense.
The main concepts to understand is this process is a piece of time that we made the decision to invest in starting the shaping process. It doesn't mean we have committed to the idea, it just means that we evaluated the idea and said that it was worth our time to even begin to explore it in a rough way. All of the other steps can be interchangeable to work with how our teams function.
Chapter 5 Risks and Rabbit Holes
"As shapers, we’re thinking less about the ultimate design and more about basic quality and risk"
Have you ever worked a feature or ticket that has multiple pitfalls, rewrites, or blockers? In chapter four we got a rough outline of the feature, but here in chapter five we start to poke holes in it, and dive down the rabbit holes. They give a great example as to why you want to do this before the process. What it comes down to is we only are working this feature because we think it is a valuable use of our time right now, and it's value is directly tied to the amount of time we are willing to work on it. If we begin to work a feature and the timeline expands is it really worth it in the end?
A huge stand out for our team, even outside of the shaping process, is declaring items out of bounds. These ideas and features are nice to have, but the continual add on either means we didn't plan well enough, or we are adding nice to haves. Nice to haves are valid, but as extra features if we can get to them, and then backlog items.
Chapter Six The Pitch
The last chapter in Part 1 sparked an overall discussion on our team of how this could be valuable for our team.
The most vigorously debated topic was the idea of how would implement this without violating our teams core belief that measurement of work output for developers for measurement sake is a waste of time. There was one positive to the measurement of work, and when it is done correctly it allows the business side to understand how long things are going to take. The caveat to that is when you measure work output correctly it doesn't increase the efficiency of the developer. Now when you measure it wrong developer efficiency is still the same, but "Having numbers that aren’t real causes us to have a false sense of security, and then we make huge decisions based on those fake assumptions."
Regardless of implementing an accurate measurement system the team walked away wanting to try either the entirety of the Shapeup process, one fell swoop and we are doing a new process, or to figure out how to work the ethos of more shaped work before our fingers hit the keyboard.
Any kind of shaping process has the benefit of increasing the effectiveness of the developer, if done correctly. Having a source of truth(something like a pitch) for all decisions allows stakeholders to know what is the plan moving forward with a feature. Addressing complicated logic in that feature becomes a snapshot that developers can go back to when looking at past features and it helps the developer offload their mental ram. When you discuss something in person multiple people may need to know about the discussion, or fast ideas and hard decisions were made but not written down. As a developer keeping that all in our mental ram is difficult, as a stakeholder keeping that plus everything else is difficult.
Me personal thoughts on Part 1.
While reading the book it is starting to feel like this is a recipe for operational success. We are growing and evolving as a company and just like the founder can experience the founder problem, our processes may get stuck unless we figure out how to evolve with the companies growth. This isn't just top line growth, but also employee tenure, the transition to a hybrid workforce, and the increase in new developers joining the team to name a few.
In my mind getting a process of business planning that takes mostly synchronous communication, and moves to using asynchronous communication is a must for us going forward.
Signing off for now, but hit us up in the comments with suggestions for the transition, questions on our thoughts, and discussion for how to become a little better.
Top comments (0)