1
00:00:00,100 --> 00:00:03,000
Hey, a quick message, for those 
of you who are listening to this

2
00:00:03,000 --> 00:00:07,500
episode on Spotify, I have a 
small favor to ask Spotify. 

3
00:00:07,500 --> 00:00:11,000
Now allows mobile users to rate 
podcast, I would really 

4
00:00:11,000 --> 00:00:13,300
appreciate it. 
If you can take a quick, pause 

5
00:00:13,300 --> 00:00:16,100
to go to the technique Journal 
podcast page, and leave your 

6
00:00:16,100 --> 00:00:18,800
favorite show. 
Your best rating on Spotify. 

7
00:00:19,200 --> 00:00:21,800
It will help me a lot to get 
this podcast to reach more 

8
00:00:21,800 --> 00:00:24,300
people on the platform. 
Thanks a lot. 

9
00:00:24,800 --> 00:00:26,700
Everybody wants to be more 
productive. 

10
00:00:27,000 --> 00:00:30,000
And if you're looking to acquire
productivity either, as An 

11
00:00:30,008 --> 00:00:33,200
individual or as a team isn't as
great as you'd like one thing 

12
00:00:33,200 --> 00:00:36,600
you might find is that you spend
too much time on rework. 

13
00:00:36,600 --> 00:00:39,900
A way to boost productivity then
is to create high-quality 

14
00:00:39,900 --> 00:00:43,500
software from the outset so that
teams can spend less time on 

15
00:00:43,500 --> 00:00:47,200
rework, both doing development 
and following release. 

16
00:00:52,300 --> 00:00:55,000
Hey everyone. 
My name is Henry Surya with 

17
00:00:55,000 --> 00:00:58,400
Robin. 
And you're listening to the 

18
00:00:58,400 --> 00:01:01,600
technology, you know, podcast 
the show where I'll be bringing 

19
00:01:01,600 --> 00:01:04,700
you the greatest technical 
leaders practitioners and 

20
00:01:04,700 --> 00:01:08,500
thought leaders in the industry 
to discuss about their Journey 

21
00:01:08,700 --> 00:01:13,200
ideas and practices that we all 
can learn and apply to build a 

22
00:01:13,200 --> 00:01:16,800
highly performing technical team
and to make an impact in your 

23
00:01:16,800 --> 00:01:20,000
personal work. 
So let's dive into our Journal. 

24
00:01:25,000 --> 00:01:27,100
Hello my friends. 
Welcome back to the tekhelet 

25
00:01:27,100 --> 00:01:30,000
Janelle podcast the show where 
you can learn about technical 

26
00:01:30,000 --> 00:01:33,300
leadership and Excellence from 
my conversations with great 

27
00:01:33,300 --> 00:01:36,100
thought, leaders in the tech 
industry, and this is the 

28
00:01:36,100 --> 00:01:39,800
episode number 103. 
If this is your first time 

29
00:01:39,800 --> 00:01:42,600
listening to Tech lead, you 
know, subscribe and follow the 

30
00:01:42,600 --> 00:01:46,500
show on your podcast app and on 
LinkedIn, Twitter and Instagram.

31
00:01:47,000 --> 00:01:50,100
And if you'd like to support my 
journey creating this podcast, 

32
00:01:50,500 --> 00:01:52,400
Subscribe as a patron at 
package. 

33
00:01:52,400 --> 00:01:56,700
You know, dot, f / Patron. 
My guest for today's episode is 

34
00:01:56,700 --> 00:02:00,400
called uyghurs call is the 
author of software development 

35
00:02:00,400 --> 00:02:04,600
pearls and the principal 
consultant at process impact in 

36
00:02:04,600 --> 00:02:08,199
this episode called shared some 
lessons that he has learned over

37
00:02:08,199 --> 00:02:12,100
the past five Decades of his 
career or what he refers to. 

38
00:02:12,100 --> 00:02:16,000
As pearls we first discussed 
software requirement and its 

39
00:02:16,000 --> 00:02:19,900
role for communication and why 
it is very important to define 

40
00:02:19,900 --> 00:02:24,100
the rights of Requirements call 
then touch on the reasons why we

41
00:02:24,100 --> 00:02:27,400
cannot optimize All Quality 
attributes that we desire in a 

42
00:02:27,400 --> 00:02:31,000
software and instead, advised 
how we should Define the quality

43
00:02:31,000 --> 00:02:34,800
attribute requirements. 
Next caller, shared some project

44
00:02:34,800 --> 00:02:37,400
management. 
Pearls related to work planning 

45
00:02:37,700 --> 00:02:40,500
dealing with estimates and 
making commitments. 

46
00:02:41,000 --> 00:02:45,100
Towards the end, call explain 
the relation between quality and

47
00:02:45,100 --> 00:02:49,000
productivity using pain as a 
driver for improvement. 

48
00:02:49,200 --> 00:02:51,900
And lastly, his out. 
Ultimate pearl of wisdom. 

49
00:02:52,500 --> 00:02:55,600
I hope you enjoy listening to my
conversation with call. 

50
00:02:55,900 --> 00:02:57,900
If you find it useful. 
Please help. 

51
00:02:57,900 --> 00:03:01,000
Share it with your friends and 
colleagues who can also benefit 

52
00:03:01,000 --> 00:03:04,600
from listening to this episode. 
It is my ultimate mission to 

53
00:03:04,600 --> 00:03:08,100
spread this podcast to more 
people and I really appreciate 

54
00:03:08,100 --> 00:03:11,500
your support in any way towards 
fulfilling my mission. 

55
00:03:12,000 --> 00:03:15,000
Before we continue to the 
conversation, let's hear some 

56
00:03:15,000 --> 00:03:18,300
words from our sponsor. 
Definitely is the top 

57
00:03:18,300 --> 00:03:20,900
International software 
development conference, With an 

58
00:03:20,900 --> 00:03:24,900
emphasis on coding, architecture
and tag leadership skills. 

59
00:03:25,200 --> 00:03:28,500
The lineup for this year is 
truly stellar and features many 

60
00:03:28,500 --> 00:03:32,300
Legends in software development 
names, such as Robert Uncle Bob,

61
00:03:32,300 --> 00:03:37,100
Martin can back Scott Hanselman,
Franca subramanyam Carolyn 

62
00:03:37,100 --> 00:03:40,500
honey, Alan Halep, Mary, 
poppendieck, and many other 

63
00:03:40,500 --> 00:03:43,900
prominent names, including some 
of those who have also appeared 

64
00:03:43,900 --> 00:03:47,800
in this podcast before the 
conference takes place online. 

65
00:03:47,900 --> 00:03:50,300
So you can enjoy it from the 
comfort of your couch. 

66
00:03:50,500 --> 00:03:54,000
Ouch, we spoke to the definite 
the organizers and I'm happy to 

67
00:03:54,000 --> 00:03:56,500
share that technology. 
You know, has got the 10% 

68
00:03:56,500 --> 00:04:01,100
discount code for you. 
Enter the promo code, awsm 

69
00:04:01,300 --> 00:04:04,400
underscore tlj. 
When you purchase the ticket on 

70
00:04:04,400 --> 00:04:07,400
definite e.com, here's the promo
code. 

71
00:04:07,400 --> 00:04:11,500
One more time awsm underscore, 
tlj. 

72
00:04:12,300 --> 00:04:15,500
Depending on the time when you 
purchase a ticket early price is

73
00:04:15,500 --> 00:04:17,800
still available. 
See you there. 

74
00:04:18,200 --> 00:04:21,000
Today's episode is proudly 
sponsored by Skills. 

75
00:04:21,000 --> 00:04:24,700
Meta the global community and 
events platform with more than 

76
00:04:24,700 --> 00:04:29,300
100,000 software professionals 
here members, can organize their

77
00:04:29,300 --> 00:04:32,100
learning experiences around the 
technology topics. 

78
00:04:32,100 --> 00:04:35,800
They care about most you get 
on-demand access to their latest

79
00:04:35,800 --> 00:04:39,100
content thought, leadership 
insights, as well as the 

80
00:04:39,100 --> 00:04:43,300
exciting schedule of tech events
running across all time zones. 

81
00:04:43,700 --> 00:04:47,300
So we're the devops our data 
science is your bus or you are 

82
00:04:47,300 --> 00:04:50,300
fan of functional programming or
all things cloud. 

83
00:04:50,400 --> 00:04:52,900
What'd you can make real 
connections with people who 

84
00:04:52,900 --> 00:04:57,000
share your interests head on 
over to skills method or calm to

85
00:04:57,000 --> 00:04:59,800
become part of the tech 
community that matters most to 

86
00:04:59,800 --> 00:05:01,900
you. 
It's free to join and you will 

87
00:05:01,900 --> 00:05:05,000
find it easy to keep up with the
latest tech Trends. 

88
00:05:07,500 --> 00:05:09,800
Hi everyone. 
Welcome again to the tech lead, 

89
00:05:09,800 --> 00:05:12,800
you know, podcast today, I have 
with me, someone, I really 

90
00:05:12,800 --> 00:05:14,300
looking forward to learn from 
him. 

91
00:05:14,500 --> 00:05:17,300
His name is Carl. 
We goes is the principal 

92
00:05:17,300 --> 00:05:20,200
consultant with process impact 
and he has written. 

93
00:05:20,600 --> 00:05:24,300
In books, 13 books. 
That's really a lot of books out

94
00:05:24,300 --> 00:05:25,900
there. 
And today, in particular, will 

95
00:05:25,900 --> 00:05:28,600
be talking about his latest 
book, titled software 

96
00:05:28,600 --> 00:05:31,000
development. 
Pearls, the subtitle is actually

97
00:05:31,000 --> 00:05:34,100
lessons from his 50 years of 
experience. 

98
00:05:34,100 --> 00:05:37,300
So 50, that's really a lot of 
years out there. 

99
00:05:37,500 --> 00:05:40,000
So yeah, counting so much for 
being in the show. 

100
00:05:40,200 --> 00:05:42,800
I'm really looking forward to 
learning from you with all your 

101
00:05:42,800 --> 00:05:44,900
posts in the book. 
Thank you, Henry. 

102
00:05:44,900 --> 00:05:48,900
I'm happy to be with you today. 
So, call your book has 60 

103
00:05:48,900 --> 00:05:51,900
pearls, when I look at them. 
Um, it's really great but maybe 

104
00:05:51,900 --> 00:05:55,800
before we start into those, can 
you maybe start by sharing your 

105
00:05:55,800 --> 00:05:57,800
career Journey? 
Mentioning about highlights 

106
00:05:57,800 --> 00:06:02,800
turning points Okay, I have a 
slightly unusual background, but

107
00:06:02,800 --> 00:06:05,500
the age group that I'm in a lot 
of people came into software 

108
00:06:05,500 --> 00:06:08,200
from different backgrounds. 
We didn't have a lot of computer

109
00:06:08,200 --> 00:06:12,200
science, programs, or software 
engineering programs in college.

110
00:06:12,400 --> 00:06:14,700
So I first learned to program in
Fortran. 

111
00:06:14,700 --> 00:06:17,100
Of course, back in college in 
1970. 

112
00:06:17,100 --> 00:06:20,800
It's hard to believe that was 
nearly 52 years ago, but it was,

113
00:06:21,100 --> 00:06:23,100
they didn't build a software 
right away. 

114
00:06:23,100 --> 00:06:26,200
I actually have a PhD in organic
chemistry, which I've always 

115
00:06:26,200 --> 00:06:29,000
thought was the perfect 
background for anyone in it on. 

116
00:06:29,100 --> 00:06:30,900
No. 
Not everyone seems to understand

117
00:06:30,900 --> 00:06:34,000
that, but one third of my PhD 
thesis was code. 

118
00:06:34,100 --> 00:06:36,200
So I've done a lot of 
programming in a lot of 

119
00:06:36,200 --> 00:06:39,200
different ways after graduate 
school and postdoc. 

120
00:06:39,200 --> 00:06:42,900
I began my career as a research 
scientist at Kodak in New York 

121
00:06:43,300 --> 00:06:46,500
and one of the major turning 
points was around 1983, when I 

122
00:06:46,500 --> 00:06:49,500
did switch over into doing 
software development full time 

123
00:06:49,500 --> 00:06:52,500
for several reasons, but 
software had been my second 

124
00:06:52,500 --> 00:06:54,300
interest anyway. 
And by then it was becoming my 

125
00:06:54,300 --> 00:06:56,700
first interest. 
So I was a software developer at

126
00:06:56,700 --> 00:07:00,100
Kodak for several years and I 
managed a small Software group 

127
00:07:00,100 --> 00:07:03,200
in the Kodak research labs. 
And I moved more into business 

128
00:07:03,200 --> 00:07:06,400
analysis, quality engineering, 
and process Improvement. 

129
00:07:06,800 --> 00:07:10,600
And another major turning point 
came in 1996, when my first book

130
00:07:10,600 --> 00:07:13,400
was published, which was called 
creating a software engineering 

131
00:07:13,400 --> 00:07:15,700
culture, and that was a lot of 
fun. 

132
00:07:15,700 --> 00:07:18,200
I always wanted to write a book,
but I really didn't have an idea

133
00:07:18,200 --> 00:07:21,300
but some ideas came together 
then and that turned into my 

134
00:07:21,300 --> 00:07:23,700
first book. 
And then, another big Turning 

135
00:07:23,700 --> 00:07:25,300
Point happened. 
A couple of years later. 

136
00:07:25,400 --> 00:07:29,000
I'm 1998, when I left Kodak and 
started my software development.

137
00:07:29,100 --> 00:07:31,300
Eating and training company 
process impact. 

138
00:07:31,300 --> 00:07:34,100
Since then I have continued to 
write books periodically on 

139
00:07:34,100 --> 00:07:37,500
various topics including 
requirements peer reviews 

140
00:07:37,500 --> 00:07:41,100
project initiation Consulting, 
product design, and even a 

141
00:07:41,100 --> 00:07:44,400
forensic mystery novel. 
But for the last 25 years, 

142
00:07:44,400 --> 00:07:47,500
mostly I've been doing 
consulting and training, so 

143
00:07:47,500 --> 00:07:50,300
maybe some other time you would 
cover your forensic novel. 

144
00:07:50,400 --> 00:07:53,300
But for today, we'll be covering
about your software development 

145
00:07:53,300 --> 00:07:55,100
pearls. 
As you mentioned in your career 

146
00:07:55,100 --> 00:07:57,900
Journey, you've been dealing 
with a lot of different areas, 

147
00:07:57,900 --> 00:07:59,000
right? 
It's not just purely soft. 

148
00:07:59,900 --> 00:08:02,700
So you've moved into 
requirements design process 

149
00:08:02,700 --> 00:08:05,700
Improvement culture. 
I think it's really great to see

150
00:08:05,700 --> 00:08:07,800
all these actually covered in 
the books as well. 

151
00:08:08,200 --> 00:08:11,900
So there's in total six areas if
I'm not mistaken starting from 

152
00:08:11,900 --> 00:08:15,100
like requirements design, 
project management culture and 

153
00:08:15,100 --> 00:08:17,800
teamwork quality and process 
Improvement. 

154
00:08:17,800 --> 00:08:20,800
We may not be able to cover all 
your 60 but I think we'll just 

155
00:08:20,800 --> 00:08:24,100
take the importance one or 
interesting ones for you. 

156
00:08:24,300 --> 00:08:25,600
So that's that with 
requirements. 

157
00:08:25,600 --> 00:08:28,800
I think this is very interesting
and look at the different roles 

158
00:08:28,800 --> 00:08:31,600
that you You have think we'll 
just focus first on the first 

159
00:08:31,600 --> 00:08:35,000
thing, which is the overarching 
objective of requirement 

160
00:08:35,000 --> 00:08:38,000
development is clear and 
effective communication. 

161
00:08:38,000 --> 00:08:40,900
So tell us more about this 
because yeah, we know 

162
00:08:40,900 --> 00:08:44,500
requirements should have a very 
clear and effective way of 

163
00:08:44,500 --> 00:08:47,600
expressing the requirements of 
the software, but can you maybe 

164
00:08:47,600 --> 00:08:50,600
elaborate furthermore? 
Yeah, I always think of 

165
00:08:50,600 --> 00:08:54,900
requirements as being all about 
communication software 

166
00:08:54,900 --> 00:08:57,900
development is maybe half 
communication and half Computing

167
00:08:57,900 --> 00:09:02,400
but All about communication. 
So I use the term business 

168
00:09:02,400 --> 00:09:06,100
analyst to refer to whoever on a
project, is responsible for 

169
00:09:06,100 --> 00:09:09,700
Bridging the communication gap 
that always exists between the 

170
00:09:09,700 --> 00:09:12,500
customer domain, whatever, kind 
of customers, or users you 

171
00:09:12,500 --> 00:09:16,000
talking about in The implementer
Domain, Whoever has to go off 

172
00:09:16,000 --> 00:09:19,000
and then build some solution to 
meet some need or exploit some 

173
00:09:19,000 --> 00:09:22,600
business opportunity. 
So, the ba is real. 

174
00:09:22,600 --> 00:09:25,800
It's not a title necessarily 
although many times it is, but 

175
00:09:25,800 --> 00:09:29,300
it's a role in the central role 
of the be a, I think Is to 

176
00:09:29,300 --> 00:09:33,100
facilitate exchanging knowledge 
about the requirements among all

177
00:09:33,100 --> 00:09:35,200
of the project participants. 
So it's a really critical 

178
00:09:35,200 --> 00:09:38,700
bridging function and there's no
single way to accomplish this. 

179
00:09:38,700 --> 00:09:42,100
Communication, people use 
different kinds of names for 

180
00:09:42,100 --> 00:09:44,900
different kinds of information. 
If you're talking about user 

181
00:09:44,900 --> 00:09:48,000
stories, in an agile world, if 
you're talking about, use cases,

182
00:09:48,000 --> 00:09:50,800
or functional requirements, more
traditionally, it doesn't 

183
00:09:50,800 --> 00:09:53,100
matter. 
My principal heater is that the 

184
00:09:53,100 --> 00:09:56,900
developers need the same 
information to write the correct

185
00:09:56,900 --> 00:10:00,600
code properly. 
Regardless of what you call it, 

186
00:10:00,700 --> 00:10:03,500
regardless of what development 
lifecycle you're following. 

187
00:10:03,700 --> 00:10:06,000
So, I don't think there's 
anything special about agile, 

188
00:10:06,000 --> 00:10:09,000
requirements, and calling things
by in special names. 

189
00:10:09,400 --> 00:10:11,400
In fact, there's a lot of 
confusion over even what the 

190
00:10:11,400 --> 00:10:14,700
terms used in requirements mean?
So, I find that when I start 

191
00:10:14,700 --> 00:10:16,700
talking with people about 
requirements, the very first 

192
00:10:16,700 --> 00:10:20,000
thing I have to do is Define our
terms so we can communicate 

193
00:10:20,000 --> 00:10:22,300
effectively. 
For example, if I say business 

194
00:10:22,300 --> 00:10:24,700
requirement different people 
have different ideas about what 

195
00:10:24,700 --> 00:10:26,700
that means. 
So immediately at a 

196
00:10:26,708 --> 00:10:30,200
communication disadvantage, 
another problem that we have is 

197
00:10:30,200 --> 00:10:33,900
that we have multiple audiences 
for requirements information who

198
00:10:33,900 --> 00:10:36,800
have different needs, they want 
to see information in different 

199
00:10:36,800 --> 00:10:41,700
ways, we different levels of 
detail so the ba has to focus 

200
00:10:41,700 --> 00:10:44,800
their requirements activities on
getting a whole lot of 

201
00:10:44,808 --> 00:10:48,700
information from various sources
and presenting that in ways that

202
00:10:48,700 --> 00:10:52,200
let all these various audiences,
get the information they need to

203
00:10:52,200 --> 00:10:54,900
do their jobs, effectively and 
efficiently. 

204
00:10:55,300 --> 00:10:58,300
There's two techniques that 
people sometimes seem to try for

205
00:10:58,400 --> 00:11:02,800
It's work, telepathy reading 
minds and Clairvoyance. 

206
00:11:02,800 --> 00:11:06,200
Knowing thing is somehow 
magically, those don't work very

207
00:11:06,200 --> 00:11:08,800
well but they seem to be the 
technical foundation for some 

208
00:11:08,800 --> 00:11:11,500
projects. 
I also have another philosophy 

209
00:11:11,500 --> 00:11:15,000
when it comes to communication 
here, I think the cost of 

210
00:11:15,000 --> 00:11:18,600
recording knowledge is small 
compared to the cost of 

211
00:11:18,600 --> 00:11:21,500
acquiring knowledge. 
And so sometimes people aren't 

212
00:11:21,500 --> 00:11:23,800
very interested in recording 
information over. 

213
00:11:23,800 --> 00:11:25,800
Don't have time to write that 
down or we don't need to write 

214
00:11:25,800 --> 00:11:28,000
that down and I think that's a 
terrible mistake. 

215
00:11:28,300 --> 00:11:32,300
Because human memories are 
imperfect, their transient the 

216
00:11:32,300 --> 00:11:34,400
fallible. 
Have you ever had the experience

217
00:11:34,400 --> 00:11:36,700
Henry, where you've had a 
conversation or a meeting with 

218
00:11:36,700 --> 00:11:38,300
some people? 
You walk out? 

219
00:11:38,300 --> 00:11:39,400
You think you've agreed on 
something? 

220
00:11:39,400 --> 00:11:41,500
You think you have a common 
understanding and then a little 

221
00:11:41,500 --> 00:11:44,100
bit later, you realize, oh, we 
interpreted something 

222
00:11:44,100 --> 00:11:45,400
differently. 
We remembered something 

223
00:11:45,400 --> 00:11:47,300
differently if you ever had that
kind of experience. 

224
00:11:47,300 --> 00:11:50,400
Yeah, almost all the time, 
especially in this remote work. 

225
00:11:50,600 --> 00:11:53,500
So you have a sink, maybe you 
chat a little bit but yeah, 

226
00:11:53,500 --> 00:11:56,800
turns out the understanding is 
actually very different and you 

227
00:11:56,800 --> 00:11:58,100
don't know it's different 
course. 

228
00:11:58,400 --> 00:12:01,000
You just go off and do your work
thereafter in. 

229
00:12:01,000 --> 00:12:03,500
Good faith, based on what you 
thought you understood and 

230
00:12:03,500 --> 00:12:05,700
someone else thought they 
understood something different. 

231
00:12:05,800 --> 00:12:09,100
So I think having a group 
memory, a documented group 

232
00:12:09,100 --> 00:12:11,900
memory by documenting 
requirements at an appropriate 

233
00:12:11,900 --> 00:12:15,100
level of detail, gives you some 
shareable resource that can 

234
00:12:15,100 --> 00:12:17,800
persist over time. 
And even if you did all have the

235
00:12:17,800 --> 00:12:20,100
same understanding, when you 
walk out of that discussion or 

236
00:12:20,100 --> 00:12:22,800
meeting the most part, you're 
going to remember in six months 

237
00:12:22,800 --> 00:12:25,000
when you have to go back and say
now what were we doing here? 

238
00:12:25,000 --> 00:12:27,600
Or I got to fix that or somebody
requested a change? 

239
00:12:28,000 --> 00:12:30,200
So So sure documentation can get
out of date. 

240
00:12:30,200 --> 00:12:32,100
No question. 
It takes some effort to maintain

241
00:12:32,100 --> 00:12:33,000
it. 
No question. 

242
00:12:33,400 --> 00:12:36,100
But I think a shareable group 
memory is the phrase. 

243
00:12:36,100 --> 00:12:40,000
I like to use for that is a 
valuable asset to have and then 

244
00:12:40,000 --> 00:12:43,400
it's up to the be a to work with
their various stakeholders and 

245
00:12:43,400 --> 00:12:45,800
audiences to figure out. 
Well, what's the best way to 

246
00:12:45,800 --> 00:12:48,100
represent knowledge to meet your
needs? 

247
00:12:48,400 --> 00:12:51,400
When I talk about writing 
requirements, I'm mentally 

248
00:12:51,400 --> 00:12:54,600
translate that into representing
requirements knowledge. 

249
00:12:54,900 --> 00:12:58,800
Sure, natural language. 
Text is the most common But you 

250
00:12:58,800 --> 00:13:02,100
can draw lots of kinds of 
pictures visual analysis models.

251
00:13:02,100 --> 00:13:05,700
We can use tables or prototypes,
or photographs, or mathematical 

252
00:13:05,700 --> 00:13:08,500
Expressions. 
Some people want all the details

253
00:13:08,500 --> 00:13:12,000
other people just want a high 
level view so the goal of trying

254
00:13:12,000 --> 00:13:14,400
to figure out how do we 
communicate all that knowledge. 

255
00:13:14,400 --> 00:13:16,600
Clearly and accurately that's 
really the essence of 

256
00:13:16,600 --> 00:13:19,400
requirements work. 
I think I like the two 

257
00:13:19,400 --> 00:13:21,900
techniques that you mentioned 
telepathy and Clairvoyance. 

258
00:13:21,900 --> 00:13:25,000
I think in the Practical world 
this is what tends to happen 

259
00:13:25,400 --> 00:13:27,200
again especially in the remote 
work live. 

260
00:13:27,200 --> 00:13:29,000
You don't actually sits Side by 
side. 

261
00:13:29,200 --> 00:13:31,400
Yeah, maybe you have a saying, 
you kind of like talk about it 

262
00:13:31,400 --> 00:13:34,600
and then, okay, people just 
split and do their own works and

263
00:13:34,600 --> 00:13:36,200
actually they don't think very 
often. 

264
00:13:36,500 --> 00:13:38,700
So sometimes this 
miscommunication happened, maybe

265
00:13:38,700 --> 00:13:41,500
when you have a particular Edge 
case, you don't want to ask 

266
00:13:41,500 --> 00:13:44,000
because you're afraid that 
person is busy or whatever that 

267
00:13:44,000 --> 00:13:45,900
is. 
So I think that tends to be a 

268
00:13:45,908 --> 00:13:48,800
lot of this unclear and an 
effective communication 

269
00:13:48,800 --> 00:13:50,900
happening. 
And I think one of the 

270
00:13:50,900 --> 00:13:53,200
particular important things that
you mentioned as well, it 

271
00:13:53,200 --> 00:13:55,900
doesn't matter if you have a 
very great team who can 

272
00:13:55,900 --> 00:13:57,900
implement the code in the best 
way. 

273
00:13:58,300 --> 00:14:00,500
But if they're doing the 
requirements wrong, they are 

274
00:14:00,500 --> 00:14:02,800
probably most probably building 
the wrong thing. 

275
00:14:03,200 --> 00:14:06,000
So, tell us more about this 
cause of not having a good 

276
00:14:06,000 --> 00:14:08,200
requirement and someone 
implementing it the best way 

277
00:14:08,200 --> 00:14:11,500
they can. 
Yeah, that's a real source of 

278
00:14:11,500 --> 00:14:14,100
inefficiency. 
I believe, everybody's working 

279
00:14:14,100 --> 00:14:15,000
in. 
Good faith. 

280
00:14:15,200 --> 00:14:17,700
They're trying to do the best 
job, they can based on their 

281
00:14:17,700 --> 00:14:20,700
knowledge and their assumptions.
Are you touched on an important 

282
00:14:20,700 --> 00:14:23,700
Point like an edge case, where 
maybe it's something comes up as

283
00:14:23,700 --> 00:14:27,200
you're implementing a particular
capability and you think of an 

284
00:14:27,200 --> 00:14:29,900
exception that That we haven't 
talked about or you think of a 

285
00:14:29,900 --> 00:14:33,100
particular as you say Edge case 
that we haven't discussed how to

286
00:14:33,100 --> 00:14:36,000
handle that, you have to make 
some assumptions, then we have 

287
00:14:36,000 --> 00:14:38,700
to go chase down the information
and somebody might be busy or 

288
00:14:38,700 --> 00:14:40,600
not available or in a different 
time zone. 

289
00:14:40,600 --> 00:14:44,800
Like you admire what 19 times 
harsh something right now it's 

290
00:14:44,800 --> 00:14:47,900
hard to reach people sometimes 
and so you make assumptions you 

291
00:14:47,900 --> 00:14:50,100
make guesses and you might have 
to go back and fix it. 

292
00:14:50,600 --> 00:14:54,100
And that's the problem. 
Because anytime you have to go 

293
00:14:54,100 --> 00:14:58,100
back and redo something, anytime
you have to fix something 

294
00:14:58,100 --> 00:15:00,800
because Of a misunderstanding or
a piece of knowledge, you didn't

295
00:15:00,800 --> 00:15:03,800
have or something that changed 
that's rework. 

296
00:15:04,100 --> 00:15:07,800
And we work as expensive or 
simply just having errors and 

297
00:15:07,800 --> 00:15:10,200
working in beings, we're going 
to make mistakes and we're going

298
00:15:10,200 --> 00:15:13,200
to write something wrong or 
we're going to be ambiguous in 

299
00:15:13,200 --> 00:15:15,700
the way we say something and 
people interpret it differently 

300
00:15:15,700 --> 00:15:18,200
from what we meant. 
So then you have to go fix it 

301
00:15:18,200 --> 00:15:20,600
later. 
Well anytime there's an error, 

302
00:15:21,000 --> 00:15:24,600
the quicker, you can find that 
error and fix it. 

303
00:15:24,600 --> 00:15:28,100
The less work you have to do to 
fix that, that's why. 

304
00:15:28,300 --> 00:15:31,500
It's so important to I think do,
for example, peer reviews of 

305
00:15:31,500 --> 00:15:34,000
requirements. 
I think the highest leverage 

306
00:15:34,000 --> 00:15:38,400
quality practice that software 
has available is effective, peer

307
00:15:38,400 --> 00:15:41,900
reviews, of requirements 
documents, because errors that 

308
00:15:41,900 --> 00:15:45,200
you find before someone wrote 
code are cheaper to fix than 

309
00:15:45,200 --> 00:15:47,200
afterward. 
No matter what life cycle, 

310
00:15:47,200 --> 00:15:48,900
you're following or how quickly 
you doing it. 

311
00:15:48,900 --> 00:15:51,300
If you have to write the code 
twice that costs, you more than 

312
00:15:51,300 --> 00:15:54,200
if you have to write it once. 
So that's why I think it's so 

313
00:15:54,200 --> 00:15:58,100
important to not necessarily try
to perfect the requirements but 

314
00:15:58,300 --> 00:16:01,400
How to get them better than just
some vague conversation and hope

315
00:16:01,400 --> 00:16:04,400
people can go fill in the blanks
without any confusion or errors.

316
00:16:05,300 --> 00:16:08,100
So, I also notice this kind of 
research when you find the 

317
00:16:08,100 --> 00:16:11,400
errors closer to the right side 
in the value, stream mapping way

318
00:16:11,400 --> 00:16:15,100
in the production, especially it
costs like really exponentially 

319
00:16:15,100 --> 00:16:18,500
expensive rather than you do it 
in the more towards the left, 

320
00:16:18,500 --> 00:16:20,200
that's why this term called 
shift left. 

321
00:16:20,300 --> 00:16:22,700
You try to reduce the error from
the beginning. 

322
00:16:22,900 --> 00:16:25,600
Thanks for sharing that. 
So you mentioned something about

323
00:16:25,600 --> 00:16:28,700
explaining about the key terms. 
Some people refer Were to it as 

324
00:16:28,700 --> 00:16:31,000
the domain, right? 
So, the domain terms domain 

325
00:16:31,000 --> 00:16:34,400
driven design, why having this 
shared understanding? 

326
00:16:34,400 --> 00:16:37,000
Maybe be the terms, maybe be the
calculation. 

327
00:16:37,000 --> 00:16:39,700
Whatever is actually very 
important for any business 

328
00:16:39,700 --> 00:16:42,200
analyst the product manager and 
also development. 

329
00:16:43,000 --> 00:16:45,900
It is that's why we need the 
tools that I think is a good 

330
00:16:45,900 --> 00:16:49,000
idea is to Simply create a 
glossary of terms. 

331
00:16:49,300 --> 00:16:52,500
I was working with a client once
and I was really a requirement 

332
00:16:52,500 --> 00:16:55,200
specification and they were 
planning to Outsource the 

333
00:16:55,200 --> 00:16:57,500
development of this particular 
product. 

334
00:16:57,500 --> 00:17:00,300
So obviously This because when 
you're Outsourcing something, 

335
00:17:00,300 --> 00:17:03,600
you know basically mailing a 
requirements spec or something 

336
00:17:03,600 --> 00:17:06,900
over to other people to do then 
it has to be better than if 

337
00:17:06,900 --> 00:17:09,300
you're sitting down side by side
with someone where you can talk 

338
00:17:09,300 --> 00:17:11,800
about issues as they come up and
fill in the gaps. 

339
00:17:12,400 --> 00:17:15,700
So I was reviewing this for them
and I found there were two terms

340
00:17:15,700 --> 00:17:18,200
that they were using that. 
I thought might mean the same 

341
00:17:18,200 --> 00:17:21,000
thing but I wasn't sure and it 
turned out. 

342
00:17:21,000 --> 00:17:23,900
Yes, those mean exactly the same
thing in that case. 

343
00:17:24,000 --> 00:17:27,200
Let's just pick one term and 
stick to it so that people don't

344
00:17:27,200 --> 00:17:28,400
have to mentally. 
Late. 

345
00:17:28,400 --> 00:17:30,800
It will wonder if they're 
different because every time you

346
00:17:30,800 --> 00:17:34,700
do something like that, we're 
using synonyms or things that 

347
00:17:34,700 --> 00:17:37,800
are close, but maybe not quite 
the same or terms that mean the 

348
00:17:37,800 --> 00:17:39,600
same thing or mean different 
things. 

349
00:17:39,600 --> 00:17:43,000
Rather say, in the business 
domain versus your technical 

350
00:17:43,000 --> 00:17:44,800
world. 
Every time somebody counters one

351
00:17:44,800 --> 00:17:46,300
of those they have to try to 
figure out. 

352
00:17:46,300 --> 00:17:47,900
Okay exactly. 
What does this mean? 

353
00:17:47,900 --> 00:17:50,600
I'm not sure I'd better ask 
somebody or I'll make a guess. 

354
00:17:50,900 --> 00:17:54,500
All of those approaches are less
ideal than just having a common 

355
00:17:54,500 --> 00:17:57,200
vocabulary and understanding to 
minimize some of those 

356
00:17:57,200 --> 00:18:00,400
miscommunication. 
And we'll see if led the 

357
00:18:00,400 --> 00:18:03,200
development team treated as two 
different things, they write it 

358
00:18:03,200 --> 00:18:05,500
in two different variables or 
two different concepts in the 

359
00:18:05,500 --> 00:18:07,500
code. 
The next person who comes again 

360
00:18:07,500 --> 00:18:09,200
like what is this and build on 
top of that? 

361
00:18:09,200 --> 00:18:12,400
So in the end, I think you have 
a very fun Wild Way of 

362
00:18:12,400 --> 00:18:17,200
expressing the requirements. 
In the software itself, in two 

363
00:18:17,200 --> 00:18:19,700
ways, as two different things. 
And then somebody else comes 

364
00:18:19,700 --> 00:18:21,300
along and says, we can just 
refactor. 

365
00:18:21,300 --> 00:18:23,600
This looks like the same thing 
to me, let's just be factored 

366
00:18:23,600 --> 00:18:26,000
into one. 
Maybe they really were different

367
00:18:26,000 --> 00:18:28,700
and you can't combine them, and 
then you have a problem. 

368
00:18:29,300 --> 00:18:31,700
This is what happens when people
are Hasting. 

369
00:18:31,800 --> 00:18:34,000
Sometimes they don't want to 
take the time to do this, they 

370
00:18:34,000 --> 00:18:35,900
want to get to the real work of 
coding. 

371
00:18:36,300 --> 00:18:38,900
And I think thinking is a part 
of the problem or part of the 

372
00:18:38,900 --> 00:18:41,100
solution really. 
It's an important part of what 

373
00:18:41,100 --> 00:18:44,800
we go through and not everything
in software is got to be code, 

374
00:18:45,000 --> 00:18:47,900
thinking can save you writing 
the wrong code, or writing the 

375
00:18:47,900 --> 00:18:50,200
code more than once. 
Thanks for covering this 

376
00:18:50,200 --> 00:18:52,400
requirement. 
But let's move on to the design.

377
00:18:52,700 --> 00:18:55,100
When we mention about coding, of
course, design is one thing, 

378
00:18:55,100 --> 00:18:56,800
right? 
One of the things that you 

379
00:18:56,800 --> 00:19:00,500
highlighted to me is that you 
Can't optimize all desirable 

380
00:19:00,500 --> 00:19:03,300
quality attributes. 
So I think quality attributes. 

381
00:19:03,300 --> 00:19:05,600
Some people call it 
non-functional requirements or 

382
00:19:05,600 --> 00:19:08,400
these kind of terms. 
So tell us more about why we 

383
00:19:08,400 --> 00:19:10,300
can't optimize All Quality 
attributes? 

384
00:19:11,100 --> 00:19:13,300
Yeah, I think that's a real 
important Point. 

385
00:19:13,500 --> 00:19:16,000
There's functional requirements 
and there's non-functional 

386
00:19:16,000 --> 00:19:18,000
requirements. 
Some people don't like the term 

387
00:19:18,000 --> 00:19:19,900
non-functional because it 
doesn't tell you what it is. 

388
00:19:19,900 --> 00:19:22,900
It tells you what it is and I 
think quality attributes is what

389
00:19:22,900 --> 00:19:25,900
people are normally thinking of,
when they say non-functional 

390
00:19:25,900 --> 00:19:28,700
requirements, it's really a lot 
of different dimensions. 

391
00:19:28,900 --> 00:19:31,300
Quality. 
There's no single measure of 

392
00:19:31,300 --> 00:19:33,300
quality. 
That tells people everything 

393
00:19:33,300 --> 00:19:35,200
they need to know about the 
quality of our product or what 

394
00:19:35,200 --> 00:19:38,100
quality they want to see. 
Some of these quality attributes

395
00:19:38,100 --> 00:19:42,500
are extra invisible to users 
like usability, reliability, 

396
00:19:42,500 --> 00:19:46,700
security, robustness and others 
relate more to the products. 

397
00:19:46,700 --> 00:19:49,900
Internal qualities such as 
portability or maintainability 

398
00:19:49,900 --> 00:19:53,200
of verifiability. 
But the reason you can't 

399
00:19:53,200 --> 00:19:56,000
optimize all of those is because
there are a lot of different 

400
00:19:56,000 --> 00:19:57,800
kinds of relationships between 
them. 

401
00:19:57,800 --> 00:20:01,100
So sometimes, When you increase 
one of those desirable 

402
00:20:01,100 --> 00:20:03,400
attributes, it increases another
one. 

403
00:20:03,400 --> 00:20:06,100
That's good. 
If you increase reliability, 

404
00:20:06,100 --> 00:20:08,000
you're going to increase 
availability because the 

405
00:20:08,008 --> 00:20:10,800
software is not going to crash 
as much, but if you increase 

406
00:20:10,800 --> 00:20:15,000
other things that might decrease
a different attribute and I 

407
00:20:15,008 --> 00:20:18,100
think a good example is around 
security, I think we'll all 

408
00:20:18,100 --> 00:20:20,100
agree. 
That multi-factor authentication

409
00:20:20,100 --> 00:20:24,200
is more secure than just using a
simple login password, but 

410
00:20:24,800 --> 00:20:28,100
there's a usability penalty. 
You pay for that because now the

411
00:20:28,108 --> 00:20:30,900
user has to Multiple steps. 
Maybe take more time. 

412
00:20:30,900 --> 00:20:34,200
Certainly take more time and 
might need multiple devices to 

413
00:20:34,200 --> 00:20:36,200
login. 
Sometimes, I've had to use my 

414
00:20:36,200 --> 00:20:39,700
phone so I can watch certain 
shows on streaming TV. 

415
00:20:40,000 --> 00:20:42,100
I understand the security but 
it's a little silly and it's 

416
00:20:42,100 --> 00:20:45,100
clumsy. 
So you have a usability, you 

417
00:20:45,100 --> 00:20:48,600
reduce usability, because your 
increase in security, and then 

418
00:20:48,600 --> 00:20:50,600
other attributes don't have much
of a connection. 

419
00:20:50,900 --> 00:20:53,900
But even here then certain 
quality attribute, they can be 

420
00:20:53,900 --> 00:20:55,900
very complex with multiple 
Dimensions. 

421
00:20:55,900 --> 00:20:58,700
So like usability includes both 
ease of learning. 

422
00:20:58,800 --> 00:21:02,800
Any and ease of use. 
So if you optimize the design 

423
00:21:02,800 --> 00:21:07,500
for ease of learning by new 
users or occasional users, that 

424
00:21:07,500 --> 00:21:10,300
might make the system 
frustrating to use for experts, 

425
00:21:10,300 --> 00:21:12,800
because it slows them down 
waiting through menus, instead 

426
00:21:12,800 --> 00:21:15,200
of being able to do something in
the command line interface. 

427
00:21:16,200 --> 00:21:19,300
So you have to balance those 
different quality attributes 

428
00:21:19,300 --> 00:21:21,500
against each other. 
And that means you need to do 

429
00:21:21,500 --> 00:21:25,000
enough requirements elicitation 
around those aspects of the 

430
00:21:25,000 --> 00:21:28,700
requirements that you 
understand, which of those 

431
00:21:28,700 --> 00:21:32,400
Dimensions are most aligned with
achieving our business 

432
00:21:32,400 --> 00:21:35,800
objectives, which ones are most 
important to our most important 

433
00:21:35,800 --> 00:21:39,100
customer classes. 
For example, it's a really just 

434
00:21:39,100 --> 00:21:41,800
have to decide what does quality
mean to your key stakeholders 

435
00:21:41,800 --> 00:21:45,700
and then align, everyone's work 
towards those objectives and if 

436
00:21:45,700 --> 00:21:49,100
you don't do that, if you don't 
specify the details of these 

437
00:21:49,100 --> 00:21:52,600
desired quality characteristics.
If you don't prioritize them so 

438
00:21:52,600 --> 00:21:55,200
that the designers can make 
appropriate trade-off decisions.

439
00:21:55,200 --> 00:21:58,000
Then you're just lucky. 
If you get whatever quality, you

440
00:21:58,000 --> 00:21:59,800
hope to see in the The final 
product. 

441
00:22:00,300 --> 00:22:02,800
So thanks for highlighting all 
these different trade off 

442
00:22:02,800 --> 00:22:05,200
balance. 
Sometimes when you increase one 

443
00:22:05,200 --> 00:22:07,800
cruelty, attribute the app you 
may be lucky the increases the 

444
00:22:07,800 --> 00:22:11,000
others, but most of the times it
actually reduces the other side 

445
00:22:11,000 --> 00:22:12,900
is like an opposite effect kind 
of thing. 

446
00:22:13,300 --> 00:22:16,500
If we can tie this to the 
requirements back, how do you 

447
00:22:16,500 --> 00:22:17,900
specify these quality 
attributes? 

448
00:22:17,900 --> 00:22:20,700
In the requirements? 
Sometimes, stakeholders product 

449
00:22:20,700 --> 00:22:21,900
people. 
They just sell. 

450
00:22:21,900 --> 00:22:23,200
Yeah. 
You just built to the best 

451
00:22:23,200 --> 00:22:25,900
quality because they are really 
not aware of what cruelty 

452
00:22:25,900 --> 00:22:28,400
attribute to think about or 
maybe they're just too many of 

453
00:22:28,400 --> 00:22:30,300
them. 
So this ellipses, right people 

454
00:22:30,300 --> 00:22:32,500
call it till it is s so many 
realities of death. 

455
00:22:32,800 --> 00:22:35,200
How shall we actually document 
this properly in the 

456
00:22:35,200 --> 00:22:36,700
requirements itself? 
So that is clear. 

457
00:22:36,700 --> 00:22:39,200
It's effective, that's an 
excellent question. 

458
00:22:39,200 --> 00:22:43,600
Henry anyway, the users will not
usually spontaneously tell you 

459
00:22:43,600 --> 00:22:47,300
what their quality expectations 
are they sort of have passed it 

460
00:22:47,300 --> 00:22:50,400
ones that they haven't stated. 
And so part of the business 

461
00:22:50,400 --> 00:22:53,000
analyst job is to start those 
conversations. 

462
00:22:53,000 --> 00:22:55,800
So we can make that a part of 
our exploration of requirements 

463
00:22:55,800 --> 00:22:58,400
during elicitation. 
The other thing that will happen

464
00:22:58,400 --> 00:23:01,000
is even if it comes up in the 
conversation, you're likely to 

465
00:23:01,000 --> 00:23:04,400
get a very simplistic answers. 
So you can't ask a question. 

466
00:23:04,400 --> 00:23:06,700
Like, what are your availability
requirements? 

467
00:23:07,100 --> 00:23:09,800
Probably, nobody knows exactly 
what you're looking for. 

468
00:23:09,800 --> 00:23:12,900
How to answer that question? 
Or they'll say systems got to be

469
00:23:12,900 --> 00:23:14,600
available. 
Anytime somebody wants to use 

470
00:23:14,600 --> 00:23:17,700
it, isn't that obvious, but that
doesn't really help you very 

471
00:23:17,700 --> 00:23:22,300
much. 
So a b, a has to ask more subtle

472
00:23:22,300 --> 00:23:25,000
questions, more direct 
questions, at aspects of it. 

473
00:23:25,000 --> 00:23:27,000
Like are there certain parts of 
the system that it's more 

474
00:23:27,000 --> 00:23:30,400
important to be available? 
All the time versus others. 

475
00:23:30,700 --> 00:23:33,700
Okay, well, that'll give you an 
idea of priorities, for things. 

476
00:23:33,900 --> 00:23:37,300
Also, for example, if we have a 
system that requires periodic 

477
00:23:37,300 --> 00:23:40,000
maintenance, I mean, sometimes I
try to log into a website. 

478
00:23:40,000 --> 00:23:41,700
It's like sorry, we're busy 
right now. 

479
00:23:41,700 --> 00:23:44,100
Fixing something or doing our 
weekly maintenance, you can't 

480
00:23:44,100 --> 00:23:46,700
get in. 
Well, how long can you do that? 

481
00:23:46,800 --> 00:23:50,500
But time windows, can you use 
for scheduled downtime? 

482
00:23:50,900 --> 00:23:54,400
So by asking those kinds of more
specific questions rather than 

483
00:23:54,400 --> 00:23:57,300
very general questions, you 
know, if you ask a user what are

484
00:23:57,308 --> 00:23:59,600
your interoperability? 
Quirements they haven't got the 

485
00:23:59,600 --> 00:24:02,200
foggiest idea what you're 
talking about, but if you ask 

486
00:24:02,200 --> 00:24:04,800
them, are there other systems 
you have to exchange data. 

487
00:24:04,800 --> 00:24:07,600
With our, you have to import 
data, from any place to do your 

488
00:24:07,600 --> 00:24:10,800
job at the system, that might 
give you some information, that 

489
00:24:10,800 --> 00:24:13,800
is in the category of 
interoperability, but you didn't

490
00:24:13,800 --> 00:24:17,400
have to even use that word. 
So, the key thing that I took 

491
00:24:17,400 --> 00:24:21,000
these that ask good questions 
and always try to subtly dig 

492
00:24:21,000 --> 00:24:23,300
deeper and deeper. 
Most of the times we do it for 

493
00:24:23,300 --> 00:24:25,500
the functional part. 
So we asked to create how the 

494
00:24:25,500 --> 00:24:27,500
feature should be. 
How does it work? 

495
00:24:27,700 --> 00:24:29,400
What are the inputs? 
What Output. 

496
00:24:29,700 --> 00:24:32,200
But not the same emphasis is 
taken for this. 

497
00:24:32,200 --> 00:24:34,500
Non functional attributes of a 
quality attributes. 

498
00:24:34,800 --> 00:24:37,500
So I think this is very 
important as good questions and 

499
00:24:37,500 --> 00:24:40,800
always try to dig deeper users. 
Obviously they'll just do you 

500
00:24:40,808 --> 00:24:43,200
know the best quality. 
As you can buy me know, that 

501
00:24:43,200 --> 00:24:47,100
best is subjective right? 
It's contextual depends on the 

502
00:24:47,100 --> 00:24:49,100
situation and depends on who 
you're asking. 

503
00:24:49,600 --> 00:24:52,600
That's correct. 
So after we move to this design,

504
00:24:52,700 --> 00:24:54,800
let's move to the actual work 
itself. 

505
00:24:54,900 --> 00:24:57,300
You categorize this as project 
management. 

506
00:24:57,300 --> 00:24:58,500
We have the requirements we 
have. 

507
00:24:58,700 --> 00:25:01,800
The design we have all these. 
So now time to execute. 

508
00:25:02,000 --> 00:25:04,500
So one of the problems that you 
have is you set work. 

509
00:25:04,500 --> 00:25:08,100
Plans must account for friction.
So tell us more. 

510
00:25:08,100 --> 00:25:10,700
What do you mean by friction? 
Why should we account for it? 

511
00:25:11,000 --> 00:25:14,600
Alright, so here, I'm talking 
about project friction not 

512
00:25:14,600 --> 00:25:17,000
interpersonal, friction. 
That's a whole nother problem 

513
00:25:17,000 --> 00:25:19,400
that we're not going to talk 
about, but it's a very real 

514
00:25:19,400 --> 00:25:23,100
problem, sometimes by fiction. 
Let me give you a good example. 

515
00:25:23,300 --> 00:25:26,800
I was in a software team shortly
before I went off on my own as a

516
00:25:26,808 --> 00:25:28,600
consultant and I heard a 
conversation. 

517
00:25:28,700 --> 00:25:32,800
In between the manager and one 
of the people in my group that 

518
00:25:32,800 --> 00:25:35,700
particular team member was 
providing a specific service to 

519
00:25:35,700 --> 00:25:37,600
a project and the manager asked 
her. 

520
00:25:37,800 --> 00:25:40,600
How much time are you spending 
on that particular service each 

521
00:25:40,600 --> 00:25:42,300
week? 
And she said, eight hours for 

522
00:25:42,300 --> 00:25:45,100
this project and he said, okay 
that means you can work on five 

523
00:25:45,100 --> 00:25:49,300
of them at once then because 5 
times 8 is 40 which is a nominal

524
00:25:49,300 --> 00:25:52,400
work week for many places even 
if nobody really works. 

525
00:25:52,400 --> 00:25:54,700
The move hours, that's what it 
is on paper. 

526
00:25:55,000 --> 00:25:58,500
So that manager was making some 
assumptions. 

527
00:25:58,700 --> 00:26:02,300
Is that we're not valid. 
The problem is, when you start 

528
00:26:02,300 --> 00:26:05,600
getting people, multitasking 
like that, you haven't 

529
00:26:05,600 --> 00:26:08,600
efficiencies because people 
don't really multitask. 

530
00:26:08,600 --> 00:26:10,900
The task switch and just like a 
computer. 

531
00:26:11,100 --> 00:26:13,600
If your task switching too much,
because you're running too many 

532
00:26:13,600 --> 00:26:16,000
things at once. 
It starts slowing down just 

533
00:26:16,000 --> 00:26:19,200
because there's in efficiencies 
associated with the process of 

534
00:26:19,200 --> 00:26:21,400
switching tasks, where there's 
dead time. 

535
00:26:21,400 --> 00:26:25,300
Basically what happens is that 
maybe this woman could do her 

536
00:26:25,300 --> 00:26:27,900
eight hours for this one project
and it's time to move to the 

537
00:26:27,900 --> 00:26:30,500
next one. 
You don't just snap into a new 

538
00:26:30,500 --> 00:26:32,900
way of thinking for that next 
project. 

539
00:26:33,000 --> 00:26:35,800
It takes you a while to get 
everything in your brain, get 

540
00:26:35,800 --> 00:26:38,300
all of your work materials in 
front of you, open all the right

541
00:26:38,300 --> 00:26:42,200
files so that you are ready to 
then be productive. 

542
00:26:42,400 --> 00:26:46,100
It takes time, just a little bit
and you brain probably is that 

543
00:26:46,100 --> 00:26:49,300
the more things you're working 
on at once the more time you 

544
00:26:49,300 --> 00:26:53,600
lose to task switching overhead.
And that's why extensively 

545
00:26:53,600 --> 00:26:55,700
multitasking. 
People are not nearly as 

546
00:26:55,700 --> 00:26:57,500
productive as you think. 
They're going to be. 

547
00:26:57,500 --> 00:27:01,000
They just don't have as many A 
effective hours per week as it 

548
00:27:01,000 --> 00:27:03,700
seems like there ought to be. 
It's just the way people work 

549
00:27:04,000 --> 00:27:07,000
kind of related to that is the 
mindset you've had this 

550
00:27:07,000 --> 00:27:08,800
experience. 
I'm sure Henry, all software 

551
00:27:08,800 --> 00:27:12,100
people have where you get into a
state of flow and that's what 

552
00:27:12,100 --> 00:27:14,500
happens when you're working on 
something and you're really 

553
00:27:14,500 --> 00:27:16,900
productive, you're making great 
progress, you having a good 

554
00:27:16,900 --> 00:27:18,900
time. 
All of a sudden you look up and 

555
00:27:18,900 --> 00:27:22,200
realize oh I forgot to eat lunch
because I was really cranking 

556
00:27:22,200 --> 00:27:24,100
along. 
He said that experience, I'm 

557
00:27:24,100 --> 00:27:27,800
sure and so what happens if that
state of flow gets interrupted 

558
00:27:28,000 --> 00:27:29,700
you're working on. 
Like that and then you get a 

559
00:27:29,700 --> 00:27:33,700
phone call or text message and 
like Pavlov's dog. 

560
00:27:33,700 --> 00:27:36,300
We all check the phone 
immediately and see what the 

561
00:27:36,300 --> 00:27:39,000
message is about. 
Or somebody calls you, the 

562
00:27:39,000 --> 00:27:42,100
question, what happens to you 
when you're in that kind of 

563
00:27:42,100 --> 00:27:43,700
mode? 
You know what I'm talking about,

564
00:27:44,200 --> 00:27:45,000
right? 
Definitely. 

565
00:27:45,000 --> 00:27:46,700
I mean, I will brain work 
smartly, right? 

566
00:27:46,700 --> 00:27:48,700
So when you have this 
Interruption, especially when 

567
00:27:48,700 --> 00:27:51,600
you think it's urgent, you kind 
of like wipe the whole thing in 

568
00:27:51,600 --> 00:27:54,600
your brain and do the more 
urgent task, maybe you pick it 

569
00:27:54,600 --> 00:27:56,700
up and then your contacts all 
change. 

570
00:27:56,900 --> 00:27:58,900
But then when you have to go 
back to the floor, State. 

571
00:27:58,900 --> 00:28:01,200
I think it takes a while. 
So the booting time is not as 

572
00:28:01,200 --> 00:28:02,600
straightforward. 
Now. 

573
00:28:02,600 --> 00:28:05,300
That's absolutely right. 
People have measured that and it

574
00:28:05,300 --> 00:28:07,000
can take like, 15 minutes or 
something. 

575
00:28:07,000 --> 00:28:10,300
To get back to where you were. 
Some people are better at 

576
00:28:10,300 --> 00:28:12,700
multitasking than others. 
I don't know if I just have a 

577
00:28:12,708 --> 00:28:14,800
short attention span or what, 
but, I'm pretty good at 

578
00:28:14,800 --> 00:28:16,700
switching back and forth between
things. 

579
00:28:16,700 --> 00:28:19,100
I'm working on something for a 
little bit, then coming back and

580
00:28:19,100 --> 00:28:22,200
doing something else. 
When I was a manager of a 

581
00:28:22,200 --> 00:28:25,200
software group, I had a guy who 
is not as productive, as he 

582
00:28:25,200 --> 00:28:26,100
could have been a should have 
been. 

583
00:28:26,100 --> 00:28:29,300
He was very bright, very 
creative but he Couldn't put 

584
00:28:29,300 --> 00:28:32,300
work out the door as fast as I 
thought he should. 

585
00:28:32,500 --> 00:28:36,000
So, one of the things that we 
tried was having him block out 

586
00:28:36,000 --> 00:28:39,600
chunks of time, try to eliminate
some of this Interruption driven

587
00:28:39,600 --> 00:28:43,100
flow loss, so that you get 
longer periods of productive 

588
00:28:43,100 --> 00:28:44,800
work. 
And then actually work pretty 

589
00:28:44,800 --> 00:28:46,300
well. 
There really is, basically, you 

590
00:28:46,300 --> 00:28:48,800
don't deal with emails. 
You don't answer the phone for 

591
00:28:48,800 --> 00:28:51,100
the morning, you can do that in 
the afternoon and get caught up 

592
00:28:51,100 --> 00:28:53,600
in all the trivial things that 
you have to do. 

593
00:28:53,800 --> 00:28:56,900
But if you block out your time 
so that you get bigger chunks of

594
00:28:56,900 --> 00:28:59,800
an interrupted work then, You're
more productive. 

595
00:29:00,100 --> 00:29:02,400
So that's I think the biggest 
source of friction and what that

596
00:29:02,400 --> 00:29:05,200
turns into when it comes to 
project management as the 

597
00:29:05,200 --> 00:29:08,000
manager, or even as a team 
member, you need to figure out 

598
00:29:08,000 --> 00:29:11,500
what's your number of effective 
project hours per week on 

599
00:29:11,500 --> 00:29:14,700
average and use that number for 
estimating. 

600
00:29:14,700 --> 00:29:17,800
And for planning, instead of 
trying to say, okay, I got 40 

601
00:29:17,800 --> 00:29:20,000
hours to work this week. 
What am I going to do? 

602
00:29:20,000 --> 00:29:22,500
Because you don't have 40 hours,
you just don't. 

603
00:29:23,100 --> 00:29:24,800
Yes. 
I you don't account for sure 

604
00:29:24,800 --> 00:29:28,500
like full 8 hours a day because 
we chat we take coffee breaks. 

605
00:29:28,700 --> 00:29:32,100
C and F and I think what you 
mentioned speaks True to this 

606
00:29:32,100 --> 00:29:34,600
concept called lean. 
So limiting your work in 

607
00:29:34,600 --> 00:29:38,100
progress done multitask too much
unplanned work as well. 

608
00:29:38,300 --> 00:29:40,600
If you have interruptions that's
kind of like unplanned work, 

609
00:29:40,600 --> 00:29:44,200
maybe incidents on call or maybe
some managers asking about 

610
00:29:44,200 --> 00:29:47,600
certain things in Urgent. 
And I think another friction if 

611
00:29:47,600 --> 00:29:51,500
I make guesses about dependency 
where you are, depending on some

612
00:29:51,500 --> 00:29:54,900
people or team or maybe some 
kind of work that has to be 

613
00:29:54,900 --> 00:29:58,600
there, but it's not available. 
Is it also counted as one of The

614
00:29:58,608 --> 00:30:00,800
friction in the project that you
have to account. 

615
00:30:01,300 --> 00:30:04,900
Yeah, that would be really a 
matter of creating rate states 

616
00:30:04,900 --> 00:30:07,300
where you're thinking, okay? 
I have to do these things. 

617
00:30:07,300 --> 00:30:09,500
And as you point out, there are 
dependencies, I need this piece 

618
00:30:09,500 --> 00:30:12,100
of information where I need all 
module that. 

619
00:30:12,100 --> 00:30:14,900
Somebody else was writing that 
has to be available before I can

620
00:30:15,000 --> 00:30:18,200
integrate it with my modules. 
If it's not there, then you 

621
00:30:18,200 --> 00:30:21,300
can't finish your task. 
So I think it's important to 

622
00:30:21,300 --> 00:30:25,300
recognize those dependencies and
build some slack time into your 

623
00:30:25,300 --> 00:30:27,800
schedules to account for the 
possibility that not. 

624
00:30:27,800 --> 00:30:31,000
Everything is going to Exactly, 
like clockwork to get a little 

625
00:30:31,000 --> 00:30:33,900
depend on the work environment. 
Because, for example, if you're 

626
00:30:33,900 --> 00:30:38,000
in a situation where you're not 
only working on a new product, 

627
00:30:38,000 --> 00:30:41,100
but you're maintaining a 
previous product or you have to 

628
00:30:41,100 --> 00:30:45,200
go back and fix something from 
previous iteration, those kinds 

629
00:30:45,200 --> 00:30:47,700
of interruptions have to be 
planned for because that's 

630
00:30:47,700 --> 00:30:50,500
another form of friction that's 
going to slow you down and you 

631
00:30:50,500 --> 00:30:52,500
didn't plan for it. 
But you know that maybe on 

632
00:30:52,500 --> 00:30:55,700
average, I'm going to have five 
hours a week that I have to deal

633
00:30:55,700 --> 00:30:58,500
with those kinds of things. 
So, take all of that out of 

634
00:30:58,600 --> 00:31:01,700
You're planning for how you're 
going to turn physical work 

635
00:31:01,700 --> 00:31:06,100
hours into calendar time. 
Speaking about effective Alice, 

636
00:31:06,100 --> 00:31:08,300
giving estimations, project 
management. 

637
00:31:08,300 --> 00:31:10,600
Sometimes it's all about 
estimating, right? 

638
00:31:10,700 --> 00:31:13,400
You have these two very 
interesting pearls about 

639
00:31:13,400 --> 00:31:15,100
estimation, which I'll read it 
here. 

640
00:31:15,500 --> 00:31:18,500
Don't give anyone an estimate 
off the top of your head. 

641
00:31:18,700 --> 00:31:21,700
And the other one is based on 
what the recipient wants to 

642
00:31:21,700 --> 00:31:23,800
hear. 
So I think software developer 

643
00:31:24,200 --> 00:31:27,600
most guilty of giving estimates,
right of the top of the mind and

644
00:31:27,600 --> 00:31:30,000
also what She the requester ones
here. 

645
00:31:30,000 --> 00:31:34,000
So tell us more about why this 
is not the right way I guess 

646
00:31:34,000 --> 00:31:36,000
symmetrical. 
Best guess as to what's going to

647
00:31:36,000 --> 00:31:38,700
happen in the future based on 
what, you know, and some 

648
00:31:38,700 --> 00:31:40,800
assumptions. 
So maybe you're walking down the

649
00:31:40,800 --> 00:31:44,300
hall and you run into one of 
your customers who says, hey, 

650
00:31:44,300 --> 00:31:46,500
I've got an idea for some 
feature, I want to add to the 

651
00:31:46,500 --> 00:31:49,700
thing you're working on now, so 
they tell you their idea and you

652
00:31:49,700 --> 00:31:51,100
say, yeah, I think we can work 
that in. 

653
00:31:51,100 --> 00:31:53,100
That's not too bad. 
Sure no problem. 

654
00:31:53,400 --> 00:31:56,200
So then you go back to your 
office and start thinking about 

655
00:31:56,200 --> 00:31:57,300
it. 
And the more you think about it,

656
00:31:57,300 --> 00:32:00,200
the bigger it gets, There's all 
these hidden connections is all 

657
00:32:00,200 --> 00:32:03,000
these Ripple effects. 
It was all these other obvious 

658
00:32:03,000 --> 00:32:06,700
depth of details and then you 
realize that maybe it's actually

659
00:32:06,700 --> 00:32:08,800
the opposite of what someone 
else agreed to do for a 

660
00:32:08,808 --> 00:32:10,500
different customer the day 
before. 

661
00:32:10,500 --> 00:32:14,700
So, it gets bigger and bigger. 
But when you told the person the

662
00:32:14,700 --> 00:32:17,700
bumped into the Hall, sure we 
can do this in three days, that 

663
00:32:17,700 --> 00:32:19,700
was an estimate. 
Maybe off the top of your head, 

664
00:32:19,700 --> 00:32:22,200
based on what you knew at the 
time, but it sounded like a 

665
00:32:22,208 --> 00:32:24,200
commitment to the person who 
heard it. 

666
00:32:24,400 --> 00:32:27,000
They don't necessarily know the 
difference between a commitment 

667
00:32:27,000 --> 00:32:31,600
and an estimate So I think the 
best answer for any requests 

668
00:32:31,600 --> 00:32:34,700
about an estimate is to say, let
me get back to you on that 

669
00:32:35,000 --> 00:32:37,700
instead of just giving them an 
estimate, based on very little 

670
00:32:37,700 --> 00:32:41,600
analysis and information, get 
the information go, think about 

671
00:32:41,600 --> 00:32:43,600
it. 
Do a more careful job of 

672
00:32:43,600 --> 00:32:46,800
thinking about what it's going 
to take to do that, then offer 

673
00:32:46,800 --> 00:32:49,300
an estimate. 
Also, if you give a point 

674
00:32:49,300 --> 00:32:52,700
estimate like okay, that's going
to take 40 hours, you can't 

675
00:32:52,700 --> 00:32:54,300
predict the future that 
accurately. 

676
00:32:54,500 --> 00:32:57,100
We might be better off saying. 
I think it will take between 30 

677
00:32:57,100 --> 00:33:00,000
and 50 hours. 
The problem is people don't like

678
00:33:00,000 --> 00:33:02,800
that managers in particular 
people who have to write the 

679
00:33:02,800 --> 00:33:06,000
check or allocate resources, 
they don't like that kind of 

680
00:33:06,000 --> 00:33:08,300
fuzziness but that's the 
reality. 

681
00:33:08,500 --> 00:33:11,300
And I always tell people in my 
classes, I'm not always crazy 

682
00:33:11,300 --> 00:33:14,700
about reality but it's all I've 
got so I have to work with it 

683
00:33:14,900 --> 00:33:18,300
and the reality is we can't 
predict these things precisely. 

684
00:33:18,700 --> 00:33:22,000
So I think giving estimates in 
the form of a range is better. 

685
00:33:22,300 --> 00:33:25,500
So that's the kind of my point 
about the idea of not giving 

686
00:33:25,500 --> 00:33:27,300
people estimates off the top of 
your head. 

687
00:33:27,800 --> 00:33:31,000
So there's the other Rule that 
says you estimate you give 

688
00:33:31,000 --> 00:33:33,700
someone should not depend on 
what you think they want to hear

689
00:33:34,000 --> 00:33:37,000
you mentioned that one as well 
and I can tell you a story about

690
00:33:37,000 --> 00:33:39,300
that. 
So I saw a conversation between 

691
00:33:39,300 --> 00:33:43,100
a project leader and a senior 
manager, senior manager asks, 

692
00:33:43,100 --> 00:33:46,100
how long is it going to take you
to do this project project 

693
00:33:46,100 --> 00:33:49,900
manager said about two years and
the senior manager said no 

694
00:33:49,900 --> 00:33:51,800
that's too long. 
I need it in six months. 

695
00:33:52,200 --> 00:33:54,600
So what did the project manager?
Say okay. 

696
00:33:55,200 --> 00:33:58,300
Well what changed in those 
seconds, you know he didn't get 

697
00:33:58,500 --> 00:34:01,800
Or times as productive, he 
didn't get more people, the 

698
00:34:01,800 --> 00:34:04,900
problem didn't get four times 
smaller, none of those things 

699
00:34:04,900 --> 00:34:08,500
happened, he just said, okay, 
well you want in six months so 

700
00:34:08,500 --> 00:34:11,199
I'll say I can do that. 
That's just a lie. 

701
00:34:11,199 --> 00:34:14,100
Basically. 
I think knowing that someone's 

702
00:34:14,100 --> 00:34:16,500
not happy with your estimate 
should lead to a conversation. 

703
00:34:16,699 --> 00:34:19,500
Should lead to negotiation and 
say, okay, what knobs can we 

704
00:34:19,500 --> 00:34:22,300
turn to make this happen? 
Maybe my estimates wrong, but 

705
00:34:22,300 --> 00:34:24,600
was you estimate, how did you 
come up with your estimate of 

706
00:34:24,600 --> 00:34:26,800
six months them? 
See your manager? 

707
00:34:26,800 --> 00:34:30,699
Did not have an estimate of six.
See our goal, the project 

708
00:34:30,699 --> 00:34:32,500
manager. 
In this case didn't have an 

709
00:34:32,500 --> 00:34:36,000
estimate either, he had a guess.
So if you're guessing you're 

710
00:34:36,000 --> 00:34:38,400
going won't match. 
We're going to have to work that

711
00:34:38,400 --> 00:34:42,400
out but I think actually doing 
an analytical estimate based on 

712
00:34:42,400 --> 00:34:44,699
some thought process, some 
historical data. 

713
00:34:44,699 --> 00:34:47,800
Some depth of understanding is 
going to let you compare. 

714
00:34:47,800 --> 00:34:50,199
The differences may be in 
assumptions that you're making 

715
00:34:50,600 --> 00:34:52,600
the, don't just change it 
because someone doesn't like it,

716
00:34:52,800 --> 00:34:55,199
that doesn't change the future. 
If I want to go on a picnic 

717
00:34:55,199 --> 00:34:57,400
tomorrow and someone tells me 
it's going to rain. 

718
00:34:57,400 --> 00:34:59,400
I can't just say, oh well, I 
don't want it to rain. 

719
00:35:00,200 --> 00:35:03,000
Yeah, I don't, that's simply 
change the future, right? 

720
00:35:03,700 --> 00:35:06,200
Thanks for explaining these two 
different perspectives, because 

721
00:35:06,200 --> 00:35:10,100
sometimes managers or leaders 
have their own goals and the 

722
00:35:10,100 --> 00:35:12,800
software development. 
All we have is guess, we don't 

723
00:35:12,800 --> 00:35:14,900
actually know unless we have 
done it before. 

724
00:35:14,900 --> 00:35:18,400
It's like a repetitive work. 
We know the gist of the work but

725
00:35:18,400 --> 00:35:20,900
they are most of the time we 
just guess which brings us to 

726
00:35:20,900 --> 00:35:24,300
the next Pearl, which actually 
is an extension of this problem.

727
00:35:24,600 --> 00:35:26,900
So you have given a range of an 
estimate, maybe one month to 

728
00:35:26,900 --> 00:35:28,400
three months. 
Obviously, man. 

729
00:35:28,500 --> 00:35:30,500
Just don't like that kind of 
ambiguity. 

730
00:35:30,900 --> 00:35:33,500
This like a big brains anyway, 
and they're kind of like, put 

731
00:35:33,500 --> 00:35:36,400
pressure this often happens. 
I'm sure it's everywhere. 

732
00:35:36,800 --> 00:35:39,700
They'll put pressure, but your 
poll says that no matter how 

733
00:35:39,700 --> 00:35:43,300
much pressure others exert, 
never make a commitment. 

734
00:35:43,300 --> 00:35:44,600
You cannot fulfill. 
Okay. 

735
00:35:44,600 --> 00:35:47,900
This is very tough, but tell us 
more about this thing. 

736
00:35:48,600 --> 00:35:50,800
I think I remember this and 
that's actually Point. 

737
00:35:50,800 --> 00:35:53,900
Let me back up just a bit. 
These portals didn't come to me 

738
00:35:53,900 --> 00:35:56,600
on stone tablets or anything. 
These are things that I just 

739
00:35:56,600 --> 00:35:59,400
learned over my career either. 
Sure from my personal 

740
00:35:59,400 --> 00:36:03,500
experiences or from clients that
I've worked with or from things 

741
00:36:03,500 --> 00:36:05,100
that I've read and heard from 
other people. 

742
00:36:05,100 --> 00:36:08,300
So I just accumulated these 
little bits of knowledge that I 

743
00:36:08,300 --> 00:36:11,300
found helpful and relevant. 
The reason I wrote this book was

744
00:36:11,300 --> 00:36:14,400
to try to share some of those 
with other people because you've

745
00:36:14,400 --> 00:36:17,400
probably noticed that experience
is a great teacher but it's also

746
00:36:17,400 --> 00:36:21,200
painful and slow. 
And we learn a lot from mistakes

747
00:36:21,200 --> 00:36:24,000
that we made. 
I wrote this book so that people

748
00:36:24,000 --> 00:36:26,300
maybe don't have to make all the
same mistakes that I made. 

749
00:36:26,300 --> 00:36:28,300
And I've seen other people make 
one. 

750
00:36:28,600 --> 00:36:30,600
The stories. 
I think that applies. 

751
00:36:30,600 --> 00:36:33,000
In this case how did I learn 
this lesson about? 

752
00:36:33,000 --> 00:36:35,100
Never making a commitment. 
You can't fulfill. 

753
00:36:35,400 --> 00:36:38,400
So one time I was leading a 
process Improvement effort in a 

754
00:36:38,400 --> 00:36:42,200
division of about 450 software 
and systems engineers and a big 

755
00:36:42,200 --> 00:36:45,900
company, usually very organized.
Systematic process Improvement, 

756
00:36:45,900 --> 00:36:46,900
thing back. 
When those were very 

757
00:36:46,900 --> 00:36:50,300
fashionable, me and my manager 
had a meeting with the senior 

758
00:36:50,300 --> 00:36:53,500
manager of this division, who is
like, total levels above me on 

759
00:36:53,500 --> 00:36:57,000
the organization chart, you 
wanted to know what was our plan

760
00:36:57,000 --> 00:37:00,000
for achieving a specific goal. 
Goal with this big initiative. 

761
00:37:00,200 --> 00:37:02,800
So I told them how long I 
thought it was going to take us 

762
00:37:02,800 --> 00:37:05,800
to achieve that goal. 
And he was one of these guys 

763
00:37:05,800 --> 00:37:07,200
had. 
No, that's too long I wanted 

764
00:37:07,200 --> 00:37:09,400
sooner. 
He's the kind of manager and 

765
00:37:09,400 --> 00:37:12,300
little lot of managers like 
this, who will say, don't tell 

766
00:37:12,300 --> 00:37:14,400
me you can't do it. 
Tell me what I have to do to 

767
00:37:14,400 --> 00:37:17,200
enable you to do it. 
And that sounds very 

768
00:37:17,200 --> 00:37:20,200
collaborative. 
But in fact, it really wasn't in

769
00:37:20,200 --> 00:37:23,100
this case. 
So I explained to him how we 

770
00:37:23,100 --> 00:37:25,900
came up with our estimates by 
looking at, with other companies

771
00:37:25,900 --> 00:37:28,300
had done with the similar 
approach and stuff and you know,

772
00:37:28,500 --> 00:37:31,600
Really pressuring me to commit 
to doing this goal in six 

773
00:37:31,600 --> 00:37:32,800
months. 
When I knew that, there was 

774
00:37:32,900 --> 00:37:35,300
absolutely no way we could do 
that. 

775
00:37:35,500 --> 00:37:38,900
So, finally I said, said I'm not
going to commit to that and you 

776
00:37:38,900 --> 00:37:41,000
just kind of looked at me I 
don't think anybody had ever 

777
00:37:41,000 --> 00:37:43,800
said that to him before. 
He didn't really know what to 

778
00:37:43,800 --> 00:37:45,800
say. 
No, I was wearing nervous 

779
00:37:46,000 --> 00:37:48,600
telling this guy, all these 
levels up above me that I 

780
00:37:48,600 --> 00:37:50,200
couldn't commit to what he was 
requesting. 

781
00:37:50,500 --> 00:37:53,900
But I knew that no matter how 
hard we worked, no matter how 

782
00:37:53,900 --> 00:37:57,200
smoothly things went, it's 
simply could not happen in six 

783
00:37:57,200 --> 00:37:58,700
months, it just wasn't doing 
Abel. 

784
00:37:59,000 --> 00:38:01,700
So I told him I couldn't do it. 
So he said, okay, you're not 

785
00:38:01,700 --> 00:38:03,100
going to commit well. 
Now, what? 

786
00:38:03,400 --> 00:38:05,700
So we talked about it, we 
negotiated some, and he 

787
00:38:05,700 --> 00:38:09,400
eventually agreed to the 
schedule that I had proposed to 

788
00:38:09,400 --> 00:38:11,300
him. 
Once I explain how we came up 

789
00:38:11,300 --> 00:38:14,300
with that, but my boss who was 
with me in the meeting, he was a

790
00:38:14,308 --> 00:38:16,100
little nervous. 
He went back saying Carl told 

791
00:38:16,100 --> 00:38:18,800
Fred, he wasn't going to commit,
but I think that's the right 

792
00:38:18,800 --> 00:38:22,100
thing to do, don't you? 
I mean, if you can't do it, what

793
00:38:22,100 --> 00:38:25,800
value is served by telling 
someone that you will, I don't 

794
00:38:25,800 --> 00:38:28,300
think that accomplishes anything
other than temporarily. 

795
00:38:28,500 --> 00:38:30,300
Is someone feel better and you 
feel worse? 

796
00:38:31,200 --> 00:38:34,200
I think it also goes back to the
psychological safety, this term 

797
00:38:34,200 --> 00:38:37,200
being discussed a lot these days
if you don't have psychological 

798
00:38:37,200 --> 00:38:39,900
safety in the team, when the 
manager pressures you a, of 

799
00:38:39,900 --> 00:38:43,400
course you will say okay for the
sake of my job, just make that 

800
00:38:43,400 --> 00:38:47,100
commitment at that point in time
and you have to make that choice

801
00:38:47,400 --> 00:38:50,700
if it comes down to lying or 
promising something that you 

802
00:38:50,700 --> 00:38:53,500
almost certainly can't do and 
might burn yourself out in the 

803
00:38:53,500 --> 00:38:55,800
process. 
If it comes down to that, we're 

804
00:38:55,800 --> 00:38:59,200
losing a job but you might 
actually enjoy Oi, you have to 

805
00:38:59,200 --> 00:39:01,500
decide, what are you willing to 
do for that? 

806
00:39:01,700 --> 00:39:05,900
But my personal philosophy is to
under commit and over-deliver, 

807
00:39:06,300 --> 00:39:09,300
to me that works. 
It's not as aggressive as what 

808
00:39:09,300 --> 00:39:11,300
some people might do. 
But on the other hand be 

809
00:39:11,300 --> 00:39:14,900
unreliable, if you ask me to do 
something and I tell you what, 

810
00:39:14,900 --> 00:39:17,200
I'm going to have it done, it's 
going to be done by then you can

811
00:39:17,200 --> 00:39:20,200
count on that and I think that's
maybe better than saying, what 

812
00:39:20,200 --> 00:39:21,000
is it? 
What is it? 

813
00:39:21,000 --> 00:39:22,600
You said you'd be bunting. 
You, why aren't you done? 

814
00:39:23,200 --> 00:39:26,200
In fact, maybe if you said ok 
I'm not going to commit on that.

815
00:39:26,200 --> 00:39:29,500
Some sneaky leaders might find 
another Then who will make that 

816
00:39:29,500 --> 00:39:31,900
commitment, and he will say, 
okay, this person say, actually 

817
00:39:31,900 --> 00:39:34,200
can be done. 
So then now you're in a like 

818
00:39:34,200 --> 00:39:37,600
that, I'm a phenomenal, it's 
called the best liar wins. 

819
00:39:39,000 --> 00:39:41,500
This is speaking about all 
these, as the main and trying to

820
00:39:41,500 --> 00:39:44,800
come up with the agreement on 
the timeline and all that, some 

821
00:39:44,800 --> 00:39:48,700
people tend to associate time, 
spent on the effort and the 

822
00:39:48,700 --> 00:39:50,600
quality. 
So if you want to reduce time, 

823
00:39:50,600 --> 00:39:53,800
okay, let's just reduce the 
quality but actually your next 

824
00:39:53,800 --> 00:39:55,500
Pearl. 
Your next category of the Pearl 

825
00:39:55,500 --> 00:39:58,300
is about quality and one of the 
things that you highlighted is 

826
00:39:58,400 --> 00:40:01,800
about high quality naturally 
leads to higher productivity. 

827
00:40:02,100 --> 00:40:05,300
So tell us about this quality 
thing because it's always put as

828
00:40:05,300 --> 00:40:07,800
a lever that you can play, 
right? 

829
00:40:07,800 --> 00:40:10,600
In fact, one of the classic 
things that shows up in project 

830
00:40:10,600 --> 00:40:14,200
management is the Iron Triangle.
You heard of the Iron Triangle 

831
00:40:14,200 --> 00:40:17,400
or the triple constraint, is the
other term that used for that. 

832
00:40:17,700 --> 00:40:21,100
It's shown in various ways but 
it basically boils down to what 

833
00:40:21,100 --> 00:40:23,800
do you want? 
Good fast or cheap pick to 

834
00:40:24,300 --> 00:40:25,900
recognizing that there are 
trade-offs. 

835
00:40:25,900 --> 00:40:29,000
And you just said, well, okay, 
you wanted faster I can That you

836
00:40:29,000 --> 00:40:32,800
care if it works well because if
I go too fast, then I may have 

837
00:40:32,800 --> 00:40:34,200
enough problems. 
But it doesn't work. 

838
00:40:34,300 --> 00:40:37,300
How good is that? 
But the problem here is that 

839
00:40:37,300 --> 00:40:39,200
everybody wants to be more 
productive. 

840
00:40:39,500 --> 00:40:42,400
And if you're looking to acquire
productivity, either as an 

841
00:40:42,400 --> 00:40:45,500
individual, or as a team isn't, 
as great as you'd like, one 

842
00:40:45,500 --> 00:40:48,500
thing you might find, is that 
you spend too much time on 

843
00:40:48,500 --> 00:40:51,000
rework. 
My mission Bree work earlier and

844
00:40:51,000 --> 00:40:53,900
that just is a productivity 
killer teams plan to get a 

845
00:40:53,908 --> 00:40:56,600
certain amount of work done in a
particular time, but then they 

846
00:40:56,600 --> 00:41:00,400
have to fix problems found in 
Heated work or maybe reallocate 

847
00:41:00,400 --> 00:41:03,500
effort to repair a production 
system, a way to boost 

848
00:41:03,500 --> 00:41:06,900
productivity then is to create 
high-quality software from the 

849
00:41:06,900 --> 00:41:10,700
outset so that teams can spend 
less time on rework, both doing 

850
00:41:10,700 --> 00:41:13,400
development and following 
reliefs. 

851
00:41:13,700 --> 00:41:16,200
I'm going to so long time ago I 
was actually in junior high 

852
00:41:16,200 --> 00:41:19,300
school in which shop my really 
first will project, we have this

853
00:41:19,300 --> 00:41:22,300
chunk of wood and we had to just
use various tools on a drill 

854
00:41:22,300 --> 00:41:24,500
holes, cut it to size that sort 
of thing. 

855
00:41:24,800 --> 00:41:27,200
And if you got it too small or 
put the hole in the wrong place,

856
00:41:27,200 --> 00:41:28,200
you have to get a new chunk of 
wood. 

857
00:41:28,400 --> 00:41:32,400
Start over took me nine tries 
before I finally got it, right? 

858
00:41:32,600 --> 00:41:35,400
And I noticed that one of the 
kids in the class got it, right?

859
00:41:35,400 --> 00:41:38,300
And just two tries and he was 
done before me. 

860
00:41:38,900 --> 00:41:40,800
He was going slower and more 
carefully. 

861
00:41:40,800 --> 00:41:43,900
He wasn't making mistakes and so
he didn't have to keep starting 

862
00:41:43,900 --> 00:41:46,000
over and fixing it. 
So that's a lesson. 

863
00:41:46,000 --> 00:41:48,900
I've learned a long time ago, so
I hate rude work. 

864
00:41:48,900 --> 00:41:50,500
I hate doing something over 
that. 

865
00:41:50,500 --> 00:41:53,300
I've already done once some of 
it's unavoidable, it's the 

866
00:41:53,300 --> 00:41:56,500
nature of what we do that. 
I think we just sort of accept 

867
00:41:56,500 --> 00:42:00,200
it as a normal part of software.
Development and we don't really 

868
00:42:00,400 --> 00:42:03,800
focus on it as I leave her as 
you said for increasing 

869
00:42:03,800 --> 00:42:07,600
productivity and not having to 
fix stuff organizations. 

870
00:42:07,600 --> 00:42:11,200
That do track how much of their 
portal software effort goes into

871
00:42:11,200 --> 00:42:15,000
rework can get some very scary 
numbers sometimes up to 40 or 50

872
00:42:15,000 --> 00:42:18,300
percent of their total effort is
doing things over there were 

873
00:42:18,300 --> 00:42:20,900
already done once and that's why
I think it's so important. 

874
00:42:20,900 --> 00:42:24,100
As you put it out earlier to 
push, quality, to the left. 

875
00:42:24,300 --> 00:42:28,200
Let's try to find problems 
earlier and quicker because that

876
00:42:28,400 --> 00:42:31,300
Means we can fix them cheaper 
and not have to spend so much. 

877
00:42:31,300 --> 00:42:33,600
We work later on. 
Have you ever worked in an 

878
00:42:33,600 --> 00:42:36,500
organization where people 
measured rework our thought of 

879
00:42:36,500 --> 00:42:41,000
it as an explicit thing? 
It's pretty rare, very rare to 

880
00:42:41,000 --> 00:42:44,500
have this kind of measurement 
and maybe we can use the analogy

881
00:42:44,500 --> 00:42:47,600
of the number of bugs found. 
Yeah, it's probably not the same

882
00:42:47,600 --> 00:42:49,900
thing, right? 
Yeah, certainly related because 

883
00:42:49,900 --> 00:42:53,100
that's where the reward comes 
from, but I think the thing we 

884
00:42:53,100 --> 00:42:56,000
want to try to do, is to 
minimize avoidable rework. 

885
00:42:56,200 --> 00:42:59,300
There's always going to be some 
people are Are doing knowledge 

886
00:42:59,300 --> 00:43:01,200
work. 
Human communication is 

887
00:43:01,200 --> 00:43:03,200
imperfect. 
We can't predict the future 

888
00:43:03,200 --> 00:43:06,200
perfectly, but I think if we 
improve our initial work 

889
00:43:06,200 --> 00:43:09,100
quality, we can minimize the 
avoidable reword. 

890
00:43:09,400 --> 00:43:12,700
One of the ways we can make this
more visible is to, you know, 

891
00:43:12,700 --> 00:43:17,900
our project planning call-out 
rework as a discrete tasks. 

892
00:43:18,600 --> 00:43:21,000
A lot of times you might say, 
okay, we're going to do this and

893
00:43:21,000 --> 00:43:22,700
we're going to build something 
and we're going to integrate it.

894
00:43:22,700 --> 00:43:24,500
And then we're going to test it 
and we're going to move on. 

895
00:43:24,800 --> 00:43:26,300
Well that's never been my 
experience. 

896
00:43:26,300 --> 00:43:29,200
My experience has been you build
it, you Did you test it? 

897
00:43:29,200 --> 00:43:32,400
Then you fix some stuff then 
they re test it and eventually 

898
00:43:32,400 --> 00:43:36,100
you know, Ron. 
But we sort of barely rework is 

899
00:43:36,100 --> 00:43:39,700
part of that quality control. 
Activity of testing a review. 

900
00:43:39,900 --> 00:43:44,100
I think it's better to make it a
specific explicit task and then 

901
00:43:44,100 --> 00:43:46,800
you can actually measure how 
much time did we spend fixing 

902
00:43:46,800 --> 00:43:50,200
things after the test or fixing 
things because of problems found

903
00:43:50,200 --> 00:43:52,700
during a peer review? 
And that gives you an idea of 

904
00:43:52,700 --> 00:43:55,100
how much rework you're actually 
doing and then you can ask 

905
00:43:55,100 --> 00:43:56,800
yourselves. 
Is that acceptable? 

906
00:43:57,100 --> 00:43:59,400
Is that reasonable? 
All amount of our effort or 

907
00:43:59,400 --> 00:44:02,500
should we say that's too much. 
Let's try to find some ways to 

908
00:44:02,500 --> 00:44:05,700
cut down on our rework. 
Now, I do that in a group once 

909
00:44:05,700 --> 00:44:09,200
we actually measured for several
years, how we spent time on 

910
00:44:09,200 --> 00:44:11,700
projects, how much time on 
requirements work in design and 

911
00:44:11,700 --> 00:44:14,100
coding, and testing and 
maintenance and so forth. 

912
00:44:14,400 --> 00:44:18,100
We didn't like our initial 
levels of bug fixing and so we 

913
00:44:18,100 --> 00:44:21,600
focused on techniques that could
help us do a better job of 

914
00:44:21,600 --> 00:44:25,500
producing initial high quality 
software within about six to 

915
00:44:25,500 --> 00:44:28,200
eight months. 
We reduced our defect correction

916
00:44:28,400 --> 00:44:31,200
Works from 13 and a half percent
of our initial work to do 

917
00:44:31,200 --> 00:44:34,500
percent which I was perfectly. 
Okay with, there's always some 

918
00:44:34,700 --> 00:44:38,800
but 32 is higher than I liked so
I think making that visible 

919
00:44:39,400 --> 00:44:42,300
making it explicit trying to 
measure it then at least let you

920
00:44:42,300 --> 00:44:44,500
know what's going on. 
So you can decide is there some 

921
00:44:44,500 --> 00:44:47,900
way that we can do, a better job
of initial quality to do less 

922
00:44:47,900 --> 00:44:50,700
rework. 
So these also comes back the 

923
00:44:50,700 --> 00:44:53,000
lean principle that you have 
value stream, mapping. 

924
00:44:53,000 --> 00:44:55,600
And maybe you will Analyze This,
Wait times and also reworked. 

925
00:44:55,600 --> 00:44:58,200
So that's actually one part of 
the value stream mapping. 

926
00:44:58,300 --> 00:45:00,000
Sighs and you are reducing 
waste. 

927
00:45:00,200 --> 00:45:03,400
We all agree that we should 
reduce more ways more rework. 

928
00:45:03,600 --> 00:45:05,800
But I think I just want to 
highlight one at the Pearl that 

929
00:45:05,800 --> 00:45:08,900
you have about this is that 
organizations never have time to

930
00:45:08,900 --> 00:45:11,400
build software. 
So we never build software, but 

931
00:45:11,400 --> 00:45:14,500
we always find the resources and
time to fix it later. 

932
00:45:14,700 --> 00:45:17,100
I think that's one thing for us 
to ponder about. 

933
00:45:17,400 --> 00:45:20,500
So let's move on to the process 
Improvement, you mention, if we 

934
00:45:20,500 --> 00:45:23,900
want to improve the best 
motivation for changing, how we 

935
00:45:23,900 --> 00:45:26,700
work is pain? 
I think some people learn from 

936
00:45:26,700 --> 00:45:28,700
the hard lessons, so they 
Asthma. 

937
00:45:28,700 --> 00:45:32,400
But this pain they do I think 
that's true life. 

938
00:45:32,400 --> 00:45:35,900
In general, the best motivation 
for changing anything we do is 

939
00:45:35,900 --> 00:45:37,800
pain which can come in many 
forms. 

940
00:45:38,100 --> 00:45:41,000
And here, I'm talking about the 
real pain that happens on 

941
00:45:41,000 --> 00:45:43,900
projects because of quality 
problems or process, 

942
00:45:43,900 --> 00:45:45,900
shortcomings or communication 
problems. 

943
00:45:45,900 --> 00:45:48,700
Those kinds of things. 
I'm not talking about artificial

944
00:45:48,700 --> 00:45:52,400
pain, that's externally induced 
by managers or customers who are

945
00:45:52,400 --> 00:45:56,200
demanding the impossible, that 
can be painful, but that's not 

946
00:45:56,200 --> 00:45:57,800
in itself. 
Terribly motivating. 

947
00:45:58,300 --> 00:46:01,400
Some examples of project pane 
that can be motivating are 

948
00:46:01,400 --> 00:46:04,400
failing to meet delivery 
schedules releasing products 

949
00:46:04,400 --> 00:46:07,300
that have more defects than you 
think are acceptable or missing 

950
00:46:07,300 --> 00:46:10,400
functionality, delivering 
products that don't satisfy the 

951
00:46:10,400 --> 00:46:13,600
customer needs. 
Or maybe you got burned by risks

952
00:46:13,600 --> 00:46:16,400
because nobody fought about the 
risks and figured out, how can 

953
00:46:16,400 --> 00:46:19,400
we mitigate that risk and then 
turned into a problem and you 

954
00:46:19,400 --> 00:46:22,700
paid some price for that. 
So from your experience, those 

955
00:46:22,700 --> 00:46:25,500
kinds of pain that should make 
you say, oh that wasn't very 

956
00:46:25,500 --> 00:46:28,000
much fun. 
What can we do differently? 

957
00:46:28,300 --> 00:46:31,600
Time to try to avoid that 
unpleasant situation. 

958
00:46:31,600 --> 00:46:34,800
And so that to me is the driver 
for process Improvement. 

959
00:46:35,200 --> 00:46:39,000
Give an example, I worked in the
Kodak.com group. 

960
00:46:39,000 --> 00:46:40,700
Kodak used to be a very large 
company. 

961
00:46:40,700 --> 00:46:44,400
Now, it's not such a big company
in the late 1990s. 

962
00:46:44,400 --> 00:46:47,800
I was in the Kodak.com group 
that ran all their websites and 

963
00:46:47,800 --> 00:46:49,800
they had a configuration 
management problem. 

964
00:46:49,800 --> 00:46:54,000
At that time, they had two web 
servers that were almost but not

965
00:46:54,000 --> 00:46:56,500
quite duplicates. 
They were having all these 

966
00:46:56,500 --> 00:46:58,100
configuration management 
confused. 

967
00:46:58,200 --> 00:47:00,700
Asians because it won't too sure
exactly what to trust. 

968
00:47:00,700 --> 00:47:02,400
What was most current at any 
time. 

969
00:47:02,600 --> 00:47:06,400
They also had a huge backlog of 
change requests because there 

970
00:47:06,400 --> 00:47:09,000
was a lot of people wanting 
websites at that point. 

971
00:47:09,200 --> 00:47:11,900
So I was there in a process 
Improvement leadership role and 

972
00:47:11,900 --> 00:47:15,600
I helped introduce a change 
request system and better 

973
00:47:15,600 --> 00:47:18,500
configuration management 
practices that reduce the pain 

974
00:47:18,500 --> 00:47:21,300
coming from that. 
And the thing I found is that in

975
00:47:21,300 --> 00:47:24,300
this group which are bunch of 
very smart people, working very 

976
00:47:24,300 --> 00:47:27,600
hard, very fast, sort of the 
Leading Edge, kind of stuff now 

977
00:47:27,900 --> 00:47:31,000
the Very receptive to both 
process changes. 

978
00:47:31,300 --> 00:47:33,300
A lot of times people and 
fast-moving groups are. 

979
00:47:33,300 --> 00:47:35,600
We're not interested in process,
we don't have time for process, 

980
00:47:36,000 --> 00:47:39,200
but they felt the pain and they 
saw the benefits they 

981
00:47:39,200 --> 00:47:40,800
understood. 
That the process is always 

982
00:47:40,800 --> 00:47:42,800
talking about. 
We're barriers to getting work 

983
00:47:42,800 --> 00:47:45,600
done, they were structures to 
help you get the work done 

984
00:47:45,600 --> 00:47:49,400
better and they saw that they 
were very receptive to it and it

985
00:47:49,400 --> 00:47:51,600
really made a difference in 
helping them manage. 

986
00:47:51,600 --> 00:47:53,400
All this work that they were 
trying to do. 

987
00:47:54,000 --> 00:47:57,100
So I think if you're trying to 
get people to change what 

988
00:47:57,100 --> 00:47:59,800
they're doing and they're all 
Busy working on their projects, 

989
00:47:59,900 --> 00:48:02,100
then you have to make this pain 
visible. 

990
00:48:02,300 --> 00:48:05,600
So that the promise of reducing 
the pain, outweighs the 

991
00:48:05,600 --> 00:48:09,500
discomfort of making the changes
because making changes isn't 

992
00:48:09,500 --> 00:48:11,200
that much fun? 
No matter what we're doing, 

993
00:48:11,300 --> 00:48:14,100
whether you're trying to lose 
weight or can prove your diet or

994
00:48:14,100 --> 00:48:15,700
create yourself for 
productivity. 

995
00:48:15,700 --> 00:48:18,200
It's never fun but you sort of 
have to do it. 

996
00:48:18,700 --> 00:48:21,400
One of the problems is and 
curious if you've run into this 

997
00:48:21,400 --> 00:48:23,800
that some of these kinds of 
project paint aren't always 

998
00:48:23,800 --> 00:48:26,400
visible to everyone who's 
affected by it. 

999
00:48:26,900 --> 00:48:29,900
So maybe a development team. 
Is taking certain approaches and

1000
00:48:29,900 --> 00:48:32,700
that causes problems for whoever
has to maintain the software 

1001
00:48:32,700 --> 00:48:35,000
later on. 
But that doesn't have a feedback

1002
00:48:35,000 --> 00:48:36,500
loop back to the development 
team. 

1003
00:48:36,500 --> 00:48:39,900
So they may not even know that 
what they're doing is causing 

1004
00:48:39,900 --> 00:48:41,600
problems. 
Have you ever seen a situation 

1005
00:48:41,600 --> 00:48:43,800
like that? 
Yeah, this is the syndrome. 

1006
00:48:43,800 --> 00:48:47,100
Like, we always done it this way
so sometimes you are into the 

1007
00:48:47,100 --> 00:48:50,000
things, you never see it like a 
fish in the water so to speak. 

1008
00:48:50,200 --> 00:48:52,300
So you never know that. 
I could you live in the water, 

1009
00:48:52,300 --> 00:48:54,800
you live with the pain, but 
yeah, you need to take a step 

1010
00:48:54,800 --> 00:48:56,500
out and find the big picture. 
Okay. 

1011
00:48:56,500 --> 00:48:58,100
These are the paintings that we 
have. 

1012
00:48:58,200 --> 00:49:01,400
Yeah, but sometimes when we are 
in the Gs of making things, work

1013
00:49:01,400 --> 00:49:04,800
and implementing stuff quick, we
don't always realize this pains.

1014
00:49:05,400 --> 00:49:08,400
I think if you're in a 
leadership role, trying to steal

1015
00:49:08,400 --> 00:49:11,300
an organization to better ways 
of working, you want to look for

1016
00:49:11,300 --> 00:49:13,600
the points of pain, because 
those are the things that people

1017
00:49:13,600 --> 00:49:16,600
can usually agree upon once. 
They are made aware of them. 

1018
00:49:16,600 --> 00:49:18,400
That, yeah, we can do better 
than that. 

1019
00:49:18,400 --> 00:49:21,100
That isn't that much, fun? 
Let's find some better ways to 

1020
00:49:21,100 --> 00:49:23,500
do our work. 
One of the other things, another

1021
00:49:23,500 --> 00:49:26,200
podcast episode that I have with
giardina London, she also 

1022
00:49:26,200 --> 00:49:27,800
mentioned about this making 
changes. 

1023
00:49:28,300 --> 00:49:31,100
You want to ask people to 
change, you better stop the 

1024
00:49:31,100 --> 00:49:33,000
pain. 
First from bleeding more, right?

1025
00:49:33,200 --> 00:49:35,500
Sometimes when we all introduced
this change management, you just

1026
00:49:35,500 --> 00:49:38,700
introduce more tactics more 
strategies but you actually not 

1027
00:49:38,700 --> 00:49:42,200
necessarily fixing the pain that
the team is currently having. 

1028
00:49:42,200 --> 00:49:45,700
So you're introducing more pain.
So to speak, there's always a 

1029
00:49:45,700 --> 00:49:47,500
learning curve. 
You go through whenever you're 

1030
00:49:47,500 --> 00:49:50,700
trying to do something new or 
different, there's a learning 

1031
00:49:50,700 --> 00:49:53,800
curve for you take an immediate 
productivity hit as soon as you 

1032
00:49:53,800 --> 00:49:58,600
the take a class or you adopts a
new methodology or Or you buy 

1033
00:49:58,600 --> 00:50:01,000
some new tool or whatever you're
doing this different 

1034
00:50:01,000 --> 00:50:03,700
immediately, you have a 
productivity penalty because you

1035
00:50:03,700 --> 00:50:05,400
have to figure out Lorraine. 
How does this work? 

1036
00:50:05,400 --> 00:50:08,500
How do I apply it in my world 
and it takes you some fumbling 

1037
00:50:08,500 --> 00:50:11,300
around but then eventually if 
you can push through that, 

1038
00:50:11,300 --> 00:50:14,000
you'll get to a point where 
you're being more productive and

1039
00:50:14,000 --> 00:50:18,200
hopefully less pain with the new
technique, but the change itself

1040
00:50:18,200 --> 00:50:20,900
can be unpleasant, people have 
to recognize that there's a 

1041
00:50:20,900 --> 00:50:23,400
short-term performance penalty, 
in our work. 

1042
00:50:23,400 --> 00:50:25,100
While we're going through that 
transition. 

1043
00:50:25,900 --> 00:50:28,300
This is a good segue to 
summarize, all the pearls, 

1044
00:50:28,300 --> 00:50:30,000
right? 
The ultimate Purl, the Purl, 

1045
00:50:30,000 --> 00:50:32,500
number 60, so there are 60 of 
them. 

1046
00:50:32,700 --> 00:50:35,200
The last one you mentioned that 
you can't change everything at 

1047
00:50:35,200 --> 00:50:37,700
once. 
I think people know about this, 

1048
00:50:37,700 --> 00:50:39,400
but sometimes they live in 
fantasy. 

1049
00:50:39,600 --> 00:50:41,100
They want to change everything 
all at once. 

1050
00:50:41,600 --> 00:50:44,800
So tell us more about this. 
It's interesting because 

1051
00:50:44,800 --> 00:50:47,400
sometimes you do have groups and
I've worked with some like this,

1052
00:50:47,400 --> 00:50:50,700
that were very enthusiastic 
about process Improvement. 

1053
00:50:50,900 --> 00:50:54,200
The really saw the benefits of 
making improvements in whatever 

1054
00:50:54,200 --> 00:50:56,000
areas working as well. 
For them. 

1055
00:50:56,200 --> 00:50:59,000
And I remember a group once 
with, about 20 people in the 

1056
00:50:59,000 --> 00:51:02,400
team who's like, that, they 
decided to work on seven 

1057
00:51:02,400 --> 00:51:06,800
different change initiatives at 
once, but the problem was they 

1058
00:51:06,800 --> 00:51:10,300
were spread too thin and they 
didn't really make much progress

1059
00:51:10,300 --> 00:51:12,100
on any one of them. 
It wasn't clear, which were the 

1060
00:51:12,100 --> 00:51:14,300
top priorities. 
Let's do this first, let's do 

1061
00:51:14,300 --> 00:51:16,100
that next. 
And so they just try to do them 

1062
00:51:16,100 --> 00:51:18,500
all at once. 
Kind of a broad front strategy 

1063
00:51:18,800 --> 00:51:20,500
as a result. 
They didn't make much progress 

1064
00:51:20,500 --> 00:51:23,000
which is frustrating. 
You I think you only get two 

1065
00:51:23,000 --> 00:51:27,800
tries in an organization to make
Kind of changes that fail and 

1066
00:51:27,800 --> 00:51:29,400
then people aren't interested 
anymore. 

1067
00:51:29,400 --> 00:51:31,000
It's like I guess we can't do 
this. 

1068
00:51:31,400 --> 00:51:35,000
So I think what's important is 
to focus your change efforts on 

1069
00:51:35,000 --> 00:51:37,900
the places where you're going to
get the maximum benefit for the 

1070
00:51:37,900 --> 00:51:41,500
investment of effort to make the
changes and there's an operative

1071
00:51:41,500 --> 00:51:43,200
term. 
That I learned a long time ago 

1072
00:51:43,200 --> 00:51:45,700
that I love about process 
Improvement, which is gentle. 

1073
00:51:45,700 --> 00:51:49,800
Pressure relentlessly applied. 
In other words, you should all 

1074
00:51:49,800 --> 00:51:53,400
as individuals, as teens as 
organizations, you should always

1075
00:51:53,400 --> 00:51:55,400
be spending part of your time 
learning. 

1076
00:51:55,500 --> 00:51:58,600
Knowing how to do things better.
I've never known anyone who 

1077
00:51:58,600 --> 00:52:01,600
could honestly say, I am 
building software today as well 

1078
00:52:01,600 --> 00:52:04,600
as software could ever be built.
I certainly can't say that. 

1079
00:52:04,600 --> 00:52:07,300
I don't know anyone who could, 
and if you can't, then you 

1080
00:52:07,300 --> 00:52:09,400
should say. 
All right, let me try to find 

1081
00:52:09,400 --> 00:52:11,300
better ways. 
Let me always spend some of my 

1082
00:52:11,300 --> 00:52:14,900
time trying to improve the way I
do my work in one way or 

1083
00:52:14,900 --> 00:52:17,200
another. 
So related to that is the idea 

1084
00:52:17,200 --> 00:52:21,100
of doing team retrospectives. 
This is a Hot Topic in the agile

1085
00:52:21,100 --> 00:52:23,900
World which I think is great 
because retrospectives are such 

1086
00:52:23,900 --> 00:52:27,700
an important learning. 
D for groups to say, alright, 

1087
00:52:27,900 --> 00:52:30,500
let's reflect on what happened? 
How did it go or what parts 

1088
00:52:30,500 --> 00:52:32,000
went? 
Well, let's do that again. 

1089
00:52:32,300 --> 00:52:34,700
But Parts didn't go so. 
Well, unless that we about 

1090
00:52:34,700 --> 00:52:36,200
blaming people, that's not the 
point. 

1091
00:52:36,200 --> 00:52:38,600
But let's just learn. 
Let's try to see if we could do 

1092
00:52:38,600 --> 00:52:40,700
those better. 
The next time, what happened 

1093
00:52:40,700 --> 00:52:42,600
that? 
We still don't understand. 

1094
00:52:42,800 --> 00:52:44,800
There's some learning 
opportunities there. 

1095
00:52:45,100 --> 00:52:46,400
What happened? 
That surprised us. 

1096
00:52:46,400 --> 00:52:48,900
Maybe some risks came up. 
We haven't thought about before,

1097
00:52:48,900 --> 00:52:50,500
so you add those to your risk 
list. 

1098
00:52:50,500 --> 00:52:53,100
So on the next project, you ask 
yourself, could that happen 

1099
00:52:53,100 --> 00:52:55,700
again? 
So a retrospective is an Silent 

1100
00:52:55,700 --> 00:52:58,400
learning opportunity. 
That helps, you kind of gently 

1101
00:52:58,500 --> 00:53:01,900
try to keep changing things just
a little bit at a time. 

1102
00:53:02,700 --> 00:53:05,600
Thanks for emphasizing this. 
I think focus is really key, no 

1103
00:53:05,600 --> 00:53:08,500
matter whether in project. 
So in your individual life 

1104
00:53:08,700 --> 00:53:11,300
Focus, this definitely one thing
that I think, modern people, 

1105
00:53:11,300 --> 00:53:12,700
right? 
We have this problem of 

1106
00:53:12,700 --> 00:53:15,300
focusing, that's just too many 
things to consume, the many 

1107
00:53:15,300 --> 00:53:17,700
things to learn, too many things
to watch and whatever that 

1108
00:53:17,700 --> 00:53:20,000
things. 
So, thanks for sharing this one 

1109
00:53:20,000 --> 00:53:23,200
of the problems with the focus. 
We also busy, we're working on 

1110
00:53:23,200 --> 00:53:24,800
so many things. 
There's so much pressure, 

1111
00:53:24,800 --> 00:53:27,300
everybody. 
Things yesterday is that if you 

1112
00:53:27,300 --> 00:53:30,900
don't take the time to learn and
improve, you have absolutely no 

1113
00:53:30,900 --> 00:53:33,200
reason to expect the next 
project to go better than the 

1114
00:53:33,200 --> 00:53:36,700
current project you can hope but
you have no reason to believe 

1115
00:53:36,700 --> 00:53:40,000
that's going to happen. 
So it's a magic if you expect 

1116
00:53:40,000 --> 00:53:42,700
that to happen by itself. 
So thanks call. 

1117
00:53:42,700 --> 00:53:44,700
It's been a pleasure talking 
about all these bills. 

1118
00:53:44,700 --> 00:53:48,500
So for people who want to learn 
more about the other Pros as 60 

1119
00:53:48,500 --> 00:53:52,200
of them, like I said, there are 
Lessons Learned by Carl in his 

1120
00:53:52,200 --> 00:53:54,400
50 years of software development
experience. 

1121
00:53:54,700 --> 00:53:57,300
So really were Earth to check. 
Because I mean, where else can 

1122
00:53:57,300 --> 00:53:59,300
you find this 50 years of 
experience? 

1123
00:53:59,300 --> 00:54:02,200
Dance into one book then you 
don't have to repeat the same 

1124
00:54:02,200 --> 00:54:04,300
mistakes? 
I think that's the benefit of 

1125
00:54:04,300 --> 00:54:07,200
reading this book so that you 
don't actually redo the mistakes

1126
00:54:07,200 --> 00:54:09,400
that may be called it in his 
previous work. 

1127
00:54:09,700 --> 00:54:12,100
So called due to time. 
Unfortunately, we have to wrap 

1128
00:54:12,100 --> 00:54:14,600
up pretty soon but normally 
Before I Let You Go. 

1129
00:54:14,600 --> 00:54:17,700
I have one last question that I 
always ask to all my guests 

1130
00:54:17,800 --> 00:54:20,000
which is to share this thing 
called three technical 

1131
00:54:20,000 --> 00:54:22,700
leadership wisdom. 
So think of it like an advice 

1132
00:54:22,700 --> 00:54:25,000
that you want to give to 
listeners out there so that they

1133
00:54:25,000 --> 00:54:28,200
can Reflect and maybe do it 
better for their own sake. 

1134
00:54:28,900 --> 00:54:32,100
Okay, well you could have led 
right into that, with your final

1135
00:54:32,100 --> 00:54:35,500
comments there about ballooning 
from what we've done before. 

1136
00:54:35,900 --> 00:54:38,000
And the way I think about it is 
that you don't have time to 

1137
00:54:38,000 --> 00:54:41,200
ReDiscover everything that all 
the software people before you 

1138
00:54:41,200 --> 00:54:44,100
have already learned. 
So I think it's important for 

1139
00:54:44,100 --> 00:54:47,700
people to read the literature, 
respect the lessons of the past.

1140
00:54:47,800 --> 00:54:51,100
I dapped established effective 
practices to your new reality 

1141
00:54:51,100 --> 00:54:53,900
instead of ruining the same 
lessons painfully. 

1142
00:54:54,200 --> 00:54:56,800
Sometimes there's a tendency I 
think especially among younger 

1143
00:54:56,800 --> 00:55:00,200
people to throw out anything old
especially in software and such 

1144
00:55:00,200 --> 00:55:02,300
a young field and itself and 
moving along. 

1145
00:55:02,500 --> 00:55:04,600
People don't say, oh, that was a
chemistry. 

1146
00:55:04,600 --> 00:55:06,700
I don't remember it. 
That doesn't apply anymore. 

1147
00:55:07,000 --> 00:55:09,200
Yeah, it does. 
There's a lot of stuff that 

1148
00:55:09,200 --> 00:55:12,600
still applies that we've known 
for a long time and software and

1149
00:55:12,600 --> 00:55:14,900
maybe you need to adapt it in 
some way. 

1150
00:55:14,900 --> 00:55:18,300
But the ideas still apply. 
And so respect the body of 

1151
00:55:18,300 --> 00:55:21,900
knowledge that we have another 
piece of wisdom gets back to 

1152
00:55:21,900 --> 00:55:23,400
the. 
You can't change everything at 

1153
00:55:23,400 --> 00:55:26,300
once idea. 
But you can Something all the 

1154
00:55:26,300 --> 00:55:28,900
time. 
One way I suggest people do this

1155
00:55:28,900 --> 00:55:32,800
as on every project you work on 
pick out two areas you want to 

1156
00:55:32,808 --> 00:55:36,400
get better at they could be 
specific technical practices or 

1157
00:55:36,400 --> 00:55:39,500
softer skills or anything else 
that you think would add value 

1158
00:55:39,500 --> 00:55:41,400
to your project work in your 
career. 

1159
00:55:41,700 --> 00:55:44,900
Some of the things I chose 
various times in my career were 

1160
00:55:44,900 --> 00:55:48,700
things like build management or 
unit testing analysis and design

1161
00:55:48,700 --> 00:55:51,800
modeling, writing requirements. 
Things that I said I need to 

1162
00:55:51,800 --> 00:55:54,300
learn more about that. 
So then spend a little bit of 

1163
00:55:54,300 --> 00:55:57,500
your time on your project 
warning about those areas and 

1164
00:55:57,500 --> 00:56:00,600
trying to actively apply them to
get some experience with them on

1165
00:56:00,600 --> 00:56:03,900
your current project and the 
third bit of wisdom that I think

1166
00:56:03,900 --> 00:56:07,700
I like to pass along its before 
you decide to adopt any 

1167
00:56:07,700 --> 00:56:09,900
particular solution. 
But you think is going to give 

1168
00:56:09,900 --> 00:56:13,100
you a great new results because 
you read an ad somewhere or 

1169
00:56:13,200 --> 00:56:15,900
that's what the person that the 
conference said, make sure you 

1170
00:56:15,908 --> 00:56:19,200
understand the real problem. 
I'm a big fan of root cause 

1171
00:56:19,200 --> 00:56:21,500
analysis. 
So let's say you're tempted to 

1172
00:56:21,500 --> 00:56:24,900
adopt some new methodology, I'll
call it method 9, it's supposed 

1173
00:56:24,900 --> 00:56:28,400
to give you Like productivity or
higher customer satisfaction or 

1174
00:56:28,900 --> 00:56:32,700
some other fabulous goodness 
before you switch to Method. 9, 

1175
00:56:32,700 --> 00:56:35,500
first, ask yourself why are we 
not already having great 

1176
00:56:35,500 --> 00:56:37,900
productivity? 
Why do we not already have 

1177
00:56:37,900 --> 00:56:40,100
higher customer satisfaction 
than we do? 

1178
00:56:40,400 --> 00:56:43,000
So once you've done some root 
cause analysis then you can 

1179
00:56:43,000 --> 00:56:45,900
decide whether the solution 
you're considering is actually 

1180
00:56:45,900 --> 00:56:47,900
going to address the right 
problems. 

1181
00:56:48,200 --> 00:56:50,300
In other words, if method 9 is 
the answer, what was the 

1182
00:56:50,300 --> 00:56:53,200
question? 
So, I think it's important to do

1183
00:56:53,200 --> 00:56:56,400
some root cause thinking before 
you choose Is any new way to 

1184
00:56:56,400 --> 00:56:58,700
work, then you can make sure 
you're choosing the right one. 

1185
00:56:59,400 --> 00:57:00,900
Well, I really liked the last 
one. 

1186
00:57:00,900 --> 00:57:03,700
It's really wise to have that so
because he has in software 

1187
00:57:03,700 --> 00:57:06,200
development, especially, we tend
to follow this hype driven 

1188
00:57:06,200 --> 00:57:09,500
development, always chase the 
latest hype latest technology, 

1189
00:57:09,500 --> 00:57:12,800
be the next Google or whatever 
that is, and then try to apply 

1190
00:57:12,800 --> 00:57:14,600
that in our working environment.
Okay. 

1191
00:57:14,600 --> 00:57:17,100
Sometimes it's not the same 
problem, but because of that, it

1192
00:57:17,100 --> 00:57:20,200
introduced more problems for the
team and the company itself. 

1193
00:57:20,600 --> 00:57:23,800
So, thanks God for your time. 
For people who want to learn 

1194
00:57:23,800 --> 00:57:27,000
more about your work, maybe 
Other books, where can they find

1195
00:57:27,000 --> 00:57:29,300
you online or where they can 
reach out if they want to 

1196
00:57:29,300 --> 00:57:33,100
continue this conversation with 
a personal website is Carl 

1197
00:57:33,100 --> 00:57:38,200
weekers.com, my company website 
is process impact.com and 

1198
00:57:38,200 --> 00:57:40,900
there's information at both of 
those about all of my books on 

1199
00:57:40,908 --> 00:57:43,400
various topics. 
There's a lot of Articles I've 

1200
00:57:43,400 --> 00:57:47,000
posted a lot of particles both 
on the process impact.com site 

1201
00:57:47,000 --> 00:57:52,000
and on medium.com, I have 85 or 
so articles up there on a wide 

1202
00:57:52,000 --> 00:57:54,000
range of topics. 
So those are all places where 

1203
00:57:54,000 --> 00:57:55,200
people can learn a little bit 
more. 

1204
00:57:55,400 --> 00:57:58,700
Or another thing you can do it, 
call uyghurs.com that may not be

1205
00:57:58,700 --> 00:58:01,400
obvious. 
My main hobby is recording 

1206
00:58:01,400 --> 00:58:03,200
music. 
Just for fun at home. 

1207
00:58:03,500 --> 00:58:05,600
I play guitar. 
I'm not a good singer. 

1208
00:58:05,600 --> 00:58:08,100
I'm not a great guitarist, but I
don't let that stop me. 

1209
00:58:08,400 --> 00:58:11,100
So, I like to record music and I
have about 50. 

1210
00:58:11,400 --> 00:58:15,700
I think 51 Songs now had Carl 
uyghurs.com that I've recorded 

1211
00:58:15,800 --> 00:58:18,100
just me doing all the parts. 
Maybe a little help from some 

1212
00:58:18,100 --> 00:58:20,900
friends once in a while. 18 of 
them are songs that I wrote 

1213
00:58:20,900 --> 00:58:23,400
myself, in recorded in the 
restaurant, all covers of other 

1214
00:58:23,400 --> 00:58:24,800
songs. 
It's just a fun hobby. 

1215
00:58:25,400 --> 00:58:27,500
People who want to listen to new
music. 

1216
00:58:27,500 --> 00:58:30,900
Instead of Spotify, go to Cal 
Wiggins.com and make sure to 

1217
00:58:30,900 --> 00:58:33,400
check out these original songs 
that Carl has produced. 

1218
00:58:33,600 --> 00:58:36,500
So thanks a lot for your time. 
I'm really learning a lot from 

1219
00:58:36,500 --> 00:58:39,100
your pearls. 
I'm sure people would also learn

1220
00:58:39,100 --> 00:58:40,900
something if they read from the 
books. 

1221
00:58:41,200 --> 00:58:43,800
So thanks again for your time. 
Thanks very much Henry's. 

1222
00:58:43,800 --> 00:58:45,300
Been a pleasure being with you 
today. 

1223
00:58:48,300 --> 00:58:51,500
Thank you for listening to this 
episode and for staying, right 

1224
00:58:51,500 --> 00:58:55,000
until the end, if you're highly 
enjoyed it, I would appreciate 

1225
00:58:55,000 --> 00:58:57,600
if you share it with your 
friends and colleagues who you 

1226
00:58:57,600 --> 00:59:00,300
think would also benefit from 
listening to this episode. 

1227
00:59:00,600 --> 00:59:03,400
And if you are new to the 
podcast, make sure to subscribe 

1228
00:59:03,400 --> 00:59:05,900
and leave me your valuable 
review and feedback. 

1229
00:59:06,100 --> 00:59:09,100
It helps me a lot in order to 
grow this podcast better. 

1230
00:59:09,500 --> 00:59:12,400
You can also find the full show 
notes of this conversation on 

1231
00:59:12,400 --> 00:59:15,600
the episode page at tackling 
journal, the death website, 

1232
00:59:15,700 --> 00:59:17,900
including the full transcript 
interesting. 

1233
00:59:18,100 --> 00:59:21,000
Courts and links to the 
resources mention from the 

1234
00:59:21,000 --> 00:59:23,800
conversation. 
And lastly, make sure to 

1235
00:59:23,800 --> 00:59:26,100
subscribe to the show's mailing 
list on package. 

1236
00:59:26,100 --> 00:59:29,000
You know, that deaf to get 
notified for any future 

1237
00:59:29,000 --> 00:59:31,200
episodes. 
Stay tuned for the next 

1238
00:59:31,200 --> 00:59:34,600
technology, no episode. 
And until then goodbye.