If these points sound familiar, here's a fun way to structure a quarter. It's a nice change of pace and helps a team go through the "full cycle" of learning, building, measuring, learning, etc.
A perfect example of a combination lifecycle that increases agility: iterative and incremental without being "agile." I really like the focus of "Make this the only thing." Thanks.
We switched from "rigid" quarterly planning (e.g. lets see what we can fit into this quarter in the beginning of this quarter) to a more "continuous" quarterly planning (e.g. let's meet once or twice a quarter to understand the progress we have made and the adjustments we need to the direction we decided to go last time we met).
The main issue with the former was that each team was in a very different phase when the (calendar) quarter started - some had perhaps just completed their main project(s), but some were in the middle of a project and their flow was distracted since at least of the team members needed to make plans for the next quarter. The other major problem was that all those predictions (what would fit next quarter or not) needed to be done in a very small timeframe (e.g. 2 weeks) so they were very rough guesses anyway. And things may change drastically when you look deeper. The PMs could do their part better - as they could do early discovery while engineering was still delivering the previous project. However, this did not help much as engineering was still needed to discuss the potential solutions, level of effort, etc.
Great read, John! I have never seen this in practice myself but I really resonated with the idea. I think the initial focus on discovery is very important as it reduces guessing and wasted time developing the wrong thing. I like the fact that the main build phase is time boxed as it forces you to prioritize what truly matters for the end user. Having time to iterate and implement the feedback is mandatory.
Focusing on one single thing for a full quarter seems risky. I see that you can iterate within a single quarter but it is still addressing one need or problem.
Are we assuming that we are already working on a valid problem space and we are primarily focused on finding the right solution? If so, does this mean we actually need to separately explore and validate problems continuously in parallel so that we have ideas to execute on in the following quarters?
How do we fit in tech debt, paper cuts and bug fixes into this model?
That sounds very similar to 2d PIPE, 3x2w iterations, 2w ideate and plan as in SAFe. However, in that setting, there's a much larger share dedicated to 'get something out' (~46.2% vs. 67.5%, considering there's some other things happening in SAFe during that time as well).
Nice iteration of Shape Up!
Had exactly the same thought. The founders have written and shared a lot about their thoughts.
For readers who are not familiar with it, you can read more about Shape Up in detail here: https://basecamp.com/shapeup
Also found a nice video introduction from Ryan himself about it: https://youtu.be/h_8M23wVjXk?si=_1HbogtNpZueXmnM
Benedikt and Patrick
You both might like my review of Shape Up.
I see this post as connected to ideas that largely pre-dated Shaped Up but which Ryan did an amazing job of codifying in their context.
https://medium.com/@johnpcutler/review-notes-shape-up-2c2bde31fc8a
A perfect example of a combination lifecycle that increases agility: iterative and incremental without being "agile." I really like the focus of "Make this the only thing." Thanks.
We switched from "rigid" quarterly planning (e.g. lets see what we can fit into this quarter in the beginning of this quarter) to a more "continuous" quarterly planning (e.g. let's meet once or twice a quarter to understand the progress we have made and the adjustments we need to the direction we decided to go last time we met).
The main issue with the former was that each team was in a very different phase when the (calendar) quarter started - some had perhaps just completed their main project(s), but some were in the middle of a project and their flow was distracted since at least of the team members needed to make plans for the next quarter. The other major problem was that all those predictions (what would fit next quarter or not) needed to be done in a very small timeframe (e.g. 2 weeks) so they were very rough guesses anyway. And things may change drastically when you look deeper. The PMs could do their part better - as they could do early discovery while engineering was still delivering the previous project. However, this did not help much as engineering was still needed to discuss the potential solutions, level of effort, etc.
Great read, John! I have never seen this in practice myself but I really resonated with the idea. I think the initial focus on discovery is very important as it reduces guessing and wasted time developing the wrong thing. I like the fact that the main build phase is time boxed as it forces you to prioritize what truly matters for the end user. Having time to iterate and implement the feedback is mandatory.
Focusing on one single thing for a full quarter seems risky. I see that you can iterate within a single quarter but it is still addressing one need or problem.
Are we assuming that we are already working on a valid problem space and we are primarily focused on finding the right solution? If so, does this mean we actually need to separately explore and validate problems continuously in parallel so that we have ideas to execute on in the following quarters?
How do we fit in tech debt, paper cuts and bug fixes into this model?
That sounds very similar to 2d PIPE, 3x2w iterations, 2w ideate and plan as in SAFe. However, in that setting, there's a much larger share dedicated to 'get something out' (~46.2% vs. 67.5%, considering there's some other things happening in SAFe during that time as well).