0:00
[Music] welcome to Shapers and Builders the show
0:07
about better ways to deliver great software products today I'm speaking with Ryan Singer former head of strategy
0:14
at Basecamp Ryan who nearly every role in the product development stack during his 17-year
0:20
tenure with the company from UI design to programming to product management and
0:25
most recently product strategy in 2019 Ryan formalized The Way That Base Camp
0:31
was working into a framework that other companies could use resulting in the release of the book shape up stop
0:37
running in circles and ship work that matters since then a lot has happened and many teams have adopted and adapted
0:44
shaper Ryan in turn has taken these learnings from those teams to reshape the framework and decouple it more and
0:51
more from the specific context of Basecamp the bootstrapped and stable business with a high share of senior
0:57
people in our conversation we explore some of the initial reactions to shape up including common criticism of the
1:04
framework we then go deeper into the evolution of shape up 1.0 into the 2.0
1:10
version which Ryan is now teaching in this course shaping in real life you'll probably get the most out of this
1:17
interview if you're already somewhat familiar with the shape of framework if you want to catch up on context first
1:23
check the show notes for some links to get started I'm particularly excited to
1:28
Ryan on today because this episode actually kicks off the first season of the Shapers and Builders podcast where
1:34
I'll be speaking with teams of all sizes and stages to hear their stories of adopting shape up how and why they've
1:41
introduced it to their companies and the tweaks they've made along the way if you're curious to hear some real life
1:47
case studies of teams working with shape up make sure to subscribe and check out the other episodes of the show but
1:54
enough introduction let's get into the conversation [Music]
2:02
hey Ryan it's such a pleasure to be speaking to you again I want to talk to you about shape up today and how this
2:08
framework has evolved over the past three to four years so to start things off can you give us the 90-second
2:15
introduction to what shape up is oh good challenge
2:21
um well I usually start with uh why somebody would even get interested in it
2:28
um people usually get interested in shape up when the develop the development process they're using isn't
2:34
working so uh if you're using something like scrum and you're finding out that
2:40
you know there's a lot of meetings and there's a lot of time going by and there's Sprint after Sprint but stuff
2:46
actually isn't getting finished and you start to think okay is there another way that we can do our product development that's that's going to work better also
2:54
I see uh startups who are just kind of doing everything organically you know
3:00
without any structure at all but then they reach a certain stage where they start to grow and it's kind of like okay
3:06
now we need some process but we know that we don't want to just mindlessly you know file tickets and think that
3:13
that's also going to help us to actually ship quality work so it's usually either coming from a standpoint of like how can
3:20
we ship better or how can we kind of give the teams more autonomy so that
3:26
leadership has more time to work on other things and uh it's yeah stepping back from
3:32
this kind of typical agile thing that we've seen where it's like two weeks at a time and
3:38
very ticket based and instead of actually asking the question of what is it strategically that we want to do and
3:44
how do we put our heads together to solve the really important unknowns and have a kind of strategy about what it is
3:50
that we're going after and what it is that we're trying to build so uh actually bringing people together to do
3:58
what's called shaping which is like figuring out the overall architecture
4:03
and the key trade-offs of what we're going to build in such a way that the
4:09
build team actually has more freedom and more autonomy to make decisions inside
4:15
the delivery phase and they can actually get things done on time something like that you know I think
4:21
it's hard to it's hard to boil it down to 90 seconds but usually those are some
4:26
of the the factors that are driving people yeah perfect and we'll get into much more depth but you you publish the
4:33
book on Shape Up in 2019 and recently launched a course around it called
4:39
shaping in real life why was that necessary well you know the original
4:45
book Shape Up came out in 2019 and it formalized all the things that we
4:53
learned at base camp over the 17 years that I was there and
4:59
those things were you know when the book first came out there were a whole bunch of companies
5:06
that immediately adopted it you know they were like this makes perfect sense to us we can we're going to work in six
5:12
week Cycles like the book says we're going to do shaping before we start the the actual Cycles we're going to do cool
5:17
down like they did all the things that were in the book but then a lot of people started coming to me and saying oh we're doing parts of
5:25
shape up or we're trying to use pieces of it and what I understood was that the
5:30
companies who were just like base camp they were able to just take everything
5:35
in the book and run with it but companies who weren't like base camp uh
5:41
they weren't actually able to use it but they still needed it's funny they were
5:46
still trying and they were still kind of twisting it and adapting it so that it could be something that they could use
5:52
and when I say companies that were not like base camp what I mean is companies that were VC backed instead of
5:59
bootstrapped so they have different pressures companies that
6:05
have more of a gap between Junior and senior people instead of having mainly senior
6:12
people companies that are significantly larger where you have like a thousand people in
6:19
the organization instead of just 50 especially companies where
6:25
the ratio of designer to vet to developers is much different at base camp every single build team had a
6:31
dedicated full-time product designer somebody who could do interaction design and front-end design
6:38
and all that stuff and a lot of software companies have more of a one to ten ratio where there's you know like
6:45
10 for every 10 programmers is only one designer and sometimes even fewer than that and so a lot of the stuff that's in
6:52
the book doesn't translate directly for them so I had people reaching out to me again and again saying
6:59
how do we make this work for us and what I understood was that
7:04
instead of taking this single package where like you have to do all of these
7:09
things exactly as they're written that it was actually possible to break apart what's in the book into separate
7:17
individual practices that teams can adopt so what are different things that we can
7:22
do to shape what are different ways that we can create a time box for ourselves that's meaningful instead of just two
7:28
week Sprints and a lot of the things that kind of people thought were sacred uh turned out to be much more flexible
7:35
like the this length of the Cycles or
7:40
how you involve designers at which phase the latitude that you shape at whether
7:46
it's rough marker like this like fat marker sketch yeah or sometimes you actually need to Define more detail up
7:54
front sometimes you need to Define less detail up front so this like kind of setting the dial on what is the right
8:01
amount of information to include when you shape there's also some really interesting things that we found out
8:07
about you know in the original book we have What's called the betting table and there's
8:13
this idea that somehow a set of pitches are going to come to the betting table and then there's going to be a choice of
8:19
like which thing are we going to build in the next cycle but that actually presumes that there's
8:25
enough time to prepare and meaningfully shape multiple pitches right which very
8:31
often isn't the case at a lot of companies this was a luxury That Base Camp had so what we are what I often saw
8:37
actually was that teams who were trying to follow the base camp way but they didn't they weren't structured like base
8:43
camp they would end up very superficially shaping you know they would have like a
8:49
bunch of pitches but they weren't really getting into the nuts and bolts of why
8:54
is this viable and how is the hip bone going to connect to the leg bone and like what is the mechanism that we're actually going to make
9:01
they were much more like kind of like sales pitches you know here's a reason why we should add this
9:07
feature here's a reason why we should do this we should build something in response to this request we're always
9:12
getting from customers and um a lot of what we end up starting to
9:18
well like actually a lot of what this course teaches is how to really recognize the difference between just
9:24
making a sales pitch where the product team is saying here's why we should do something and then it all lands on the laps of the
9:31
developers and they have no idea what the real requirements are and you know what success or done looks like
9:37
and um stepping away from that and figuring out how do we actually put product and Engineering together in the
9:42
shaping session so that we have a more meaningful understanding of what we're really getting into and we actually start to make some trade-offs together
9:48
and understand what we're proposing yeah that makes a lot of sense and um so you mentioned who the course is for
9:55
um was that also what you then observed in the first cohort that you had and that this mix of people from larger
10:02
companies VC back kind of growth driven companies or was it still very much the
10:07
the core bootstrapped scene you know there what I saw was that um there were
10:14
some folks who originally fell into the core bootstrapped kind of group
10:19
but then since then there they've hired a lot more people and they've had to
10:24
deal with problems that they didn't have to deal with in the first place so we saw some folks who were originally very small bootstrap teams but since then
10:31
they've grown and now they have new new difficulties but actually the majority of folks who've come into the course
10:37
have been people from VC back companies from larger companies uh smaller teams
10:43
inside of bigger companies who are trying to make this work for them and do you hear from participants kind
10:50
of how they then are able to translate what they learn in the course in their teams because it's you know I assume
10:58
it's a big challenge knowing what you know and then applying that in your team going back home and and the team might
11:03
not have been in the course and have that context yeah that's interesting we're seeing
11:09
different things there for some people they have this a big aha moment so I've
11:14
had some cases where the the founders or somebody who's like VP of engineering or
11:21
somebody who's head of product they're saying in in the Q a during the course they're saying like oh wow I
11:28
didn't realize like what what we called shaping was actually just framing what we were going to do and we weren't
11:34
actually getting enough into the detail and like no wonder we were always having these problems in the build cycle right
11:39
like they were having kind of just these big like aha moments another thing was that we saw a lot of
11:45
people trying to shape asynchronously instead of actually putting their heads together into live shaping sessions
11:52
and there were some big ahas there too of like oh wow like okay so I'm gonna go back to my team and instead of sending
12:00
documents back and forth for discussion or for comments let I'm actually going to put this you know we talk about how
12:07
to choose a technical shaper in the course and there's people who say you know I I already know who represents
12:14
kind of the customer knowledge but here's now I have the technical person in mind and we're going to bring those
12:21
people together and ask them to do a shaping session and I'm really excited to try that so that's something that we hear so some people are able to just run
12:29
with it because they kind of see what they couldn't see before and they also
12:35
kind of understand the practices enough to kind of guide people through what a shaping session is going to look like and how they're going to actually run
12:41
that or how they're going to package the work differently that's also something
12:46
we talk about um the other thing is like taking things
12:52
for example from from the point where there's a shaped packaged piece of work that's ready to
12:59
go to giving that to a junior programmer and saying saying how can I actually trust them that they're going to be able
13:05
to run with this you know without a lot of management for six weeks you know we we teach for example the handoff
13:10
exercise there and those are that's that's the kind of thing where people go like oh I'm gonna go try that I think I
13:16
can see how to do that there are other cases where uh people have said that
13:21
this they want their teams to really learn this language
13:27
to be able to we talk about judging what room are we
13:33
in you know there's kind of this this mindset of like we're trying to do some work
13:39
and sometimes it's very clear what the problem is and we're just debating different solutions so we're kind of in
13:46
a shaping yeah phase sometimes we're trying to shape something and we're just going in circles because nobody can even
13:53
agree what the problem is and then that's the kind of thing where it's like oh we're not actually ready to
13:58
shape this we need to step back and frame what is the actual problem or build the business case for like why to
14:04
spend time on this problem instead of that problem because we're not agreeing on what's worth spending time on so
14:10
identifying the difference between when we're framing when we're shaping when we're spiking when we're in packaging
14:15
and when we're actually moving into delivery those are all kind of different kinds of
14:20
work where we're asking different questions and we're taking in different things that we've already solved to carry them
14:27
forward into the next step and some of the people want their whole teams to be able to speak that language
14:33
in order to start kind of better problem solving the different things that are going on in the development process yeah
14:39
so I've seen cases where folks have actually brought their whole team through so they said can we do a private
14:44
cohort and then they bring the whole team through uh and then and then they have you know six people or ten people
14:49
go through as a match to to to all get up to speed on the same language so then they can go into these framing sessions
14:57
and shaping sessions and they have more common language to actually get through that yeah after the book came out I
15:04
certainly felt a lot of reactions to it some were very positive um but some were also quite critical so
15:11
what I'd like to do with you is a quick fire round of the most common criticism or maybe misconceptions you tell us
15:18
right around Shape Up and get your take on these would you be
15:23
up for that yeah certainly okay so I have I have a list of five and I'm just
15:29
gonna read them out to you and then you can kind of react to them whichever way you see it
15:35
the first one I have here I call the lonely genius shaper and the the quote I
15:41
dug up here was it smacks at times of the genius solo designer crafting their Masterpiece and
15:48
doing the Deep work while the team executes I'm pretty sure sure that was not the intent but it's it is implied in
15:55
a couple of places that's a very good criticism you know
16:01
um what we've seen this is also coming to base what the experience at base camp
16:09
versus The Wider world we had the situation at base camp where
16:14
the people who were doing the shaping represented
16:19
three kind of very different areas of expertise when you're doing shaping someone has to
16:24
represent what is actually technically practical to do what is technically
16:30
possible so someone has to have deep technical knowledge someone has to understand what's actually valuable to
16:35
the customer you know someone has to understand the interaction design so these these
16:42
different areas that all have to come together in the shaping to come up with something that is going to be viable and
16:48
it's going to be fun to work on that's going to be meaningful yeah and we were in a situation where we had a lot of
16:55
those skills kind of in the same people so there were a lot of cases at base camp where one or two people
17:03
could lock themselves in a room shape a concept and bring it to the team and when we gave it to the team the team
17:09
wasn't saying oh you know here here we have another concept coming from product where they don't know what they're
17:14
talking about and they tell us that we should go build this right you know usually when that happens you see a really big disconnect where the product
17:21
people come up with an idea and then they make a whole bunch of drawings and stuff like that and then they bring it
17:27
to the technical people like here's your work and the technical people are like this isn't at all executable the way
17:33
that you think it is you know and that's of course that's a frustrating situation yeah now when the
17:39
person who's doing the shaping actually is really close to the technical people or even works with the technical people you know it can be that you give that
17:48
work to the technical people and they say awesome I'm really excited to work on this this is something that is doable
17:53
and makes a lot of sense to us and we're eager to start on it you know so the the
17:59
thing that's really important for teams to be successful possible with this is to bring the right people together into
18:07
the shaping sessions so at a minimum make sure that it's not just the the you
18:14
know the artist with the with the with the Beret who's going to make the giant figma drawing and then say here I've
18:20
solved it all right um but to have actually have the have the person who looks at it from the
18:26
design perspective and very important the the technical person in fact the
18:31
technical person is a is a huge critical piece of a successful shaping session
18:38
because what we're shaping is is a piece of software it's actually something that needs to get built so the technical
18:43
piece is critical to be there from the absolute beginning so
18:49
we usually talk about three roles you know bringing the the product person who really understands what the customer is
18:54
trying to do the design person who understands kind of what is going to make sense in terms of getting from A to
19:00
B in the interface and in the flows and then the technical person who understands what can be built what can
19:06
what we can execute and then the three of them can all make trade-offs together and then when specific questions come up
19:12
about what is viable or what is practical actually doing spikes and that might involve doing you know a little
19:19
bit of deeper work on the technical side to figure out if something that we think we're going to do in this concept is
19:25
actually something that's realistic or if there are unknowns there that are going to blow up right so yeah yeah I
19:32
think I think if you if you take the shaping and you think that that now like our designers or our product people are
19:38
going to solve it all and give it to the technical people that's definitely a that's definitely a mistake and we need
19:43
to bring the technical people into the shaping process but recognize that it's a different type of work that happens
19:49
and it's under a different clock it's not something where we when we're inside of a Time boxing we've committed to do a
19:56
project that clock is ticking right versus when we're in the shaping phase we can throw out we can throw out the
20:03
whole project and completely take a right turn and go down a different direction because of something that we
20:08
discovered together so it's not as much about the shaper but it's about the
20:14
activity of shaping needing to happen right yes exactly it's about not just
20:20
going into a delivery time box where we're supposed to be shipping something
20:26
when we don't actually know what it is that we're shipping and we haven't done the we haven't done the diligence to
20:31
make sure that we know what we're doing and that it's viable yeah so the second item I have on my
20:38
list is In Shape Up teams aren't really empowered and the quote I have for you
20:43
is I do worry that it is heavily biased to certain perspectives about the role
20:49
of designers leaders teams Etc it's surprisingly disempowering approach for
20:55
a team but they make a point of talking about empowering teams
21:01
so I I'm not sure if if they if somebody was speaking from experience when they
21:07
said that they found it disempowering because what we hear from the teams who adopt it is is very much the opposite
21:13
we're not trying to sell anything here as empowering this is this is a quote from people who've adopted it you know a
21:21
standard approach is figure out what we're going to do so a
21:27
lot of software companies what happens there's either a main even if they're they say that they're agile even if
21:32
they're scrum somebody is coming up with the concept of what's going to get built yeah it's happening somehow and that's
21:40
either in the form of an architecture from a senior technical person or it might be a bunch of figma files from
21:46
designers somebody is creating something that is like the thing we're going to go build and what happens on a typical team today
21:54
is that work then gets split into tickets and those tickets get assigned and that's what the technical people are
22:01
responsible to do they're responsible for completing tickets yeah in The Shape Up model there's no step of assigning of
22:10
breaking the work into tickets and then this is your ticket and that's what you're responsible for the team is given
22:16
the the overall concept of this is the thing that we think we can go build so
22:22
the the team is given the shaped concept and then they work out for themselves what the actual tasks are
22:29
how they want to implement that they make trade-offs there's latitude
22:34
for them to make changes to what was defined in the shape work so when we
22:39
talk about empowerment I think it's mainly contrasted against this environment where you're just
22:46
executing tickets and then somehow the tickets are all supposed to fit together you know like somebody created all the
22:52
Lego bricks for you and your job is just to make them so that they all snap together in the end instead what we have
22:58
is that the team is actually responsible for the whole thing coming together and they are figuring out how to integrate
23:06
and how to design all the different pieces so that this thing actually does what it was intended to do
23:12
yeah I think it the criticism I mean I'm speculating 100 here but I think it
23:19
might come from um from a perspective where you know now there's kind of streams streams of
23:25
thought within the product community that are pushing Engineers to be super involved in in Discovery speaking with
23:32
customers and spending time on that side of kind of of the product uh Turf if you
23:38
will um which wouldn't be part of kind of the standard Shape Up setup right
23:44
that I I actually think it is part of the standard shape of setup and it just doesn't didn't come through clearly
23:50
enough in the book if you really read care if you really read carefully you will see that
23:56
from the very introduction shaping is described as an activity that integrates
24:02
design product and Technical knowledge there's no way that you can shape
24:08
something if you don't have the technical factor in there and that has to be there absolutely it's just that I
24:15
don't think I made the point clearly enough in the book I said that the shaper needs to be technically literate
24:20
and I think that that didn't go far enough um you know if you're working in an
24:27
environment where the product is mostly kind of just reading and writing from a database and the interface layer is
24:33
really thin then technical literacy is actually maybe enough but in a lot of cases what people are
24:40
working on you know that's it's it's not so simple fundamentally though you you
24:45
need to have that technical knowledge all the way at the beginning of the process when you're figuring out is this
24:50
a viable path that we want to go down or not when you're shaping that's That's essential yeah the third item I have
24:57
here is it works because of the stability slash stagnation at base camp you know
25:04
base camp is growing but stable small team no Venture back growth goals very tight founding group a single product
25:11
with a narrow scope so there's truth to that it the the
25:17
specific practices that the book argues six week long Cycles
25:24
two weeks of cooldown uh shaping multiple pitches during uh in
25:31
parallel and then and then bringing those to the betting table to decide for the next cycle
25:36
um no road map at all basically all of those those specifics are completely
25:43
related I think stagnation isn't fair but they are um they they completely are
25:49
related to the fact that base camp was bootstrapped and base camp ran on yeah had the luxury of doing things uh
25:56
completely on their own schedule and any company who's bootstrapped whether you
26:01
are um you know fat and happy because you've reached a lot of success or if you are
26:07
you know I did it recently I did a project where we had one part-time
26:12
programmer and we had very very little budget it was this like shoestring
26:17
budget with one part-time programmer but we were bootstrapped and it's funny because it felt like working at base
26:23
camp because we could go on as long as we wanted you know there was no external pressure that we had to finish because
26:31
our costs were so low and that everything was so was so small that it if we wanted to just keep going three
26:38
more Cycles because we thought it was meaningful that wasn't a problem for us so being self-funded and and having
26:45
really low costs this enables you to work that way
26:51
um so I think that that objection is coming more for probably from somebody who's in an environment where they have more external pressures yeah and of
26:58
course if you have investors you cannot just go cycle after cycle six weeks at a time
27:05
doing whatever you feel like right whatever feels meaningful to you
27:10
and in that situation this is where we actually see a lot of teams doing shape up but
27:17
varying the length of the cycle actually setting the time box ad hoc on a per
27:23
project basis so they might say look here's something that's burning that's
27:29
really critical that's important that we need to do we want to be able to get it done in the next three weeks
27:35
now but if we just go and talk to the developers and sit around a table and then start building something we know
27:42
that our likelihood of actually shipping at the end of the three weeks isn't high enough and this is likely to just spiral
27:49
out of control or you know what I mean we're gonna get we're going to get into some technical area that was more
27:54
complicated than we thought where there's going to be miscommunications blah blah so you can be under tight
28:00
deadlines two weeks three weeks and still say okay but in order to use
28:06
those two or three weeks effectively and ship something at the end of it we need
28:11
to do a shaping session first right we need to actually be clear about what it
28:16
is that we're betting on so I think that's more a reaction to the pacing and the Cadence in the six weeks than it is
28:22
to the actual uh to the actual process the next thing I have on here is is a
28:29
bit connected and it says there's no way I could justify the team sitting idle
28:35
during cooldown basically for 25 percent of the time assuming a six-week cycle
28:41
plus two week cooldown Rhythm that sounds to me like the perspective of somebody who is uh under pressure from
28:49
investors and I've heard this from teams who are VC backed
28:54
and they said there's no way that we can have something called cool down yeah so what we ended up doing was created
29:01
something called ramp up because the thing is
29:07
if if the team is actually completely focused inside of the time
29:14
box whether it's six weeks or whether it's three weeks whatever it is where they are just totally heads down
29:22
delivering something that is extremely valuable and that's well shaped and then they they actually ship that at the end
29:28
of that time there are going to be a lot of little Loose Ends lying around that need those
29:34
people's attention there's going to be the little thing that marketing needs there's going to be the little bit of tech debt that you know there's going to
29:41
be this infrastructure issue there's going to be alignment meetings that need to happen or different kinds of
29:48
um meetings that are between different people who couldn't meet because their heads were down before so there if they
29:56
were indeed really focused during that time box there's going to be a lot of like other stuff that has been waiting
30:03
for their attention you know and and then at the same time if you are going to be really deliberate
30:10
and strategic about what happens in the next three weeks or the next six weeks
30:15
there needs to be time for everyone to pull their heads up look around and understand like where where are we
30:22
actually going next and that might involve having a couple shaping sessions or doing a little bit of spiking before
30:29
feeling like we can turn on the green light to start the next focused effort so that ramp up time where we actually
30:38
figure out what's next and we coordinate with each other and we take care of all the little things that have come up in
30:43
between I mean that is functionally going to be really necessary and valuable it's not
30:49
that everyone is sitting around idle it's it's it's the difference between we are targeting our efforts toward a
30:57
very specific project that we have scheduled as opposed to We are giving ourselves the room that we need for all
31:04
the unpredictable little things that that are going to need our time so that we can again focus on the next focused
31:10
effort yeah on your website you have this video called shaping in a nutshell and I think
31:16
in that video you speak about um also two ways to split the kind of
31:22
the Strategic work versus the reactive work and it sounds like that might be
31:28
connected to to what you just said where kind of my follow-on question would be uh in a in a setting where you have
31:36
separate tracks for these kinds of Works do you still see teams using cooldown on
31:41
the Strategic tracks themselves or ramp up sorry to stick with this yeah
31:48
well depending on the team sometimes cooldowns sometimes ramp up yeah we see teams doing uh doing uh sometimes a
31:53
week-long pause in between the planned efforts but it's just it's just because
31:59
if you're going to do a project you know projects have a
32:04
start and an end and there has to be some coordination in between and the idea that you're going to ship on Friday
32:14
I mean that you're going to ship a major effort on a Friday and then kick off a
32:19
major new effort a multi-week major effort on Monday it's just not going to
32:24
happen that's just not how life is you can't do that you need it you need some time in between to coordinate you know
32:31
um so that time just has to be there whether it's two weeks or not um that can depend you know on on the
32:38
other things that are going on and this thing that you mentioned about the difference between the planned work and the reactive work this is a big big
32:45
thing too this is really important to recognize one of the things that teams
32:50
struggle with is sometimes they try to adopt shape up and they think now that
32:55
all software development should happen in some kind of a shape up way and that is simply not the case
33:01
if you're so the reactive work is work that is not only small
33:09
you know we think about bugs and little issues coming up from support or like marketing needs this thing
33:16
it's not only small it's the fact that it has urgency attached to it from a stakeholder
33:22
somewhere it's the fact that it's on fire that makes it reactive and that you can't decide when you're going to do it
33:28
there are a ton of little bugs and little technical debt things that are
33:35
small and they're bad but they're not urgent nobody is saying like I need this
33:42
in three days and if I don't have it I'm blocked and it's a problem for us right yeah so uh the reactive work it has that
33:50
urgency and that's that's why it's a problem for project-based work because it interrupts us because of the because
33:56
of the urgency and so this is why I literally am telling people you know
34:02
don't use Sheba for that a ticket-based process is way more suited for that kind of work a kanban is way more appropriate
34:09
for that kind of work because you are trying to get the fastest flow from step
34:16
to step to step so that you can get that urgent thing done you know it's a separate capacity using a separate
34:22
process much more ticket oriented whereas we're not in the ticket World in
34:27
shape up but very much in the ticket world for the reactive stuff yeah this by the way includes Project work
34:35
where you do not control the schedule of all of the participants so you might
34:41
think of let's say an integration with a client you know or you have to do an integration with a with with a third
34:47
party and that might seem to be a project but if you are going to be waiting on the client or the vendor or
34:53
the third party to do their part of the integration work and get back to you you're not going to be able to do that
34:59
in the shape up model because you don't control the time box so that would be much better to uh to move that over to a
35:07
kanban and think of it as more of a ticket-based process the last item on my list of top
35:13
criticism or misconceptions is um Shape Up is just mini waterfalls
35:20
teams execute a project and never look back to check for example if the intended impact materialized there's no
35:26
iteration so I would ask is this about
35:32
it's teams never look back to figure out what happened so is this is this saying that
35:37
um once something is launched that then there's no opportunity to evaluate whether it was successful and to improve
35:44
it or something like that that's my read of it yes so if we first of all if we are indeed
35:53
shipping something and that piece of work is finished and it goes out into the world
35:58
now we can really get the feedback that we need you know because we've shipped now we
36:05
can iterate because we actually have meaningful feedback from the market from customers from real Behavior out there
36:13
in the field uh a lot of times I think that what gets called iteration in a in a more of a
36:19
scrum context is actually a never-ending project you know it's like we're gonna keep
36:26
making it better and we're going to keep making it better and better and better and we're still not ready to ship it
36:31
because it's not better enough it's not good enough it's not perfect enough yeah and then when it when it ends up
36:36
happening is there's so much time that goes into it the project drags on so long that by the time you finally ship
36:43
it you can't actually justify spending more time to improve it because now you have a giant backlog full of other
36:48
things that you haven't finished you know yeah so actually the more that
36:54
we can shape a targeted effort spend a strategic amount of time on it
37:01
the three weeks the four weeks the six weeks tip it
37:07
you know now we can decide do we want to shape a new project based on
37:13
the feedback that we got from the world to to make that better do we want to work on something that is a completely
37:20
unrelated feature or do we want to extend the thing that we previously shipped or do we want to rethink the
37:26
thing that we shipped and do it in a different way I mean all those possibilities are on the table but we really need to have the actual real
37:31
world feedback to know how to make it better yeah I think from my experience
37:37
this uh this critique of many waterfalls and not being interactive it comes from
37:43
uh from teams that um are working a lot in the MVP mindset which oftentimes
37:50
tends to be an excuse for shipping half as things because you can always iterate the next Sprint and make it better which
37:57
which then doesn't happen is that something that you think Shape Up fixes
38:03
or prevents in any way because you're more intentional about the the work well
38:08
I would say the first thing is that if people are happy with what they're doing then there's no reason to to even switch
38:13
to shape up right so if someone is in some model where they are
38:19
um constantly iterating on things and they don't think of it in terms of shaping projects that they want to walk
38:24
away from then that's that's perfect for them the place where Shape Up kind of becomes
38:31
relevant is when the team starts to feel like why are we never done
38:37
um you know when it starts to feel like a struggle that we never seem to reach the
38:43
point where we can say that this is actually done and we walk away from it because it's effective and it's doing
38:49
what it was supposed to do you know so iteration is great when you are trying to get somewhere but
38:55
iteration isn't great when when you're kind of wandering around and and nobody
39:02
knows kind of what the where the finish line is hey I hope you're enjoying the
39:07
conversation I wanted to take a moment to thank you for listening and to let you know about the Shapers and Builders
39:13
job board on shapers.builders yes that's the domain
39:18
you'll find jobs in software development design product management and other
39:23
roles at companies that work with Shape Up many of these roads are remote and
39:29
teams who use Shape Up generally run at a more sustainable healthy and meaningful Pace than the hamster wheel
39:35
of two-week Sprints so if you're looking for a job in Tech or trying to find
39:40
great people head over to the Shapers and Builders job board at shapers.builders now let's turn back to
39:48
the conversation so turning from criticism to a more
39:54
joyous topic I'd love to hear if you had any kind of positive surprises from
39:59
teams using shape up that you learned of the the number one positive surprise is
40:06
that it continues and continues and continues to spread Underground
40:11
if I were to use Twitter and Linkedin or you know as a judge of what is going on in the industry
40:17
it doesn't match the picture that I get from all the private messages that I get from people and that to me is like a
40:23
totally surprising and like really interesting also the the interest in the course has
40:29
been really surprising and interesting um that there are so many people who are
40:37
aware of the fact that the way that they are doing their product development you know that there are all these disconnects and that
40:44
scrum and all the kind of best practices that are out there that they aren't working but somehow it's not it's not something
40:51
that's out there yet as a public conversation you know it's funny we tried we tried to have like a like a public
40:58
shape up for them when we first launched the book and it was just silent and and
41:04
and I and at the time I was a little bit disappointed even you know I was like oh you know nobody's using the Forum and
41:10
it's you know nobody cares about Shape Up and yeah and of course what I discovered was that the issues that the
41:17
that that that the book addresses are the really really hard questions at the
41:23
highest level in the company I mean they're the the questions that the c-level people are struggling with about
41:28
like like why are like why are we so ineffective yeah
41:34
you know and of course you're not going to be a VP or C or or a c-level person
41:39
and go onto the public into a public forum and then start talking about how ineffective your team is yeah that's
41:46
true although I have observed some um some posts of that you know I I guess
41:52
I know the firm you're talking about and there have been people sharing their struggles uh but again I think that the
41:58
the first Niche was just the kind of the bootstrappers community if you want to
42:03
call it that and then the sea level of those companies I think so and that's it for sure yeah there's been some of that
42:10
yeah yeah especially those bootstrappers who were really close fit that we saw some of those posts the other thing
42:16
that's really surprised me is how often
42:21
I've seen a lot of teams where there's an engineering kind of Department okay
42:27
so we're talking about a slightly bigger company there's an engineering department and this engineering department is using something like scrum
42:35
and the product folks have understood that giving the
42:42
engineering people you know drawings and figma drawings and
42:48
and all this stuff you know or a bunch of just research from their discovery that there's too big of a disconnect and
42:54
everything is getting Lost in Translation and it's not working and and in my original kind of yeah like vision
43:03
of of this whole thing like when I wrote the book I thought I thought that the way that the team
43:10
does delivery was really important like from the moment the cycle starts until the moment of shipping yeah all this
43:17
stuff about breaking the work into Scopes and using Hill charts and all of this I really thought that that stuff
43:23
was essential for doing shape up because it was actually kind of the area where I
43:28
was digging deeper in my own well I don't know what you call it like in my own development you know what I
43:34
mean like as a practitioner like that was the area that I was kind of geeking out on the most and what I found out is
43:40
that for 90 of teams once you establish a time box
43:46
at the beginning of the time box is just a starting gun and then once you fire that starting gun it's just like Off to
43:52
the Races and you cannot influence anything you cannot control anything yeah and and what I've found is that all
43:59
the really like most of the Leverage is actually in the shaping and bringing
44:05
bringing bringing uh the experienced technical people into the shaping having
44:10
that push and pull between the design concept and what is technically feasible in the shaping and that's so it's just
44:18
been amazing to me to see like the kind of results the teams are getting even when they still have to put the work
44:23
through a paper shredder afterward yeah and that to me was like kind of a really kind of violated my sensibilities that
44:29
you could still have this paper shredder of splitting everything into tickets and then just assigning tickets and so on or
44:36
doing it in two week Sprints or whatever that even still just doing that shaping
44:41
first had a huge impact on the team's ability to ship on time so that was
44:47
really surprising to me and really nice to see because it also means that and this is a big part of why we ended up
44:54
you know my wife and I created this shaping in real life together I was telling like I had finished a Consulting
45:00
project and we were looking together at like all the new things that we did in this Consulting project and it's like
45:07
there's there's a whole new way to teach this that's different than what's in the book you know and she was like what why
45:12
don't you why don't we like have you thought about making a course maybe we should make a course for this and um
45:20
so that's been really interesting because now what we're seeing is that teams can pick off the practices that they want to
45:26
choose for example like the the framing and shaping steps yeah and if they don't have influence over the way that the
45:33
engineers work that's okay they can still have huge wins and then gradually
45:38
what I'm finding out is that introducing these new techniques inside
45:45
of the delivery phase like breaking things into Scopes and uh working on a scope basis and like uh uh dealing with
45:54
the unknowns and stuff inside of that like making making trade-offs inside of the delivery phase using the hill chart
46:00
inside of the delivery phase that stuff is actually all kind of like advanced level you know yeah once you really have
46:07
shaped work and you have the the folks who are in the delivery phase are
46:12
feeling really engaged and they want to kind of take it to the next level like then these things come in but they're actually not at all necessary to start
46:18
yeah and I can definitely second what you said about this underground spread
46:24
of shape up I'm reg I'm often surprised myself when I'm speaking with other teams and they are saying hey you know
46:31
uh we actually know of shape up we've tried it or we're using parts of it and
46:36
um just two weeks ago I was interviewing and speaking with a with an agile coach
46:41
that was kind of the Pinnacle of surprise for me that you know these people who are certified uh in in safe
46:48
and and kind of um that side uh where I felt like initially there was this divide between
46:56
uh Shape Up and the scrum Community
47:01
um and now we have agile coaches that I can implementing shape up and in that
47:08
case a huge company across 20 21 teams I think he said so that's been a big
47:14
surprise for me as well wow cool I even heard just yesterday I heard an interview with Kent Beck who I greatly
47:21
admire and learned so much from studying his work I mean like he's like on the very like top shelf of important
47:28
influential people in the in the world of agile and programming that I learned from uh uh you know through studying XP
47:35
and and everything that he did um but there was an interview with him and he said that he was really
47:41
disappointed that he sees kind of what he called a a reversion back to Waterfall in out there in in in this in
47:50
the industry today that there's a swing back toward upfront design and I'm listening to that and I'm thinking like
47:55
I wonder I wonder if it has anything to do with what we're talking about here you know
48:01
and of course of course we don't want to go back to that 90s style waterfall either this was also a big mistake you
48:07
know what I mean so that's not what we're talking about but there is a trend toward more upfront thinking at least
48:15
you know and it could possibly be misinterpreted by people who are really very uh strongly agile on their mindset
48:22
where they might they might get nervous about that I could understand that yeah
48:27
tied together kind of all the learnings that you had since launching the book in 2019 are you ready yet to tack on the
48:35
2.0 version label to shape up and if so what are the major upgrades that you see
48:41
between Shape Up 2.0 and 1.0 I think 1.8 is the current version number that you
48:47
have out there you know I actually think that um uh what we have in the in the shaping in
48:53
real life material is fully is fully 2.0 uh the distinction between Framing and
49:02
shaping is actually really really important understanding when we are making the
49:09
case to do something and and trying to pitch people to invest time in something
49:14
as opposed to making the trade-offs and designing the system of How It's actually going to work
49:21
those are very different kinds of things we see product managers business people
49:27
doing what we now call framing but they think it's shaping and then so they're
49:32
saying here are the 10 reasons why we should do this here are all the customers who are saying they want it so
49:38
let's go do it and it's like but wait a minute like what's the actual concept yeah right so this
49:45
um and seeing how you know making the case to spend time on something requires
49:51
going into Data doing different types of research it's a different kind of work uh to make the business case as opposed
49:58
to figure out the technical approach so that's been very very fundamental and
50:03
there's a lot related to that um in in
50:08
In Shape Up we talked about coming up with a concept and then kind of giving it to presenting it to technical people
50:15
for them to somehow kind of push back and de-risk it or something like that and we even talked about this
50:22
notion of rabbit holes in the pitch and this actually is the right idea but in
50:28
practice there shouldn't be any rabbit holes in the pitch there if if something is a rabbit hole we should solve it in
50:34
shaping by doing spikes we should go deeper into the concreteness in that area to figure out
50:40
where do we actually hit the wall where are the breaking points in this in this tricky area so that we can understand
50:46
those things before we before we make the commitment to do the project so spiking and shaping is a very very big
50:53
thing and we talk about kind of going in and out from shaping sessions into spiking
50:59
sessions and so on the fact that shaping is very much about actually looking at
51:06
alternate ways to do things whenever we were shaping at base camp we were always saying what is the what is the version
51:12
of this that we could do in six weeks but we were also saying but what is the
51:18
two-week version what is the quick hack version what's the six month version so thinking about
51:25
alternate versions option a option b option C with different constraints in
51:30
order to understand better what the possibilities are this is something fundamental in shaping that we also teach now as uh different paths so what
51:39
are the parts that we think going to the solution and what are different paths we can take under different constraints
51:45
then when we go into the actual output of shaping that the output of shaping it
51:51
doesn't make sense to call it a pitch because a pitch is like a sales pitch right but if we've made the time
51:57
investment so if we framed it we understood the business value we think that it's worth spending some time on we've shaped it we've come up with what
52:04
we think is a viable kind of system design Revival architecture or a viable approach of what to build
52:11
now what we have is actually something we call the package we package what was
52:18
shaped so that it can go into delivery so packaging means you know like it's
52:24
not just a bunch of scribbles on the wall and only those of us who were there understand what it means but now it's in
52:29
a document in a form that's going to survive the passage of time and the changing of hands
52:34
so this notion of packaging and then actually choosing the right level of latitude and what to spell out versus
52:41
what to leave for the team to decide this is something that happens in packaging that's very much dependent on
52:47
who we give the work to so in shape up there was this impression that there's kind of a right way to
52:53
write a pitch you know that it should have a fat marker sketch and it should have this and it should have that but actually what goes into the package the
53:00
package is what the team needs so that they can be successful in delivery and they can make judgment calls so it might
53:07
be that there are things that they need to know that are much more detailed about how some Legacy thing works you
53:14
know maybe there was some really old code that we had to carefully analyze in the shaping to understand what to do
53:20
and we could we should spell out exactly what we learned about that old code in
53:26
that package if that's going to be relevant and if we actually got all the way down to a very concrete
53:32
UI concept inside of the shaping and we understood in this particular project we
53:39
don't want to have latitude for something else but this very specific Design This little piece of the design
53:45
this little piece should actually be the way that we the way that we already defined it versus the other things you
53:51
know could change so this idea of being much more yeah judicious being much more
53:59
conscious of what we put into the package so that it is the right thing that's going to help the team to be
54:04
successful and then of course this also the handoff of this this method that we teach for
54:12
how to enable the team to give some feedback and show what they understand
54:17
especially when you have a lot of Junior people where they can kind of sketch out the Scopes and their implementation
54:24
approach before kickoff at the beginning of the cycle so that there can be some back and forth between senior and Junior
54:29
to make sure that we're actually aligned and that the team is going to work on the biggest unknowns and the most
54:35
important pieces first and they're not going to bump into the you know the
54:40
they're not going to bump into the biggest difficulties on the in the 11th hour at the last minute so there's
54:46
there's quite a few things there and the word package itself also I think uh it fits better the context that you
54:52
mentioned in the beginning of um teams who don't have the luxury to shape multiple competing pictures and
54:59
then come together to decide right it's it's exactly it's the package that goes into delivery next
55:05
yes exactly cool before we wrap up I'd love to hear what's next for you I know
55:12
you've been speaking at quite a few conferences lately business of software the product conf and you're running more
55:18
cohorts of the course are you a traveling coach and consultant now or are you planning at any time to go back
55:25
to Building Products because you have this kind of vague sentence in your bio on your website that says I'm currently
55:32
working with a small team to invent the next generation of creative tools for the early stage of engineering and
55:37
design projects do you want to talk about that a bit well what I've understood is that if we
55:43
lead or what I believe at least is that if we lead with with new tools but
55:48
people don't have the different way of thinking first that nobody's going to
55:54
Value the tools and they're going to say this tool doesn't work for example uh I did I I built together
56:02
with uh um with Bob mesta and some friends we we built a tool for doing job
56:08
to be done interview analysis and it's quite sophisticated I mean it's basically producing the kind of a kind
56:15
of embedding where you can figure out kind of the the mathematical distance
56:20
between different stories and a job and stuff like that it's like it's an amazing tool and uh we use it on all of
56:26
our on all of our projects now but uh if you if you haven't really understood the
56:33
how to get the these four forces from jobs to be done out of interviews it's garbage and garbage out yeah and it's
56:40
kind of like this tool doesn't do anything and so we we only even give access to the tool to people who are
56:46
already pretty really well trained in interview technique and then they're
56:51
like oh wow you know then they understand what it's doing for them and they can value it I think the same thing is true for all the tooling around the
56:58
stuff so first of all I you know I'm continuing to I have a lot of stuff
57:05
that's prototype that I use on my own projects but I don't think it's the right time to actually make any of that stuff public
57:11
um we have a little bit of some prototyping going on some people are using a handoff tool uh that I built out
57:17
there in the wild uh the I'm certainly not thinking myself as a traveling coach uh my my uh so so
57:26
Katy and I really enjoyed uh making the making the course and what the course
57:32
has allowed us to do is actually to bring more people in to the new way the kind of the latest
57:38
thinking and and this sort of 2.0 level of of shape up
57:44
and uh but the the Consulting projects that I'm doing are
57:51
projects where I go into a team where I would not have been able to give them the answer up front and where the course
57:57
doesn't have the answer for them but there's something harder there's something you know unique or really
58:04
difficult or something that I don't understand and they don't understand in their circumstance and then the
58:09
Consulting project is a way to really extend the framework and innovate and like figure out like really push the
58:15
edges of of what I already know how to explain so I'm doing one or two of those a year
58:20
they're very selective and I usually embed for about a quarter you know with
58:26
the team so like three months of um kind of part-time but but very Hands-On with
58:31
what's going on in the team and then that's actually been a source of a lot of the new stuff that's coming out so for example I just did a project where
58:38
we applied Framing and shaping and spiking to a marketing team and this was totally different than what
58:47
a product team does but at the same time it was exactly the same stuff you know what I mean so uh it's really
58:53
interesting so I'm doing occasional Consulting projects to really kind of extend um and deepen my understanding of how
58:59
this can be applied in different tricky contexts and uh in the meanwhile we're continuing to do cohorts of the course
59:06
we're doing a few of those per year and that's going really well and we're excited about that and I would love to
59:12
do some tooling but let's see let's see when the time comes and uh when it fits
59:18
yeah I'm also you know and the other thing is you know building software is actually
59:24
very time consuming and then you have to maintain and operate what you built and you have to keep all the servers running
59:30
and you have to keep updating everything to the latest version and actually the operation side of the software business
59:35
is it's it's harder than people think once you actually start to get customers and you have to support stuff so I think
59:42
it also could be interesting to see maybe in the future there's a possibility to partner with some people
59:48
where the tooling side is a little bit of a slightly different business than the than the teaching and the figuring
59:53
out the method side that sounds great I'll be looking forward to anything that gets released or announced in that
59:59
direction thank you so much Ryan uh this has been a blast uh if people want to connect
1:00:05
with you how should they do that yeah so they can find me on on Twitter
1:00:11
on LinkedIn and uh my website feltpresence.com is a great place to
1:00:17
start you'll see that shaping in a nutshell video and that's also a place to see what's happening with shaping in
1:00:22
real life and anything else that's available amazing thank you so much
1:00:27
all right thanks David really enjoyed it
1:00:34
there you have it I hope you enjoyed the conversation with Ryan as much as I did if you like this show it really goes a
1:00:41
long way if you leave a favorable review wherever you are listening to this and if you're interested to find jobs at
1:00:47
companies that work with Shape Up we've actually set up a dedicated job board at shapers.builders yep that's the domain
1:00:55
so go ahead and check that out if you're interested but for now thank you so much
1:01:00
for listening and I hope you have a great day [Music]