I work in the tech company, where we introduced over a year ago Shape Up. I noticed Shape Up is not precisely an Agile framework - it lacks a reactionary element and definitely is not based on an empirical approach. It puts a bold line on the implementation level disregarding the fact that the art of developing software varies from environment to environment, and its characteristics are defined by underlying technologies, skills and many other factors. The working methodology should be the team-oriented process of research based on observation, not copying and pasting book content on a high level. And unfortunately, I don’t see Shape Up promoting such an approach.
Do you have stories that Shape Up didn’t work the way you expected? How did you approach the problems? Do you take its principles literally or are you free for interpretation?
In my company, there is always 1 influential individual who is always pushing everyone to follow Shape Up principles word by word.
Here is a little blog I have highlighted my thought, observations, problems and concerns regarding Shape Up
Nice to meet you! I started to write some posts about how we made local adaptations to Shape Up to make it work for our context. Have a look here: https://www.linkedin.com/in/nckhell/recent-activity/all/. There might be some topics there that ring a bell for you.
With regard to the reactionary element, we experienced that too and we found a setup that worked for us. I will be writing about that in a future post but the TL;DR:
We split our engineering team in two: a team “Don’t f*ck up” (leave alone) and a team “Grow quickly” (respond quickly)
Team “Don’t f*ck up” focuses on strategic initiatives. Features we want to build, strategic problems/needs we want to solve. We use Shape Up (pitches, betting, …) to drive the product development process for this team.
Team “Grow quickly” can do more reactive, ad-hoc work like solving a specific problem for a customer, or fixing a bug that cannot wait until cooldown but has a significant impact on our users, … Engineers in this team are really close to the actual customer. We try to keep the initiatives in this team rather small, if it cannot be done in max 2-3 days, then it should be a pitch and then it needs to go through the betting table.
In terms of resource allocation, I would say that 75% of resources are allocated to team “Don’t f*ck up” and 25% to team “Grow quickly”. But note that this can change based on the context we are in.
The original idea came from https://www.startupcorestrengths.com/, they have a pretty good newsletter with some fabulous content. All credits to them, below you can find the original email for context.
I feel that the Shape Up architects have never understood the principles of the agile working environment. The simple yet common knowledge is that most of the problems you get to know only when you face them.
The Shape Up book actually agrees with you. You can find this sentence in the book, literally:
The way to really figure out what needs to be done is to start doing real work.
The shaping process is not supposed to be a top down exercise isolated from the code. In fact, Ryan just posted this today (uncanny timing):
The next step is spiking some unknowns that require heads-down time. Then “packaging” what we figured out into a readable document that captures everything important. That package is what we’ll carry forward into a time box for delivery.
Notice how spiking is meant to be part of shaping? You’re supposed to spend some time doing a small amount of “real work” during the shaping phase.
Also from your post:
The strict 6-week cycle puts a lot of pressure on the quality of the final result, which can be damaging. […] There will never be time to take care of finishing up and polishing the product.
The strict 6-week cycle is supposed to pressure the shaper into getting their scope hammering right upfront (not easy by any means), instead of pressure the delivery team to cut back on the quality of their work. If done correctly the strict deadline shouldn’t stress the delivery team. We happened to publish a post that touches this very topic recently (again, uncanny timing).
Having to do a lot of polish work is a sign that the shaper hasn’t defined a clear boundary, which results in the delivery team having to touch endless dependencies. This post about Noise Factors vs Control Factors from Ryan is a great resource on how to break off dependencies skilfully.
Thanks for your reply. I don’t see the book agreeing with me at all. What needs to be done and dealing with the problems during the execution are not the same. Dealing with problems during the work requires reactive measures that I stated clearly Shape Up completely lacks them.
In all respect, too many hypotheses, and too much dancing around the fire. I am not going to comment about spiking, because it more looks like plastering the problem rather than fixing it at its core. For me, the trouble is that the Shape Up approach doesn’t teach an empirical approach, but rather encourages us to follow what Ryan says. As stated in my blog
integrating methodologies should be a team-oriented process of research based on observation, not copying and pasting book content on a high level.
Does Ryan know the characteristic of my team? Or does he assumes everything could be dealt with in one measure?
Team GQ requires a “hold my beer” mindset, needs to be able to react quickly, and has a higher risk appetite.
“Hold my beer” conveys the mindset really well
At a previous workplace we had normal project teams and a moonshot team. The latter was more “gung-ho” and were tasked to try and find big wins quickly.
Also keep in mind that team DFU and team GQ attract very different personalities and require a different mindset.
This is an important takeaway. Couldn’t agree more. People who loved backend and AWS stuff didn’t want to be in the moonshot team, unlike people who loved metrics and being customer-centric.
