Framing before Shaping

1

Ryan published a new post:

This posts introduces a new Pattern called Framing that occurs before the whole Shaping process.
It’s about defining the context in order to find a Shape that can be presented for the Betting Table.

Also he renamed the idea of Pitch to Package, because a Pitch in the minds of people refer to a Sales Pitch and it acts better as an input to the process of Framing.

For me I think it’s a great name for the concept and also the picture explains very well the Patterns.
It defines that an important part of the work before should be to define an Outcome.

What do you think about this new concept?
Does this change your perspective on the work you are shaping ?

3 Likes
2

I like this new concept, it helps justify spending quality time on polishing the pitches. This separation of duties makes it clearer what each stage needs to accomplish before moving on.

1 Like
3

So this sounds like using a business/lean canvas, right? I feel the Shaping process should run in a 3 phases set up:

  1. Canvas/framing
  2. Shaping with key SMEs
  3. With team to check key entries/risks/etc.
4

Hey @EonNeon thanks for your reply!

  1. Isn’t a Canvas too much ? What we tend to do is just align what are the problems (with a little diagnose) or strategic ideas that we would like to try and how much time should we bet on it (2 weeks, 4 weeks, 6 weeks)

  2. Sorry I couldn’t follow, what did you mean with SMEs ?

5

Hey! A canvas to me means a one-pager, similar to the shape pitch format. SME= Subject Matter Expert.
What are your experiences on risk of too unrefined work ending up in more refine than build in the in cycle work, i.e. there was way more to refine than we estimated in betting, leaving little time to build (skewing the bell curve to the right).
There seems to be a need for a balance between right amount of shaping to allow optimal build?

1 Like
6

I try to shape things so they can be built, that’s why in cooldown I tend to meet with the developers that will be assigned to think about reducing this “Risky” things or at least think about alternatives if the main plan doesn’t work.

The systematized hand-off works really well as process to discover risky parts and prioritize them first in order to find alternatives ( “Reogrouping”) in the first 2 weeks.

Regarding de balance, as I’m a Shaper but also an experienced developer my pitches tend to not give too much freedom on the technical design.

I suggest that if you are not a technical expert when writing a pitch at least discuss it with a technical leader whose task is to write a Technical Appendix for the pitch.

What I learned how much specific are the Pitches also depends a lot on the expertise (and seniority) of the team who is building it.

7

Thanks for the reply! And reading through the article of Ryan, this basically sounds like what refinement should/would be in Agile. No real sizing/estimations though in this one, by choice or is there any high-over estimation done in this process?

8

Backlog refinement is fundamentally different vs. shaping because:

a) There’s no traditional product backlog in Shape Up
b) Refinement requires a “Definition of Ready” which often
– turns into a list of functional requirements
– requires the developers to estimate the work involved
c) It’s done with the development team

Traditional refinement uses the INVEST acronym as a best practice, so if all six are hit, the resulting user story is sort of analogous to a pitch. But in my experience, most refinement struggles with N (negotiable instead becomes a non-negotiable list of requirements) and E (because developer pre-work estimates are usually inaccurate).

In contrast, Shape Up does away with estimates completely. Instead, there is a pre-set appetite + circuit breaker to time-box development. By definition, shaped work has negotiation built in because shaped work allows for variable scope within the cycle. Finally, shaping and betting is done outside of the development team (at least, that is how Basecamp does it.)

9

I also think it’s critical to have teams comprised of more senior members because there is a lot of trust in the builders that they will be able to effectively break down the tasks, estimate the work, work through dependencies, and break the circuit if they will likely go over the appetite. Also, make critical decisions as they are building.

It is also helpful to create some form of a ‘preflight’ checklist for the Build Cycle and Cooldown Period so the teams are functioning well. One item could be checking in about Week Three if the scopes are working well for the builders.