Although Shape Up argues for iterations (6 weeks), like Scrum and other Agile frameworks, Shape Up makes the same mistake we've made in the software industry for decades.
Shape Up assumes that we know what needs to be done,and can agree “something is possible in 6 weeks” if we look “enough” (unclearly defined) about requirements.
This is nothing new. We've had Requirements Engineering as a practice and discipline for software for decades. Short story: they don't lead to better estimates, and in some cases not even to better requirements.
Shape Up does have very good ideas, like the idea they call “appetite”, or “how much should we spend on this idea?”. That is a great step towards the “invest in software” concept I've also been talking about for a few years.
However, I don't believe that the Shape Up requirements management process will solve the estimation problem. Even if they claim to do that by “shaping” something to be 6 weeks if work.
When I heard about Shape Up my first thought was that it nicely fills some gaps in Scrum:
- It's more product oriented,
- inversion of the mindset from fixed scope to fixed time (and all its pros that you described)
- puts more emphasis on product-design-engineering collaboration (while in Scrum Product Owner is supposed to create and prioritize the backlog of tasks, and engineering is supposed to realize the ticketss. But maybe this is just poorly implemented Scrum? What would you say @Vasco?*)
But when I think about it more carefully I think I tend to agree with Vasco's points:
- how many organizations out there would allow the engineering team work for 6 weeks just on the one thing?
- Could we just call it Scaled Waterfall Framework? Joke, but the methodology assumes we can scope the work upfront for 6 weeks and not iterate and react to the information/feedback discovered during the build phase. Which is exactly why Scrum was invented, in my understanding.
- When it comes to the estimations: do you think there is actually any difference between estimating task's time and estimating possible scope for the time-box?
In my opinion Shape Up introduces interesting tools for product team (apetite, shaping) but I am not convinced about their actual process framework. I think there is a huge room for Shape Up and Scrum to work together.
* and there is another problem: scrum is being poorly implemented in majority of cases so might Shape Up be. So maybe the question is not about the framework (scrum) itself being wrong, but it's distributions and quality assurance. If thats the case: new framework (shape up) introduction is not the solution (rather just like in software itself: rewrite something to encounter the same issues eventually)
These are my thoughts as of today. I hope I managed to give it a good enough structure.
It is a very interesting topic and a lot of discussions ahead. Thanks Rafa for creating just another space for it.
I would only add that Agile software development is built on the idea of trying ideas out in practice, and then learning from it.
If a team adopts Shape Up, they should define what benefits they are looking for and then measure the outcomes, to see if they get the benefits they wanted.
I'm pretty much in the same boat. I like the Shape Up ideas but I haven't used the method yet and I wonder how that would work in many organizations that might differ greatly from Basecamp. I would love to give a try one day.
I hope people that tried it can join with their opinions!
Thank you Max and Vasco for your interesting thoughts!
Thanks for sharing. The story at the beginning is very relatable. These communication mistakes are common among junior PMs and TLs who just want to get things done!
I love the idea of moving away from estimations and falling into that classic trap of PM vs Engineering tussle. Shaping seems to be the way to go - and I’ve added Shape Up to my reading list, thank you Rafa!
A note on Shape.
Although Shape Up argues for iterations (6 weeks), like Scrum and other Agile frameworks, Shape Up makes the same mistake we've made in the software industry for decades.
Shape Up assumes that we know what needs to be done,and can agree “something is possible in 6 weeks” if we look “enough” (unclearly defined) about requirements.
This is nothing new. We've had Requirements Engineering as a practice and discipline for software for decades. Short story: they don't lead to better estimates, and in some cases not even to better requirements.
Shape Up does have very good ideas, like the idea they call “appetite”, or “how much should we spend on this idea?”. That is a great step towards the “invest in software” concept I've also been talking about for a few years.
However, I don't believe that the Shape Up requirements management process will solve the estimation problem. Even if they claim to do that by “shaping” something to be 6 weeks if work.
That’s an interesting point, Vasco.
Shaping is not magic. It’s about finding those trade-offs to deliver in such time box (appetite), usually 6 weeks by default.
There is a 3rd point about Shape Up I haven’t mentioned in the post and it’s the fact that a shaped project deadline cannot be extended.
That’s a bit radical but it seems to work for Basecamp as it’s the sign they failed at shaping (aka estimating such 6-week's project/feature).
What’s your view on this?
When I heard about Shape Up my first thought was that it nicely fills some gaps in Scrum:
- It's more product oriented,
- inversion of the mindset from fixed scope to fixed time (and all its pros that you described)
- puts more emphasis on product-design-engineering collaboration (while in Scrum Product Owner is supposed to create and prioritize the backlog of tasks, and engineering is supposed to realize the ticketss. But maybe this is just poorly implemented Scrum? What would you say @Vasco?*)
But when I think about it more carefully I think I tend to agree with Vasco's points:
- how many organizations out there would allow the engineering team work for 6 weeks just on the one thing?
- Could we just call it Scaled Waterfall Framework? Joke, but the methodology assumes we can scope the work upfront for 6 weeks and not iterate and react to the information/feedback discovered during the build phase. Which is exactly why Scrum was invented, in my understanding.
- When it comes to the estimations: do you think there is actually any difference between estimating task's time and estimating possible scope for the time-box?
In my opinion Shape Up introduces interesting tools for product team (apetite, shaping) but I am not convinced about their actual process framework. I think there is a huge room for Shape Up and Scrum to work together.
* and there is another problem: scrum is being poorly implemented in majority of cases so might Shape Up be. So maybe the question is not about the framework (scrum) itself being wrong, but it's distributions and quality assurance. If thats the case: new framework (shape up) introduction is not the solution (rather just like in software itself: rewrite something to encounter the same issues eventually)
These are my thoughts as of today. I hope I managed to give it a good enough structure.
It is a very interesting topic and a lot of discussions ahead. Thanks Rafa for creating just another space for it.
I would only add that Agile software development is built on the idea of trying ideas out in practice, and then learning from it.
If a team adopts Shape Up, they should define what benefits they are looking for and then measure the outcomes, to see if they get the benefits they wanted.
Experiment, assess/retrospect, adapt.
Thank you, Max, for your insightful questions.
I'm pretty much in the same boat. I like the Shape Up ideas but I haven't used the method yet and I wonder how that would work in many organizations that might differ greatly from Basecamp. I would love to give a try one day.
I hope people that tried it can join with their opinions!
Thank you Max and Vasco for your interesting thoughts!
Thanks for sharing. The story at the beginning is very relatable. These communication mistakes are common among junior PMs and TLs who just want to get things done!
They usually miss the bigger picture!
I love the idea of moving away from estimations and falling into that classic trap of PM vs Engineering tussle. Shaping seems to be the way to go - and I’ve added Shape Up to my reading list, thank you Rafa!
It’s a brilliant book! Freely available online and easily readable over a weekend! Thanks for sharing your thoughts, Gaurav!