1
00:00:00,100 --> 00:00:03,500
Requirements are not really 
about technical things. 

2
00:00:03,500 --> 00:00:06,600
Requirements are a communication
problem, not a technical 

3
00:00:06,600 --> 00:00:09,300
problem. 
And that's I think why it's 

4
00:00:09,300 --> 00:00:11,600
hard. 
And so this process of 

5
00:00:11,607 --> 00:00:13,700
requirements development where 
our goal is. 

6
00:00:13,700 --> 00:00:17,700
Exactly, as you said clear and 
effective communication, it's 

7
00:00:17,700 --> 00:00:20,900
not following a set of rules, 
it's not conforming to some 

8
00:00:20,900 --> 00:00:24,600
standard. 
It's effective communication and

9
00:00:24,600 --> 00:00:28,400
that has to necessarily be done 
in an incremental and iterative 

10
00:00:28,400 --> 00:00:34,900
fashion. 
Hey everyone. 

11
00:00:35,400 --> 00:00:37,200
My name is Henry Surya, we 
Robin. 

12
00:00:38,900 --> 00:00:41,800
And you're listening to the 
technology, you know, podcast 

13
00:00:42,200 --> 00:00:44,500
the show where I'll be bringing 
you the greatest technical 

14
00:00:44,500 --> 00:00:48,400
leaders practitioners and 
thought leaders in the industry 

15
00:00:48,800 --> 00:00:53,100
to discuss about their Journey 
ideas and practices that we all 

16
00:00:53,100 --> 00:00:56,700
can learn and apply to build a 
highly performing technical team

17
00:00:57,100 --> 00:00:59,500
and to make an impact in your 
personal work. 

18
00:01:00,000 --> 00:01:08,200
So let's dive into our Journal. 
Hello again to all of you, my 

19
00:01:08,200 --> 00:01:10,800
friends and my listeners, 
welcome to the technology, you 

20
00:01:10,800 --> 00:01:13,900
know, podcast the podcast where 
you can learn about technical 

21
00:01:13,900 --> 00:01:17,000
leadership and Excellence from 
my conversation, with great 

22
00:01:17,000 --> 00:01:18,800
thought leaders in the tech 
industry. 

23
00:01:19,200 --> 00:01:22,000
If you haven't, please subscribe
and follow the show on your 

24
00:01:22,000 --> 00:01:24,500
podcast app and social media on 
LinkedIn. 

25
00:01:24,500 --> 00:01:27,700
Twitter and Instagram. 
And to appreciate and support my

26
00:01:27,700 --> 00:01:29,800
work. 
Subscribe as a patron at 

27
00:01:29,800 --> 00:01:33,700
technology, not Dev slash Patron
or buy me a coffee at 

28
00:01:33,700 --> 00:01:38,000
technology, not Dev slash. 
Tip my guest for today's episode

29
00:01:38,000 --> 00:01:41,200
is called uyghurs. 
Carl is the co-author of 

30
00:01:41,200 --> 00:01:44,000
software requirements, 
Essentials and has previously 

31
00:01:44,000 --> 00:01:49,500
appeared in our episode. 103, in
this episode, we discussed six 

32
00:01:49,500 --> 00:01:51,800
essential practices for software
requirements. 

33
00:01:51,900 --> 00:01:55,800
Out of the 20 core practices 
specified in his book, such as 

34
00:01:55,800 --> 00:01:58,600
understanding the problem 
before, converging on a solution

35
00:01:59,100 --> 00:02:02,100
understanding what users need to
do with the solution 

36
00:02:02,400 --> 00:02:04,900
prioritizing requirements and a 
few more. 

37
00:02:05,600 --> 00:02:08,600
Call also explained the 
importance of having a clear and

38
00:02:08,600 --> 00:02:11,100
effective communication in 
developing software 

39
00:02:11,100 --> 00:02:13,800
requirements. 
His view on doing software 

40
00:02:13,800 --> 00:02:17,300
requirements for agile teams and
the importance of having good 

41
00:02:17,300 --> 00:02:20,100
software requirements for 
becoming an effective software 

42
00:02:20,100 --> 00:02:23,800
development team and for 
avoiding unnecessary rework. 

43
00:02:24,700 --> 00:02:27,500
It's really great to have car 
back on the show for the second 

44
00:02:27,500 --> 00:02:29,600
time. 
And I always enjoy and learn a 

45
00:02:29,608 --> 00:02:33,300
lot from my conversation with 
him and I hope you also enjoyed 

46
00:02:33,300 --> 00:02:35,300
this episode as much as I am 
producing. 

47
00:02:35,300 --> 00:02:38,400
Loosing it, please share this 
episode with your colleagues, 

48
00:02:38,400 --> 00:02:41,500
friends and communities, and 
also leave a five star rating 

49
00:02:41,500 --> 00:02:44,300
and review on a podcast and 
Spotify. 

50
00:02:44,300 --> 00:02:47,800
And I hope more people can 
benefit from listening to this 

51
00:02:47,800 --> 00:02:50,800
episode. 
Before we go to my conversation 

52
00:02:50,800 --> 00:02:53,100
with call. 
Let's hear a few words from our 

53
00:02:53,100 --> 00:02:56,000
sponsors. 
Are you looking for a new cool 

54
00:02:56,000 --> 00:02:57,700
swag? 
Taglit Journal. 

55
00:02:57,700 --> 00:03:00,600
Now offers you some swags that 
you can purchase online? 

56
00:03:00,600 --> 00:03:05,100
These wax are printed on demand 
based on your preference and 

57
00:03:05,400 --> 00:03:08,700
Delivered safely to you all over
the world where shipping is 

58
00:03:08,700 --> 00:03:11,000
available. 
Check out all the cool tracks 

59
00:03:11,000 --> 00:03:13,600
available by visiting 
technology, you know, the death,

60
00:03:13,600 --> 00:03:16,300
/ shop and don't forget to break
yourself. 

61
00:03:16,400 --> 00:03:18,500
Once you receive any of those 
tracks. 

62
00:03:21,200 --> 00:03:23,700
Hey guys, welcome back to 
technology to our podcast. 

63
00:03:23,700 --> 00:03:27,300
Today we have a repeat guests. 
Someone that I really love the 

64
00:03:27,300 --> 00:03:31,100
conversation last time in 
episode 103, he's called 

65
00:03:31,100 --> 00:03:33,000
uyghurs. 
So if you still remember we 

66
00:03:33,000 --> 00:03:34,900
talked about software pulse last
time. 

67
00:03:34,900 --> 00:03:38,400
He He published a book and this 
time he came back with another 

68
00:03:38,400 --> 00:03:41,100
book if you see. 
Remember he has written 13 books

69
00:03:41,100 --> 00:03:43,600
back then, right? 
So he decided to be productive 

70
00:03:43,600 --> 00:03:45,700
and write one more to become 14 
books. 

71
00:03:45,700 --> 00:03:48,700
Now, and his new book is titled 
software requirements, 

72
00:03:48,700 --> 00:03:52,000
Essentials core practices for 
successful business analysis, 

73
00:03:52,500 --> 00:03:54,500
Carl. 
I'm really excited to have this 

74
00:03:54,500 --> 00:03:57,300
chance to talk to you again. 
And hopefully, we can talk a lot

75
00:03:57,300 --> 00:03:58,900
of things about software 
requirements today. 

76
00:03:58,900 --> 00:04:01,400
Welcome to the show. 
Well, thank you Henry. 

77
00:04:01,400 --> 00:04:03,400
I appreciate the chance to be 
back with you. 

78
00:04:03,400 --> 00:04:06,700
Like you said, I enjoyed our 
Before and I'm sure we'll have a

79
00:04:06,700 --> 00:04:10,700
good time today as well. 
So it's been quite a while since

80
00:04:10,700 --> 00:04:13,500
our last speak, right? 
Is there anything that you do 

81
00:04:13,500 --> 00:04:16,100
recently that you want to talk 
about besides the book? 

82
00:04:16,800 --> 00:04:21,100
Well, when I'm not writing books
or articles, I do like to record

83
00:04:21,100 --> 00:04:25,100
songs as sort of my main hobby. 
My wife told me probably about 

84
00:04:25,100 --> 00:04:27,600
17 years ago. 
Now, she said, Carl, you need a 

85
00:04:27,608 --> 00:04:29,800
new hobby? 
Well, I've played guitar for 

86
00:04:29,800 --> 00:04:34,000
many many years since I was 12, 
and I'm a lot more than 12 now. 

87
00:04:34,400 --> 00:04:37,400
But I just Started recording 
songs, just for fun. 

88
00:04:37,400 --> 00:04:41,200
So, I got some software in a 
computer and I enjoy trying to 

89
00:04:41,200 --> 00:04:45,300
reproduce covers of original 
songs that other people recorded

90
00:04:45,300 --> 00:04:47,800
trying to mimic what they did as
well as I could. 

91
00:04:48,000 --> 00:04:50,600
Plus I like to write my own 
music and record that too. 

92
00:04:50,600 --> 00:04:53,200
So, it's kind of fun to do all 
the guitar parts and the bass, 

93
00:04:53,200 --> 00:04:56,400
and the vocals, and keyboards 
and stuff, and program, the 

94
00:04:56,400 --> 00:04:58,300
drums. 
So, I've done a number of songs.

95
00:04:58,300 --> 00:05:01,400
Since last we spoke, and they're
all at my website, Carl 

96
00:05:01,400 --> 00:05:04,600
uyghurs.com there, just for fun.
I'm certainly no professional, 

97
00:05:04,600 --> 00:05:06,700
but it's a nice. 
Creative outlet and always a 

98
00:05:06,700 --> 00:05:10,200
good learning opportunity. 
Yes, they remember, I could find

99
00:05:10,200 --> 00:05:12,000
a number of songs on your 
website. 

100
00:05:12,000 --> 00:05:15,600
I think you also listed, I think
about 50 songs there, right? 

101
00:05:15,600 --> 00:05:18,800
So I think not just writing 
books, you also write songs, so 

102
00:05:18,800 --> 00:05:21,500
that's really great. 
So car let's go to your book, 

103
00:05:21,500 --> 00:05:22,900
right? 
So you wrote this software 

104
00:05:22,900 --> 00:05:26,200
requirements Essentials. 
If I'm not wrong, you actually 

105
00:05:26,400 --> 00:05:29,100
wrote the thicker version of, 
it's called software 

106
00:05:29,100 --> 00:05:31,100
requirements. 
Which has gone through multiple 

107
00:05:31,100 --> 00:05:33,300
editions as well. 
Maybe if you can give us a 

108
00:05:33,308 --> 00:05:35,200
background why you decided to 
write? 

109
00:05:35,500 --> 00:05:37,900
Thinner version of that book 
instead. 

110
00:05:38,500 --> 00:05:41,300
Yeah, I was kind of funny. 
I hadn't planned to write this 

111
00:05:41,300 --> 00:05:45,300
book, but nearly a year ago, I 
wrote a short article titled, 

112
00:05:45,300 --> 00:05:48,200
the six most important 
requirements practices. 

113
00:05:48,200 --> 00:05:50,600
Sometimes I just feel like 
writing something or get an 

114
00:05:50,600 --> 00:05:52,500
idea. 
And so I wrote this little 

115
00:05:52,500 --> 00:05:55,200
article, it was only maybe 
twelve or thirteen hundred words

116
00:05:55,200 --> 00:05:58,500
and I posted that article on my 
medium.com account. 

117
00:05:58,500 --> 00:06:02,600
I have nearly 100 articles up 
there on many topics and I was 

118
00:06:02,600 --> 00:06:05,200
just completely shocked the 
response to that short. 

119
00:06:05,300 --> 00:06:09,300
Go was just astonishing, it's 
been read more than 18,000 

120
00:06:09,300 --> 00:06:11,900
times. 
The posts that I created on 

121
00:06:11,900 --> 00:06:16,000
LinkedIn to announce the article
have been viewed about 100,000 

122
00:06:16,000 --> 00:06:19,800
times with you know, about a 
thousand likes and many reposts 

123
00:06:19,800 --> 00:06:22,500
and I was just completely 
astonished at the positive 

124
00:06:22,500 --> 00:06:25,100
reaction to just that little 
article on the six most 

125
00:06:25,100 --> 00:06:26,800
important requirements 
practices. 

126
00:06:27,200 --> 00:06:30,500
But that made me start thinking 
maybe there's a market for a 

127
00:06:30,500 --> 00:06:34,500
short book on requirements that 
just hits the highlights because

128
00:06:34,500 --> 00:06:37,600
like you said, I wrote this book
called software requirements. 

129
00:06:37,600 --> 00:06:40,100
In three additions. 
The Third Edition came out 10 

130
00:06:40,100 --> 00:06:42,000
years ago and that was a big 
book. 

131
00:06:42,000 --> 00:06:46,200
And there are a lot of long 
comprehensive books on software 

132
00:06:46,200 --> 00:06:49,200
requirements, and business 
analysis, and those books 

133
00:06:49,200 --> 00:06:52,700
describe dozens and dozens of 
practices, all these things, a 

134
00:06:52,707 --> 00:06:56,900
business analyst, or a product 
owner or product manager, ought 

135
00:06:56,900 --> 00:06:59,200
to do. 
And those are all useful in 

136
00:06:59,200 --> 00:07:02,400
various situations. 
But busy people don't always 

137
00:07:02,400 --> 00:07:04,600
have time to read these long 
books. 

138
00:07:05,300 --> 00:07:08,800
I had this idea of kind of a 
paradigm shift writing a short 

139
00:07:08,800 --> 00:07:11,100
book that just skims across the 
top. 

140
00:07:11,100 --> 00:07:14,400
It describes the 20 most 
important requirements, 

141
00:07:14,400 --> 00:07:17,800
practices that I think apply to 
virtually all projects and 

142
00:07:17,800 --> 00:07:20,600
teams. 
So that was my idea and you know

143
00:07:20,600 --> 00:07:23,700
it was nice because the book 
just came out a few weeks ago 

144
00:07:23,700 --> 00:07:27,000
and when I held to my copy of 
the book in my hands and look 

145
00:07:27,000 --> 00:07:29,400
through it, I realized that was 
exactly the book that I was 

146
00:07:29,400 --> 00:07:32,400
envisioning last summer when I 
first got this idea. 

147
00:07:32,400 --> 00:07:34,900
So it's nice when it works out 
that way and you say yep. 

148
00:07:34,900 --> 00:07:37,600
That's What I was trying to do. 
So I'm very pleased with how 

149
00:07:37,600 --> 00:07:40,500
that came out and I chose to 
work with a co-author. 

150
00:07:40,500 --> 00:07:43,000
I did that on the second edition
or the third edition of the 

151
00:07:43,000 --> 00:07:46,500
software requirements book. 
But I Enlisted the assistance of

152
00:07:46,500 --> 00:07:50,300
a co-author Candace Hawkinson 
and partly because she had a lot

153
00:07:50,300 --> 00:07:53,400
of experience of product 
ownership and business analysis 

154
00:07:53,400 --> 00:07:57,700
on agile projects, which I don't
have and Candace brought a lot 

155
00:07:57,700 --> 00:07:59,800
to the table. 
She brought like any other 

156
00:07:59,800 --> 00:08:04,200
co-author different experiences 
new true life stories to share 

157
00:08:04,200 --> 00:08:05,700
beyond my own. 
Inches. 

158
00:08:05,700 --> 00:08:08,900
And what I've learned from. 
Other Consulting, clients she 

159
00:08:08,900 --> 00:08:12,700
has a lot of Hands-On, current 
project experience that I don't 

160
00:08:12,700 --> 00:08:15,900
have personally these days. 
So she was helpful in making 

161
00:08:15,900 --> 00:08:19,600
sure that the practices we 
selected is being in the top 20 

162
00:08:19,900 --> 00:08:23,800
apply to virtually all software 
projects regardless of the kind 

163
00:08:23,800 --> 00:08:26,500
of product you're building and 
whether you're following an 

164
00:08:26,500 --> 00:08:30,600
agile or traditional development
approach so that was what we set

165
00:08:30,600 --> 00:08:32,900
out to do and I think we did it 
right? 

166
00:08:32,900 --> 00:08:35,100
This maybe to give some 
illustration for people. 

167
00:08:35,200 --> 00:08:38,400
Who are not familiar with your 
software requirements book if 

168
00:08:38,400 --> 00:08:42,000
you compare the pages, do you 
know how many pages difference 

169
00:08:42,000 --> 00:08:44,600
is it? 
Yeah, it's a pretty big 

170
00:08:44,600 --> 00:08:46,100
difference. 
The Third Edition of the 

171
00:08:46,100 --> 00:08:48,600
software requirements book, 
which I also co-authored with 

172
00:08:48,600 --> 00:08:51,100
joy Beatty is a seriously big 
book. 

173
00:08:51,100 --> 00:08:55,200
It's more than 600 pages of 
content, but it's sort of had to

174
00:08:55,200 --> 00:08:58,500
be because it comprehensively 
covers the entire domain of 

175
00:08:58,500 --> 00:09:00,700
requirements, development and 
management. 

176
00:09:00,800 --> 00:09:03,100
And the fact is there's a lot of
information. 

177
00:09:03,100 --> 00:09:05,100
There's a lot that people need 
to know about these. 

178
00:09:05,300 --> 00:09:07,600
Things. 
There's a lot of things people 

179
00:09:07,600 --> 00:09:10,400
need to do and requirements 
really affect everyone. 

180
00:09:10,400 --> 00:09:13,200
On the project, all the 
stakeholders on the project 

181
00:09:13,200 --> 00:09:16,000
requirements is where their 
interests all intersect. 

182
00:09:16,100 --> 00:09:19,200
So that's a lot to read and many
people have read it. 

183
00:09:19,200 --> 00:09:21,200
But what about something 
shorter? 

184
00:09:21,200 --> 00:09:25,500
Well, in contrast, the software 
requirements Essentials book is 

185
00:09:25,500 --> 00:09:29,600
only about 150 pages long. 
It's about 1/4 is large. 

186
00:09:29,600 --> 00:09:33,200
So obviously there's a lot more 
information in the big book and 

187
00:09:33,200 --> 00:09:35,100
we didn't try to duplicate all 
of that. 

188
00:09:35,200 --> 00:09:38,400
At, but we don't have as many 
topics, we don't go into as much

189
00:09:38,400 --> 00:09:40,500
detail. 
We don't have as many stories 

190
00:09:40,500 --> 00:09:42,900
and appendices and all the other
things you find in a 

191
00:09:42,908 --> 00:09:46,300
comprehensive book, but the 
software requirements Essentials

192
00:09:46,300 --> 00:09:49,900
book is really an excellent 
resource for people who want to 

193
00:09:50,000 --> 00:09:52,300
quickly. 
Learn about these, most 

194
00:09:52,300 --> 00:09:56,000
important core practices that 
can add value to their projects 

195
00:09:56,000 --> 00:09:57,400
and help, keep them out of 
trouble. 

196
00:09:57,600 --> 00:10:00,600
And then, you can go back to the
big software requirements book 

197
00:10:00,600 --> 00:10:04,600
or other resources for details 
when you need them, right? 

198
00:10:04,700 --> 00:10:06,300
I had to read. 
For the new book as well. 

199
00:10:06,300 --> 00:10:08,100
So, I think it's pretty short, 
right? 

200
00:10:08,100 --> 00:10:11,200
Like you said, I think someone 
who likes to read can easily 

201
00:10:11,200 --> 00:10:14,300
finish it in a day or two, so I 
think it covers a lot of 

202
00:10:14,300 --> 00:10:17,100
Essentials just like the title 
like the essentials of software 

203
00:10:17,100 --> 00:10:19,300
requirements which we are going 
to cover now. 

204
00:10:19,300 --> 00:10:22,500
So for people who are maybe a 
little bit of confused about 

205
00:10:22,508 --> 00:10:25,600
what is software requirements, 
or they had been burned before 

206
00:10:25,600 --> 00:10:29,100
about bad software requirements.
So baby if you can elaborate, 

207
00:10:29,100 --> 00:10:32,400
what is a software requirement? 
Well, that's an interesting 

208
00:10:32,400 --> 00:10:34,700
question because it seems like 
there should be a really simple.

209
00:10:35,200 --> 00:10:38,800
Short answer, but there's not 
and I think the first thing 

210
00:10:38,800 --> 00:10:42,500
people have to understand when 
they start talking about 

211
00:10:42,500 --> 00:10:45,600
requirements on any project is 
that people have different ideas

212
00:10:45,600 --> 00:10:49,400
of what that word means. 
And so we immediately have an 

213
00:10:49,400 --> 00:10:53,100
uphill battle because people, 
you know, one person says, well 

214
00:10:53,100 --> 00:10:55,800
let's talk about requirements 
and different people in that 

215
00:10:55,800 --> 00:10:59,300
conversation have different 
ideas of what kind of knowledge,

216
00:10:59,300 --> 00:11:01,800
what kind of information that 
includes. 

217
00:11:02,000 --> 00:11:04,700
And so I think people have to 
learn that there are different 

218
00:11:04,700 --> 00:11:07,500
kinds As of requirements 
information, we have to put some

219
00:11:07,500 --> 00:11:10,100
adjectives in front of the word 
requirements. 

220
00:11:10,600 --> 00:11:13,400
So we have to think about, for 
example, business requirements 

221
00:11:13,400 --> 00:11:16,700
and to me that's talking about 
really, the answering the 

222
00:11:16,700 --> 00:11:19,500
question of why are we working 
on this project? 

223
00:11:19,600 --> 00:11:21,700
What are our objectives that led
us to decide that? 

224
00:11:21,700 --> 00:11:24,500
This is an important project to 
start with and then there are 

225
00:11:24,700 --> 00:11:28,300
user requirements which talk 
about the things people will be 

226
00:11:28,300 --> 00:11:32,200
able to do with the product or 
the solution whatever it is 

227
00:11:32,200 --> 00:11:36,200
you're building and but then 
there's other Al's that are the 

228
00:11:36,200 --> 00:11:38,200
kinds of things that developers 
need to know about. 

229
00:11:38,200 --> 00:11:40,300
They need to know about the 
functional requirements. 

230
00:11:40,300 --> 00:11:43,800
The basic ways the system is 
supposed to behave under certain

231
00:11:43,800 --> 00:11:47,300
circumstances, and there's also 
non-functional requirements. 

232
00:11:47,300 --> 00:11:50,100
A lot of people don't like that 
term non-functional because it 

233
00:11:50,100 --> 00:11:52,800
tells you what something isn't 
rather than what it is. 

234
00:11:53,500 --> 00:11:56,100
But when people say 
non-functional requirements, 

235
00:11:56,100 --> 00:11:59,400
they're usually thinking of what
are more commonly called quality

236
00:11:59,400 --> 00:12:01,800
attributes. 
And these are things like the 

237
00:12:01,800 --> 00:12:05,100
illah tease, you know, usability
portability and so forth. 

238
00:12:05,600 --> 00:12:09,400
That describe not what the 
product does, but how well it 

239
00:12:09,400 --> 00:12:12,500
does these things, in fact, 
we've all used products that did

240
00:12:12,500 --> 00:12:14,500
just what they were supposed to 
do, but we hated them because 

241
00:12:14,500 --> 00:12:19,000
maybe they crash too often, or 
maybe they were too slow or they

242
00:12:19,000 --> 00:12:20,900
took too many steps to get 
something done. 

243
00:12:20,900 --> 00:12:24,000
So, those are examples of 
products that meet their 

244
00:12:24,000 --> 00:12:27,000
functional requirements, but not
our quality expectations. 

245
00:12:27,300 --> 00:12:29,700
And then we have constraints to 
worry about an external 

246
00:12:29,700 --> 00:12:32,800
interface requirements. 
So, there's all these kinds of 

247
00:12:32,800 --> 00:12:35,900
requirements information that we
have To deal with. 

248
00:12:35,900 --> 00:12:39,700
But basically what we're trying 
to do is with any requirements, 

249
00:12:39,700 --> 00:12:42,400
conversation is understand a 
need. 

250
00:12:42,400 --> 00:12:47,800
And then conceive of ways to 
describe to construction people 

251
00:12:47,800 --> 00:12:51,700
like developers what they have 
to build in a solution to 

252
00:12:51,700 --> 00:12:55,600
satisfy those needs. 
So I think what you said speaks 

253
00:12:55,600 --> 00:12:57,600
true, like they are many 
different types of requirements.

254
00:12:57,600 --> 00:13:00,200
Probably. 
Also, some people, they didn't 

255
00:13:00,200 --> 00:13:03,200
have a chance to have all these 
comprehensive requirements and 

256
00:13:03,200 --> 00:13:05,000
that's why I think it 
requirements, sometimes in any 

257
00:13:05,200 --> 00:13:07,000
With Team becomes a challenge, 
right? 

258
00:13:07,000 --> 00:13:10,700
So the software first of all, 
why it was being built right? 

259
00:13:10,800 --> 00:13:13,300
First it must come from 
requirements but sometimes 

260
00:13:13,300 --> 00:13:16,900
requirements is Big sometimes 
requirements just few lines of 

261
00:13:16,900 --> 00:13:19,700
statement of objectives, right? 
And I think that's where the 

262
00:13:19,700 --> 00:13:22,100
challenge is. 
And I think I still remember in 

263
00:13:22,100 --> 00:13:24,600
our previous episode you 
mentioned that the goal of a 

264
00:13:24,608 --> 00:13:27,900
requirement is actually to have 
a clear and effective 

265
00:13:27,900 --> 00:13:31,200
communication, maybe if you can 
touch on a little bit about this

266
00:13:31,200 --> 00:13:33,400
again, right. 
Why you think requirements is 

267
00:13:33,400 --> 00:13:36,700
very, very important for clear. 
And effective communication. 

268
00:13:37,400 --> 00:13:40,800
Yeah, that's exactly right. 
Henry, in fact, requirements are

269
00:13:40,800 --> 00:13:43,200
not really about technical 
things. 

270
00:13:43,200 --> 00:13:46,400
Requirements are a communication
problem, not a technical 

271
00:13:46,400 --> 00:13:49,000
problem. 
And that's I think why it's 

272
00:13:49,000 --> 00:13:51,500
hard. 
Because rather than just saying,

273
00:13:51,500 --> 00:13:52,800
okay, we understand what the 
build. 

274
00:13:52,800 --> 00:13:55,100
Let's go figure out the right 
language to use in the right 

275
00:13:55,100 --> 00:13:58,200
code to write and what platform 
you're run out of all that kind 

276
00:13:58,200 --> 00:13:59,900
of stuff. 
It's not like that. 

277
00:13:59,900 --> 00:14:03,100
It's a matter of human 
communication and understanding 

278
00:14:03,100 --> 00:14:06,800
a problem and exploration If you
go and ask someone during 

279
00:14:06,800 --> 00:14:09,500
conversation, what are your 
requirements or what do you 

280
00:14:09,500 --> 00:14:11,900
want? 
Those are terrible questions to 

281
00:14:11,900 --> 00:14:15,700
ask because nobody really knows 
how to answer those questions. 

282
00:14:15,900 --> 00:14:20,800
And so we need better questions 
to try to help explore what 

283
00:14:20,800 --> 00:14:24,100
people have in mind and why they
have it in mind. 

284
00:14:24,400 --> 00:14:27,400
And then, we can use that 
information to conceive 

285
00:14:27,400 --> 00:14:29,900
Solutions. 
Hopefully, multiple possible 

286
00:14:29,900 --> 00:14:32,900
solutions, so we can evaluate 
them and choose the most 

287
00:14:32,900 --> 00:14:35,800
appropriate one, but that's why 
it's Hard. 

288
00:14:35,800 --> 00:14:39,100
And one of the results of that 
are, one of the consequences is 

289
00:14:39,100 --> 00:14:41,100
that it has to be done 
iteratively. 

290
00:14:41,400 --> 00:14:44,000
Ideally sure we could just go 
ask somebody, what do you want? 

291
00:14:44,000 --> 00:14:46,400
They'll tell us will go off and 
build it and that just simply 

292
00:14:46,400 --> 00:14:48,100
doesn't work. 
We know that doesn't work. 

293
00:14:48,400 --> 00:14:51,500
And so this process of 
requirements development where 

294
00:14:51,500 --> 00:14:54,100
our goal is. 
Exactly, as you said clear and 

295
00:14:54,100 --> 00:14:57,700
effective communication, it's 
not following a set of rules. 

296
00:14:57,700 --> 00:15:00,100
It's not conforming to some 
standard. 

297
00:15:00,100 --> 00:15:05,000
It's effective communication and
that has to necessarily be done.

298
00:15:05,200 --> 00:15:07,500
In an incremental and iterative 
fashion. 

299
00:15:07,900 --> 00:15:10,900
And that's frustrating for 
people because you go and ask 

300
00:15:10,900 --> 00:15:15,000
someone for information, you get
some and then as the business 

301
00:15:15,000 --> 00:15:18,500
analyst and no matter what your 
job title is, if you're doing 

302
00:15:18,500 --> 00:15:20,400
this kind of work, you're 
functioning as a business 

303
00:15:20,400 --> 00:15:22,600
analyst, that's a role not a job
title. 

304
00:15:23,000 --> 00:15:25,500
So you go think about it and try
to understand it and then you 

305
00:15:25,500 --> 00:15:27,800
realize there's something, you 
thought you understood during 

306
00:15:27,800 --> 00:15:30,500
the conversation. 
But you really don't or you have

307
00:15:30,500 --> 00:15:33,100
questions or you realize it's 
the opposite of what somebody 

308
00:15:33,100 --> 00:15:35,700
else told you the next day. 
So you have To go back and 

309
00:15:35,700 --> 00:15:38,900
revisit things to have to go 
down layer-by-layer to get more 

310
00:15:38,900 --> 00:15:42,400
information and resolve 
conflicts and all that sort of 

311
00:15:42,400 --> 00:15:44,400
stuff. 
And so, that's an iterative 

312
00:15:44,400 --> 00:15:47,200
process that can be frustrating.
For people who might say, well, 

313
00:15:47,200 --> 00:15:49,600
wait, I already told you that's 
just go away and call me when 

314
00:15:49,600 --> 00:15:51,500
you're done and that's just not 
realistic. 

315
00:15:52,000 --> 00:15:55,000
So this is why it's a hard 
problem and I think people just 

316
00:15:55,000 --> 00:15:59,200
have to acknowledge the reality 
of the incremental and iterative

317
00:15:59,200 --> 00:16:02,700
approach and the fact that it's 
relying on imperfect human 

318
00:16:02,700 --> 00:16:05,000
thinking and communication, 
there's no way. 

319
00:16:05,100 --> 00:16:07,700
On that, right? 
Not to mention, you also have to

320
00:16:07,700 --> 00:16:09,800
write it, right? 
Not just communicating asking 

321
00:16:09,800 --> 00:16:12,100
people the questions, but you 
also have to write it. 

322
00:16:12,100 --> 00:16:15,700
So that the developers or 
whoever in the downstream is 

323
00:16:15,700 --> 00:16:17,800
able to understand the 
requirements itself, and be able

324
00:16:17,800 --> 00:16:21,400
to build and test it, right? 
So, I think, when you mention 

325
00:16:21,400 --> 00:16:24,700
about asking people what they 
want, what kind of requirements 

326
00:16:24,700 --> 00:16:27,400
you want, I thinking some 
Executives of some leaders who 

327
00:16:27,400 --> 00:16:30,400
have the ideas, sometimes. 
I'm not very interested in 

328
00:16:30,400 --> 00:16:33,000
detailing the requirements. 
I don't know whether it's a 

329
00:16:33,000 --> 00:16:35,800
problem of time or it's 
something that Even they don't 

330
00:16:35,800 --> 00:16:38,600
have clear idea just like any 
great ideas, right? 

331
00:16:38,600 --> 00:16:41,200
It's just like a spark of an 
idea but you don't have the 

332
00:16:41,200 --> 00:16:44,300
lower level details, what would 
be your advice for people who 

333
00:16:44,300 --> 00:16:46,700
seem to have this all great 
ideas but they are not really 

334
00:16:46,700 --> 00:16:49,200
interested in detailing further 
into requirements. 

335
00:16:49,200 --> 00:16:52,400
So that maybe the business 
analyst job becomes much easier.

336
00:16:52,400 --> 00:16:54,700
Any tips or advice from your 
experience here. 

337
00:16:55,400 --> 00:16:58,800
Well yeah, I think it's great. 
If we could rely on telepathy, 

338
00:16:59,600 --> 00:17:01,400
just exchanging information, 
mentally. 

339
00:17:01,400 --> 00:17:05,000
Or if we could rely on 
Clairvoyance where someone just 

340
00:17:05,099 --> 00:17:07,000
Medically. 
You can see the future and knows

341
00:17:07,000 --> 00:17:09,400
what people need and can fill in
all the blanks. 

342
00:17:09,400 --> 00:17:11,800
But the fact is, those are not 
very good requirements, 

343
00:17:11,800 --> 00:17:14,900
elicitation techniques, I don't 
recommend Clairvoyance and 

344
00:17:14,900 --> 00:17:17,099
telepathy. 
Although on some projects that 

345
00:17:17,099 --> 00:17:20,099
does seem to be the technical 
Foundation, doesn't work very 

346
00:17:20,099 --> 00:17:22,700
well. 
And so I think it's fine to have

347
00:17:22,700 --> 00:17:26,300
people who have visions of a 
product, a solution that's going

348
00:17:26,300 --> 00:17:29,000
to hopefully meet some need. 
And I think it's very helpful if

349
00:17:29,000 --> 00:17:32,600
we can first understand what 
problem this is solving, in 

350
00:17:32,600 --> 00:17:37,000
fact, someone senior person, or 
Visionary might come and say hey

351
00:17:37,000 --> 00:17:39,400
build me this. 
In other words they present you 

352
00:17:39,400 --> 00:17:43,100
not with a need but with a 
solution they have in mind and I

353
00:17:43,108 --> 00:17:46,200
think it's dangerous to either 
assume that the presented 

354
00:17:46,200 --> 00:17:50,300
problem is necessarily correct 
or that the presented solution 

355
00:17:50,300 --> 00:17:54,500
is necessarily appropriate. 
So the question I think of in 

356
00:17:54,500 --> 00:17:58,100
that situation as well, if that 
solution was the answer, what 

357
00:17:58,100 --> 00:18:00,400
was the question? 
Let's back up a step. 

358
00:18:00,500 --> 00:18:03,600
So I'm a big fan of doing some 
root cause analysis to make sure

359
00:18:03,600 --> 00:18:05,700
we understand the problem. 
First. 

360
00:18:05,900 --> 00:18:09,200
And then make sure we can 
address the correct problem. 

361
00:18:09,500 --> 00:18:11,900
But the fact is, we do have to 
get down to detail. 

362
00:18:11,900 --> 00:18:13,900
Somebody has to answer those 
questions. 

363
00:18:13,900 --> 00:18:17,400
Somebody has to bridge the gap 
between, okay, I have an idea 

364
00:18:17,400 --> 00:18:19,500
for a product down to white 
color. 

365
00:18:19,500 --> 00:18:22,400
Should this text be? 
You know, in between there 

366
00:18:22,400 --> 00:18:24,500
there's a whole lot of 
conversation and thinking that 

367
00:18:24,500 --> 00:18:27,500
has to take place and frankly I 
think maybe that's one reason 

368
00:18:27,500 --> 00:18:30,800
why sometimes people don't want 
to do that because thinking is 

369
00:18:30,800 --> 00:18:34,900
hard ideating, is not as hard in
some ways. 

370
00:18:35,000 --> 00:18:38,000
But thinking of all the details,
the implications, the 

371
00:18:38,000 --> 00:18:41,600
connections, the elaboration, 
that's hard. 

372
00:18:41,600 --> 00:18:44,500
And it's frankly, not all that 
much fun, compared to just 

373
00:18:44,500 --> 00:18:47,000
coming up with a cool idea for a
new app, you know. 

374
00:18:47,800 --> 00:18:51,500
So I think we do need to get to 
that point where we understand 

375
00:18:51,500 --> 00:18:54,100
all those details because 
developers are going to build 

376
00:18:54,100 --> 00:18:56,600
one thing. 
They're just building one thing,

377
00:18:57,000 --> 00:19:00,000
and I've heard it said, once 
that the requirements may be 

378
00:19:00,000 --> 00:19:03,800
fuzzy, maybe General, may be 
incomplete, but the product will

379
00:19:03,800 --> 00:19:06,400
be very specific It will be one 
thing. 

380
00:19:06,700 --> 00:19:09,500
So if we want to make sure we 
get the right thing, at least 

381
00:19:09,500 --> 00:19:12,300
eventually, then we're going to 
need the information to be able 

382
00:19:12,300 --> 00:19:14,500
to do that. 
And this is true of any project 

383
00:19:14,500 --> 00:19:18,400
of any product of any culture, 
any development approach, those 

384
00:19:18,400 --> 00:19:20,600
things are true. 
And that's something we tried 

385
00:19:20,600 --> 00:19:22,400
hard to do. 
With this book is make sure that

386
00:19:22,400 --> 00:19:25,900
the 20 practices that we 
selected, the techniques we 

387
00:19:25,900 --> 00:19:29,300
describe around each practice 
really could apply to almost any

388
00:19:29,300 --> 00:19:31,900
situation. 
They're very, very Universal. 

389
00:19:33,500 --> 00:19:35,800
But the other thing you got to a
little bit earlier Henry that I 

390
00:19:35,800 --> 00:19:38,900
want to come back to is the idea
that we need to write some of 

391
00:19:38,900 --> 00:19:43,300
this down because not only is 
telepathy, not very reliable but

392
00:19:43,300 --> 00:19:46,400
neither are human memories. 
I don't know if you've ever been

393
00:19:46,400 --> 00:19:49,300
in a situation where maybe you 
were in a meeting and some 

394
00:19:49,300 --> 00:19:52,500
people walked out of the meeting
and they later on discovered, 

395
00:19:52,500 --> 00:19:57,100
they had different Recollections
of decisions that were made and 

396
00:19:57,100 --> 00:19:59,800
what came out of that and what 
they're supposed to do next 

397
00:20:00,200 --> 00:20:04,400
whenever we have those kinds of 
Of differences in our memories, 

398
00:20:04,400 --> 00:20:07,000
we've got a problem. 
So, I think an important thing 

399
00:20:07,000 --> 00:20:11,200
for people to remember is that 
the cost of recording knowledge,

400
00:20:11,200 --> 00:20:13,700
that is writing it down, or 
otherwise storing it. 

401
00:20:13,700 --> 00:20:18,800
The cost of recording knowledge 
is small compared to the cost of

402
00:20:18,800 --> 00:20:22,500
acquiring the knowledge. 
So I don't frankly have a lot of

403
00:20:22,500 --> 00:20:24,400
patience with people who say, 
well, we don't have time to 

404
00:20:24,400 --> 00:20:27,300
write this down because they're 
setting themselves up for 

405
00:20:27,300 --> 00:20:29,900
problems in the future. 
And basically, they're saying, 

406
00:20:30,100 --> 00:20:31,700
well, we don't have time to 
write this down, but we'll have 

407
00:20:31,700 --> 00:20:34,200
time to figure. 
And out again later. 

408
00:20:34,700 --> 00:20:36,600
That's not a very good way to 
think about it. 

409
00:20:37,200 --> 00:20:40,000
Yeah, we kind of covered this as
well in the previous episode 

410
00:20:40,000 --> 00:20:42,100
right side. 
I think it's really important 

411
00:20:42,100 --> 00:20:46,400
for people the cost of recording
information is actually small, 

412
00:20:46,400 --> 00:20:49,200
even though sometimes we may not
feel like it or we feel like we 

413
00:20:49,200 --> 00:20:52,400
have so many things to do, but 
remember that if we record it? 

414
00:20:52,400 --> 00:20:55,600
Well, it actually saves a lot of
rework at the end later on. 

415
00:20:55,600 --> 00:20:58,100
Right? 
And speaking about just now I 

416
00:20:58,108 --> 00:21:01,200
was laughing when you said that 
the requirements could be fuzzy 

417
00:21:01,200 --> 00:21:03,800
but the Developers We'll build 
only one product. 

418
00:21:03,800 --> 00:21:06,000
That is very specific, right? 
Well, I don't know. 

419
00:21:06,000 --> 00:21:09,700
Now these days with all this AI 
capabilities may be the behavior

420
00:21:09,700 --> 00:21:13,300
of the product might have more 
variety with all the generative 

421
00:21:13,300 --> 00:21:14,900
AI. 
So I mean, looking forward, 

422
00:21:14,900 --> 00:21:17,600
maybe one day, even though the 
requirements is wake, the 

423
00:21:17,600 --> 00:21:19,600
product is just one thing. 
It, I will make it more 

424
00:21:19,600 --> 00:21:22,700
multiplications in terms of 
features and capabilities. 

425
00:21:23,400 --> 00:21:25,500
There's another point. 
I should make along that line. 

426
00:21:25,700 --> 00:21:29,100
I mean I know virtually nothing 
about things like chat GPT and 

427
00:21:29,100 --> 00:21:33,700
the wave of AI stuff going on. 
But in 89 a long time ago. 

428
00:21:33,700 --> 00:21:37,000
I wrote an article called the 
laws of computing at least as I 

429
00:21:37,000 --> 00:21:39,700
understood them to be back. 
Then in law number seven, I 

430
00:21:39,700 --> 00:21:41,400
think is still worth keeping in 
mind. 

431
00:21:41,600 --> 00:21:45,100
Artificial intelligence is no 
substitute for the real thing. 

432
00:21:45,600 --> 00:21:48,000
Yes, I think that's still a 
valid law, you know. 

433
00:21:48,000 --> 00:21:51,900
So these are tools but you've 
probably heard the saying that a

434
00:21:51,900 --> 00:21:54,100
fool with a tool is still a 
fool. 

435
00:21:54,100 --> 00:21:56,800
Have you ever heard that saying?
Yeah, it's a pretty common 

436
00:21:56,800 --> 00:21:58,600
expression but I changed it 
slightly. 

437
00:21:58,600 --> 00:22:02,100
I say a fool with a tool is an 
amplified fool. 

438
00:22:03,200 --> 00:22:04,700
And that's worth keeping in 
mind. 

439
00:22:05,200 --> 00:22:08,200
Nice, nice. 
So you mentioned just now about 

440
00:22:08,200 --> 00:22:10,700
understanding the problem 
before, converging on a 

441
00:22:10,700 --> 00:22:12,500
solution. 
So this is actually the practice

442
00:22:12,500 --> 00:22:15,300
number one part of the 
requirements foundation. 

443
00:22:15,600 --> 00:22:18,500
So when you mention sometimes as
a software development team, we 

444
00:22:18,800 --> 00:22:21,400
just given a task with a 
solution, right? 

445
00:22:21,800 --> 00:22:25,800
And we have to just deliver it 
but you invited people to 

446
00:22:25,800 --> 00:22:28,700
actually stop thinking about 
what actually the problem is. 

447
00:22:29,000 --> 00:22:32,100
So maybe from the situation that
you encounter before, right? 

448
00:22:32,500 --> 00:22:36,400
How can teams react when such 
situation coming that they are 

449
00:22:36,400 --> 00:22:39,300
asked to build some kind of just
a solution, just build this, 

450
00:22:39,300 --> 00:22:41,700
right? 
And how can they actually 

451
00:22:41,700 --> 00:22:44,400
capture the requirements from 
that solution better? 

452
00:22:45,200 --> 00:22:48,700
Well, I think you need to think 
backwards a little bit. 

453
00:22:48,800 --> 00:22:51,500
If you're presented with a 
problem, then I think it's very 

454
00:22:51,500 --> 00:22:55,500
helpful to do some root cause 
analysis, and you can build 

455
00:22:55,500 --> 00:22:58,000
what's called a root cause 
analysis diagram, sometimes 

456
00:22:58,000 --> 00:23:01,100
called a fishbone diagram, or an
Ishikawa diagram. 

457
00:23:01,400 --> 00:23:04,700
This is sort of a tree structure
where you think backwards from 

458
00:23:04,700 --> 00:23:07,400
the presented problem and try to
understand the contributing 

459
00:23:07,400 --> 00:23:09,400
causes like, why is that a 
problem? 

460
00:23:09,400 --> 00:23:12,000
And that's the question we're 
asking with this thought, 

461
00:23:12,000 --> 00:23:14,900
process is, well, if that's a 
problem, or if that's a goal 

462
00:23:14,900 --> 00:23:18,000
that we're trying to achieve, 
why are we not already achieving

463
00:23:18,000 --> 00:23:20,500
that goal or why is that a 
problem? 

464
00:23:20,800 --> 00:23:23,300
And you go through this through 
a couple of layers of asking 

465
00:23:23,300 --> 00:23:26,800
why, and hopefully, you'll 
eventually get to some root 

466
00:23:26,800 --> 00:23:30,900
causes that are contributing to 
the perceived problem and those 

467
00:23:30,900 --> 00:23:33,600
become actionable and we can 
Growl, how do we address those 

468
00:23:33,600 --> 00:23:36,300
specific root causes? 
Or you might find to that 

469
00:23:36,300 --> 00:23:38,100
thought process that what 
appears to be? 

470
00:23:38,100 --> 00:23:40,500
The problem isn't really the 
real problem. 

471
00:23:40,500 --> 00:23:44,200
Maybe that's just a symptom of 
the real problem, or maybe it's 

472
00:23:44,200 --> 00:23:46,700
a tangential problem or just 
part of the real problem. 

473
00:23:47,000 --> 00:23:49,700
And you do the same kind of 
thinking if you're presented 

474
00:23:49,700 --> 00:23:52,600
with the solution and someone 
says go build this product or 

475
00:23:52,600 --> 00:23:56,000
this feature, and that's where 
we start asking ourselves. 

476
00:23:56,000 --> 00:23:59,900
The question of why, if that's 
the solution, did you have in 

477
00:23:59,900 --> 00:24:02,000
mind? 
What problem do you think that's

478
00:24:02,000 --> 00:24:03,200
going? 
Going to solve, what do you 

479
00:24:03,200 --> 00:24:06,700
think is going to do for us? 
And why do we think that needs 

480
00:24:06,700 --> 00:24:09,800
to be in there? 
And that's not really 

481
00:24:10,000 --> 00:24:12,100
challenging. 
We're not trying to challenge 

482
00:24:12,100 --> 00:24:15,000
people or say you're wrong. 
When we do that, what we're 

483
00:24:15,000 --> 00:24:17,800
trying to do is understand, 
we're trying to reach an 

484
00:24:17,800 --> 00:24:22,000
understanding that we all agree 
on and can align towards a 

485
00:24:22,000 --> 00:24:24,000
common shared. 
Understanding of the problem a 

486
00:24:24,008 --> 00:24:28,100
common shared vision of the 
solution with confidence, that 

487
00:24:28,200 --> 00:24:30,700
that's the right solution for 
the right problem. 

488
00:24:31,000 --> 00:24:33,600
So just a Of doing that 
backward. 

489
00:24:33,600 --> 00:24:36,300
Thinking a little bit I think is
the right way to make sure that 

490
00:24:36,300 --> 00:24:39,800
we're not wasting our time or 
chasing something that turns out

491
00:24:39,800 --> 00:24:43,400
not to give us a good outcome 
and a phrase that I've heard 

492
00:24:43,400 --> 00:24:45,300
along the line as we were 
working on the book that I 

493
00:24:45,300 --> 00:24:46,800
liked. 
If you don't go through this 

494
00:24:46,900 --> 00:24:50,800
thought, process first, you 
might end up achieving project 

495
00:24:50,800 --> 00:24:53,300
success. 
Hey, we built our solution. 

496
00:24:53,300 --> 00:24:56,800
We delivered it on time and on 
budget and it looks great, but 

497
00:24:56,800 --> 00:25:00,800
product failure, because that 
solution isn't actually solving 

498
00:25:00,800 --> 00:25:02,100
the problem that you were hoping
it. 

499
00:25:02,200 --> 00:25:05,100
Wood or exploiting the 
opportunity that you perceived. 

500
00:25:05,100 --> 00:25:09,000
So we want to try to watch out 
for project success but product 

501
00:25:09,000 --> 00:25:11,500
failure. 
Oh yeah, I think that's really 

502
00:25:11,500 --> 00:25:13,800
really important. 
Right because many Enterprise 

503
00:25:13,800 --> 00:25:16,400
projects, right? 
Even though they still stay true

504
00:25:16,400 --> 00:25:18,500
to the timeline, they say, 
through the budget scope and 

505
00:25:18,500 --> 00:25:20,700
things like that. 
So they may not bring the kind 

506
00:25:20,700 --> 00:25:23,600
of business impact of business 
value once the product is 

507
00:25:23,600 --> 00:25:25,700
launched, right? 
So I think understanding the 

508
00:25:25,700 --> 00:25:28,300
problem instead of just 
converging to a solution is 

509
00:25:28,300 --> 00:25:30,400
really important, right? 
And I think in your book you 

510
00:25:30,400 --> 00:25:34,200
also give an example of a set 
Solution that was given but I 

511
00:25:34,200 --> 00:25:36,800
mean in a hypothetical scenario,
right? 

512
00:25:36,900 --> 00:25:40,300
Actually the team who has the 
understanding about the product 

513
00:25:40,300 --> 00:25:43,700
is able to actually advise what 
kind of road maps are many 

514
00:25:43,700 --> 00:25:46,700
Milestones that we can achieve. 
Don't forget about that. 

515
00:25:46,700 --> 00:25:49,100
So whenever you give an idea, 
maybe other people also have a 

516
00:25:49,108 --> 00:25:52,200
better ideas, especially if the 
people are working with the 

517
00:25:52,200 --> 00:25:55,100
product much, much closer than 
you are right. 

518
00:25:55,400 --> 00:25:56,900
I'm sorry. 
If I could just add to that, 

519
00:25:56,900 --> 00:25:59,600
just a little bit Henry. 
This is an example of where 

520
00:25:59,600 --> 00:26:02,000
people have different ideas of 
what the word requirements, me. 

521
00:26:02,200 --> 00:26:04,200
Ins. 
And, you know, this conversation

522
00:26:04,500 --> 00:26:08,000
that we're talking about this 
exploration of why some people 

523
00:26:08,000 --> 00:26:09,800
may not even view that as 
requirements. 

524
00:26:09,800 --> 00:26:12,800
But that's really addressing the
business, requirements that set 

525
00:26:12,800 --> 00:26:15,300
the stage for everything else 
that we do, when we build a 

526
00:26:15,308 --> 00:26:19,000
solution based on technical 
requirements, right? 

527
00:26:19,000 --> 00:26:20,900
So, let's move on to other 
practices. 

528
00:26:20,900 --> 00:26:23,300
As you mentioned, there are 20 
practices, but we won't be 

529
00:26:23,300 --> 00:26:26,200
covering all of them for sure, 
but I will just pick some from 

530
00:26:26,200 --> 00:26:27,800
my interest. 
So the other thing that you 

531
00:26:27,800 --> 00:26:30,800
mentioned about the requirements
fundamentals is that we need to 

532
00:26:30,800 --> 00:26:33,800
Define Solutions. 
Is in particular, what's in 

533
00:26:33,800 --> 00:26:38,200
scope and what is out of scope? 
So can you tell us maybe why it 

534
00:26:38,200 --> 00:26:41,700
is important especially to 
mention the out of scope part? 

535
00:26:42,300 --> 00:26:45,900
Yeah, every project, every 
product is finite, you know. 

536
00:26:45,900 --> 00:26:49,200
It has some things that does, it
has some things that won't do 

537
00:26:49,400 --> 00:26:52,200
and part of understanding our 
business requirements, and our 

538
00:26:52,200 --> 00:26:55,200
business objectives is to draw 
that boundary between what's in 

539
00:26:55,300 --> 00:26:58,200
and what's out. 
And I saw that very nicely done 

540
00:26:58,200 --> 00:27:01,700
at a company once who was 
building a website and not only 

541
00:27:01,700 --> 00:27:04,500
did they they have a list of the
things that the website was 

542
00:27:04,500 --> 00:27:06,900
going to let people do but they 
also had a list of things that 

543
00:27:06,900 --> 00:27:09,500
it explicitly was not going to 
let people do that. 

544
00:27:09,500 --> 00:27:12,700
Someone otherwise might think it
would and that's very helpful 

545
00:27:12,700 --> 00:27:16,100
for people saying, oh okay well 
we've decided it's not going to 

546
00:27:16,108 --> 00:27:19,100
provide this particular service.
You might do that in the future,

547
00:27:19,200 --> 00:27:21,300
that's fine. 
But for whatever release you're 

548
00:27:21,300 --> 00:27:24,100
talking about, we're not going 
to do that and that helps you 

549
00:27:24,100 --> 00:27:28,300
avoid the dreaded Specter of 
scope creep, where people keep 

550
00:27:28,300 --> 00:27:31,100
adding in this and that and she 
wouldn't it be nice if we did 

551
00:27:31,100 --> 00:27:32,000
this. 
And how about that? 

552
00:27:32,400 --> 00:27:34,000
And there's this new kind of 
credit card. 

553
00:27:34,000 --> 00:27:36,900
We have to be able to take those
now to well at some point you 

554
00:27:36,908 --> 00:27:39,200
have to draw the line or you 
never finish anything. 

555
00:27:39,500 --> 00:27:43,200
And so I think understanding the
boundaries between systems is 

556
00:27:43,200 --> 00:27:46,900
helpful for release planning for
scope management. 

557
00:27:47,200 --> 00:27:51,000
And also it's very helpful to 
see where our system. 

558
00:27:51,000 --> 00:27:53,300
Our solution that we're 
describing fits into our 

559
00:27:53,300 --> 00:27:56,100
universe and there's some 
pictures you can draw to help 

560
00:27:56,100 --> 00:27:59,300
you visualize these things. 
When we talk about requirement 

561
00:27:59,300 --> 00:28:02,000
to sort of naturally, think 
about natural language text 

562
00:28:02,100 --> 00:28:04,400
text. 
And that's a big part of it, but

563
00:28:04,400 --> 00:28:08,700
we also can draw all kinds of 
pictures visual analysis models 

564
00:28:08,700 --> 00:28:11,200
to represent information that 
are really valuable. 

565
00:28:11,600 --> 00:28:14,700
For example, a simple context 
diagram, which is not a New 

566
00:28:14,700 --> 00:28:17,000
Concept. 
It's been around for decades, a 

567
00:28:17,008 --> 00:28:20,100
simple circle with some boxes on
the outside and arrows, 

568
00:28:20,100 --> 00:28:21,900
connecting the boxes to the 
circle. 

569
00:28:22,100 --> 00:28:26,700
That helps you see what's inside
our solution inside that Circle.

570
00:28:26,900 --> 00:28:29,600
And what does it connect to on 
the outside? 

571
00:28:29,600 --> 00:28:32,000
Those could be users, they could
be other systems could be. 

572
00:28:32,200 --> 00:28:35,600
Pieces of Hardware. 
That's very valuable information

573
00:28:35,600 --> 00:28:38,300
to draw that boundary. 
Another thing you can do is you 

574
00:28:38,300 --> 00:28:42,000
can create an ecosystem map and 
this is valuable if you have a 

575
00:28:42,000 --> 00:28:46,300
system that fits into an 
existing world, as most do 

576
00:28:46,500 --> 00:28:49,700
rather than being completely 
Standalone and perhaps the 

577
00:28:49,700 --> 00:28:53,000
solution that you're building, 
now requires interfaces to some 

578
00:28:53,000 --> 00:28:55,900
of the other systems that you 
already have in your universe 

579
00:28:56,100 --> 00:28:59,300
and maybe those are not just 
immediate connections, but they 

580
00:28:59,300 --> 00:29:01,400
could be two or three levels 
removed. 

581
00:29:01,400 --> 00:29:03,600
So there's some Pass throughs 
and Communications and 

582
00:29:03,600 --> 00:29:07,400
interfaces that get involved and
by drawing an ecosystem map, you

583
00:29:07,400 --> 00:29:11,200
can more easily see how all of 
these things, all these pieces 

584
00:29:11,200 --> 00:29:14,400
of systems in your world fit 
together in a web and what the 

585
00:29:14,400 --> 00:29:17,600
interfaces between them look 
like at a high level and that 

586
00:29:17,600 --> 00:29:19,600
helps you see dependencies, it 
helps. 

587
00:29:19,600 --> 00:29:22,100
You see where we're going to 
have to build some glue to 

588
00:29:22,100 --> 00:29:24,100
connect these systems so they 
can communicate. 

589
00:29:24,100 --> 00:29:27,000
Maybe you're using some 
third-party applications for 

590
00:29:27,000 --> 00:29:30,900
security checks or for payment 
handling or something like that 

591
00:29:31,100 --> 00:29:33,300
so you can see how those things.
Together but we got to draw 

592
00:29:33,300 --> 00:29:35,700
those boundaries because 
otherwise you don't know how to 

593
00:29:35,700 --> 00:29:38,500
tell when you're done and 
speaking about scope. 

594
00:29:38,500 --> 00:29:39,900
Creep, just now you mentioned, 
right? 

595
00:29:39,900 --> 00:29:44,700
So I think by specifying clearly
what is not in scope, be kind of

596
00:29:44,700 --> 00:29:46,900
like covered, okay? 
This is the things that we 

597
00:29:46,900 --> 00:29:49,400
decided early on that. 
We will not be building, or we 

598
00:29:49,400 --> 00:29:52,400
will not be including so that 
later on in the future. 

599
00:29:52,400 --> 00:29:56,700
You cannot have a room for some 
maybe Tiki product leaders or 

600
00:29:56,700 --> 00:29:58,800
Executives to request something,
right? 

601
00:29:58,800 --> 00:30:01,900
Request to add more stuff even 
though maybe that request. 

602
00:30:02,100 --> 00:30:05,300
Sounds so simple but sometimes 
it's not that simple whenever 

603
00:30:05,300 --> 00:30:08,000
you try to build a system from 
scratch, for example. 

604
00:30:08,200 --> 00:30:10,700
So I think having the out of 
scope is really, really 

605
00:30:10,700 --> 00:30:12,900
important. 
So for software teams out there,

606
00:30:12,900 --> 00:30:15,900
if you haven't done this 
practice, please make sure that 

607
00:30:15,900 --> 00:30:18,500
you Define explicitly from the 
beginning. 

608
00:30:18,700 --> 00:30:21,100
What will be in scope and what 
will be out of scope? 

609
00:30:21,200 --> 00:30:25,100
This is practice number three 
and it's helpful to also know 

610
00:30:25,100 --> 00:30:27,000
what might be coming in the 
future. 

611
00:30:27,300 --> 00:30:31,000
So maybe some proposed feature 
is going to be out of scope for 

612
00:30:31,000 --> 00:30:33,500
now. 
We see that as a growth 

613
00:30:33,500 --> 00:30:35,400
Direction. 
So we might add in the future, 

614
00:30:35,600 --> 00:30:39,700
and by being aware of that, you 
can at least build in Hooks and,

615
00:30:39,700 --> 00:30:42,800
you know, the interfaces so that
it would be easy to plug in 

616
00:30:42,800 --> 00:30:46,600
something later on to grow in 
that direction, but not today. 

617
00:30:47,200 --> 00:30:50,700
Yep, thanks for adding debt. 
So let's move on to the next 

618
00:30:50,700 --> 00:30:52,900
practice. 
This part is actually about 

619
00:30:52,900 --> 00:30:55,600
requirements elicitation but 
before we move on to the 

620
00:30:55,600 --> 00:30:58,600
practice, maybe for some people 
who are not yet familiar with 

621
00:30:58,600 --> 00:31:01,900
this term elicitation, right? 
Can you maybe explain any lie? 

622
00:31:02,100 --> 00:31:05,100
Everett, how does it compare 
elicitation forces Gathering 

623
00:31:05,100 --> 00:31:08,000
requirements, which maybe some 
of us are more used to? 

624
00:31:08,900 --> 00:31:11,100
That's a good question. 
Henry, people do often talk 

625
00:31:11,100 --> 00:31:15,400
about Gathering requirements but
when I hear that term, I have a 

626
00:31:15,400 --> 00:31:18,800
mental image of walking around 
with a basket picking flowers. 

627
00:31:18,800 --> 00:31:20,400
They're out there. 
You just pick out the ones you 

628
00:31:20,400 --> 00:31:24,100
like and you put them in the 
basket or hunting Easter eggs or

629
00:31:24,100 --> 00:31:26,900
something like that. 
In other words, Gathering 

630
00:31:26,900 --> 00:31:30,700
requirements to me, sort of 
suggest a collection process. 

631
00:31:31,100 --> 00:31:32,700
And that's definitely A part of 
it. 

632
00:31:32,700 --> 00:31:35,700
You know, sometimes we do know 
of things that we're going to 

633
00:31:35,700 --> 00:31:39,000
have to build or have ideas. 
We can just put into the basket,

634
00:31:39,300 --> 00:31:43,500
but the be a, the business 
analyst isn't just a scribe, who

635
00:31:43,500 --> 00:31:46,400
just writes down, whatever 
people tell them they want. 

636
00:31:46,400 --> 00:31:50,000
Instead the business analyst is 
a guide who's leading this 

637
00:31:50,000 --> 00:31:55,100
exploration of a requirement 
space and so elicitation is 

638
00:31:55,100 --> 00:31:59,800
partly collection partly, 
Discovery partly invention and 

639
00:31:59,800 --> 00:32:01,900
the ba is the guide for those 
processes. 

640
00:32:02,100 --> 00:32:06,700
Has so elicitation involves 
asking questions, for example, 

641
00:32:06,700 --> 00:32:11,300
to see if people would find 
particular ideas or capability 

642
00:32:11,300 --> 00:32:13,300
useful. 
So someone says well we want 

643
00:32:13,300 --> 00:32:15,800
this, okay. 
Well, would it be helpful to be 

644
00:32:15,800 --> 00:32:18,100
a might ask? 
Would anybody ever want to do 

645
00:32:18,100 --> 00:32:20,200
that? 
Which is maybe an extension of 

646
00:32:20,200 --> 00:32:22,600
this. 
And they say, hmm, I haven't 

647
00:32:22,600 --> 00:32:25,400
thought about that. 
Well no, I don't think anybody 

648
00:32:25,400 --> 00:32:28,500
would want to do that or they 
might say oh wow, that's great. 

649
00:32:28,500 --> 00:32:30,500
I'm sure glad you thought of 
that because we didn't 

650
00:32:30,700 --> 00:32:33,600
solicitation is a rich. 
Process, it's more 

651
00:32:33,600 --> 00:32:36,200
collaborative. 
Not just a matter of collection,

652
00:32:36,200 --> 00:32:39,100
so I try to avoid seeing 
requirements Gathering. 

653
00:32:39,900 --> 00:32:42,300
Yes, I think that's the 
situation out there. 

654
00:32:42,300 --> 00:32:44,100
We can just gather requirements,
right? 

655
00:32:44,100 --> 00:32:46,900
I mean week, no, clearly 100% 
what we want to build, and we 

656
00:32:46,900 --> 00:32:49,600
just write it down, right? 
So, I think that ever, I think, 

657
00:32:49,600 --> 00:32:52,000
at least in my experience that 
never happens. 

658
00:32:52,600 --> 00:32:55,800
So, there's always some room of 
ambiguity, some room of ideas, 

659
00:32:55,800 --> 00:32:58,500
as well from different people. 
So I think requirements 

660
00:32:58,500 --> 00:33:00,700
elicitation is probably the 
proper term that you will 

661
00:33:00,700 --> 00:33:03,200
suggest here. 
So, Go to one of the practice 

662
00:33:03,200 --> 00:33:06,400
with its practice number 6. 
Understand what users need to do

663
00:33:06,400 --> 00:33:09,400
with the solution, right? 
So just now we talked about 

664
00:33:09,400 --> 00:33:12,500
understanding the problem not 
converging to the solution but 

665
00:33:12,500 --> 00:33:14,700
in this requirements, 
elicitation you also suggest 

666
00:33:14,700 --> 00:33:18,500
people to actually understand 
the need of the users with the 

667
00:33:18,500 --> 00:33:20,400
solution. 
Maybe tell us more about this 

668
00:33:20,400 --> 00:33:23,400
one. 
That's one of my favorite 

669
00:33:23,500 --> 00:33:25,700
topics. 
Understand what users need to do

670
00:33:25,700 --> 00:33:28,400
with the solution practice 
number 6, but in terms of 

671
00:33:28,400 --> 00:33:31,300
importance, I think it could be 
considered practically practice 

672
00:33:31,300 --> 00:33:33,400
number one. 
In fact, one of the most 

673
00:33:33,400 --> 00:33:37,100
important things I learned in my
career as a software developer 

674
00:33:37,300 --> 00:33:39,900
is to focus. 
Not on features, not on the 

675
00:33:39,900 --> 00:33:42,700
product itself at least at this 
stage of requirements 

676
00:33:42,700 --> 00:33:46,200
exploration. 
But rather focus on usage. 

677
00:33:46,200 --> 00:33:48,500
What do people need to do with 
the product? 

678
00:33:49,300 --> 00:33:53,100
And that's a much better 
approach to exploring 

679
00:33:53,500 --> 00:33:56,600
requirements usage Centric 
exploration as opposed to 

680
00:33:56,600 --> 00:34:00,000
product or feature Centric 
because by understanding what 

681
00:34:00,000 --> 00:34:03,600
people need to do with. 
The solution or certain parts of

682
00:34:03,600 --> 00:34:06,100
it. 
We can then put on our business 

683
00:34:06,100 --> 00:34:10,000
analyst hat and we can derive 
the necessary functionality that

684
00:34:10,000 --> 00:34:12,199
has to be implemented to let 
people do that. 

685
00:34:12,400 --> 00:34:15,699
We can also prioritize at that 
higher level of abstraction that

686
00:34:15,699 --> 00:34:18,100
says, oh, okay. 
Doing this task, is more common,

687
00:34:18,100 --> 00:34:20,900
or more important than doing 
that task. 

688
00:34:20,900 --> 00:34:23,600
So what are all the bits of 
functionality associated with 

689
00:34:23,600 --> 00:34:26,699
those two, various tasks that 
helps us prioritize a little bit

690
00:34:26,699 --> 00:34:30,500
higher level of abstraction, 
instead of trying to take 500 

691
00:34:30,500 --> 00:34:33,000
requirements and their stories 
and Gravel, which one is most 

692
00:34:33,000 --> 00:34:35,600
important? 
We can deal with complexity 

693
00:34:35,600 --> 00:34:38,199
through abstraction that way 
through some hierarchy. 

694
00:34:38,500 --> 00:34:41,400
And that's a very good example. 
Also, of how to change that 

695
00:34:41,400 --> 00:34:43,000
question. 
Remember, I suggested earlier 

696
00:34:43,000 --> 00:34:46,199
that bad questions to ask around
requirements are, what do you 

697
00:34:46,199 --> 00:34:48,300
want or what are your 
requirements? 

698
00:34:48,600 --> 00:34:51,199
A better question is, what do 
you need to do? 

699
00:34:51,500 --> 00:34:53,699
What do you want the solution to
do for you? 

700
00:34:53,699 --> 00:34:55,800
Let's not ask what the solution 
should have in it. 

701
00:34:55,800 --> 00:34:59,000
Let's ask what you need to do 
with the solution, so that's 

702
00:34:59,000 --> 00:35:01,500
where things like use cases and 
user stories can become 

703
00:35:01,500 --> 00:35:04,200
valuable. 
Abel and that fits at the level 

704
00:35:04,200 --> 00:35:08,500
of what I consider to be user 
requirements, the II be a, The 

705
00:35:08,500 --> 00:35:10,700
International Institute for 
business analysis. 

706
00:35:11,000 --> 00:35:14,600
Talks about stakeholder 
requirements as being kind of 

707
00:35:14,600 --> 00:35:17,800
between business requirements 
and solution requirements. 

708
00:35:18,200 --> 00:35:20,800
I don't really like that term 
because basically as I see it 

709
00:35:20,900 --> 00:35:23,400
all requirements come from some 
stakeholder. 

710
00:35:23,700 --> 00:35:27,400
So I'm specifically talking 
about user requirements, the 

711
00:35:27,400 --> 00:35:30,800
things that various kinds of 
users need to do with the 

712
00:35:30,800 --> 00:35:33,800
solution. 
And that to me is a really 

713
00:35:34,200 --> 00:35:37,000
valuable way to both, make sure 
that we include all the 

714
00:35:37,000 --> 00:35:39,100
functionality. 
People need to do those things. 

715
00:35:39,500 --> 00:35:42,300
And have you ever worked on a 
project or seen a project where 

716
00:35:42,300 --> 00:35:45,400
people built functionality that 
someone said they needed but no 

717
00:35:45,400 --> 00:35:47,600
one ever used it. 
You're seeing that happen? 

718
00:35:48,000 --> 00:35:49,900
Yes. 
I think it happened in some 

719
00:35:49,900 --> 00:35:51,800
parts of Valium of my career as 
well. 

720
00:35:51,800 --> 00:35:54,600
So we have to build a lot of 
features but I'm particularly 

721
00:35:54,600 --> 00:35:56,900
not sure like how many users 
actually use that. 

722
00:35:57,100 --> 00:35:59,700
Yeah, that's very common. 
In fact, there's data people 

723
00:35:59,700 --> 00:36:01,800
have tried to study in the 
software industry. 

724
00:36:02,000 --> 00:36:04,000
Of what percentage of the 
features. 

725
00:36:04,000 --> 00:36:08,500
However you define that in 
common products never get used 

726
00:36:08,500 --> 00:36:12,200
or rarely get used and it's over
50% in some of these analyses. 

727
00:36:12,200 --> 00:36:15,700
Well you've worked very hard 
building, those features that 

728
00:36:15,707 --> 00:36:18,500
nobody used. 
So I think it's important to 

729
00:36:18,500 --> 00:36:21,300
make sure we can focus our 
attention and our priorities on 

730
00:36:21,300 --> 00:36:24,700
the things that we know people 
are going to use and that's why 

731
00:36:24,700 --> 00:36:28,400
understanding usage patterns is 
a really important starting 

732
00:36:28,400 --> 00:36:30,500
point for elicitation. 
Yeah. 

733
00:36:30,500 --> 00:36:33,200
So in part up, what some people 
If I thought this is knowing the

734
00:36:33,200 --> 00:36:36,400
jobs to be done for the users, 
that want to use the product, 

735
00:36:36,400 --> 00:36:38,100
right? 
And I think also another 

736
00:36:38,100 --> 00:36:40,600
important point, which you 
mention in the book is that 

737
00:36:40,700 --> 00:36:44,000
sometimes we can demo this 
features, the cool features that

738
00:36:44,000 --> 00:36:46,900
we just built to the users and 
they will be wild and they seem 

739
00:36:46,900 --> 00:36:49,300
to like it. 
But at the end of the day in the

740
00:36:49,300 --> 00:36:51,900
real world, they may not use it 
because that solution that 

741
00:36:51,900 --> 00:36:54,700
features maybe not solving the 
actual need, right? 

742
00:36:54,700 --> 00:36:57,500
So they don't have a use case in
the particular situation that 

743
00:36:57,500 --> 00:37:00,200
they would require the solution 
from the feature. 

744
00:37:00,400 --> 00:37:01,900
So I think that's really 
important. 

745
00:37:02,000 --> 00:37:05,100
Is it snowing the users need 
instead of just building 

746
00:37:05,100 --> 00:37:07,100
features and solutions over 
Solutions. 

747
00:37:07,400 --> 00:37:11,200
So let's maybe touch on a little
bit about the HR world since you

748
00:37:11,200 --> 00:37:13,800
mentioned it earlier, right? 
I think in the agile World, 

749
00:37:13,800 --> 00:37:17,500
sometimes the practice of 
requirements is perceived to be 

750
00:37:17,500 --> 00:37:20,300
different, right? 
So people call it user stories 

751
00:37:20,300 --> 00:37:23,300
writing in a card or Post-its 
and things like that, where the 

752
00:37:23,300 --> 00:37:25,400
requirement seems to be just a 
one liner. 

753
00:37:25,600 --> 00:37:28,400
So user, I want this so that 
blur, right? 

754
00:37:28,700 --> 00:37:31,600
So maybe if you can touch on a 
little bit and advice for the 

755
00:37:32,000 --> 00:37:36,000
This people outside their what 
is the better way of writing 

756
00:37:36,000 --> 00:37:38,700
software requirements for the 
ages of eight teams? 

757
00:37:39,300 --> 00:37:42,300
Well, the first problem I have 
when this kind of question comes

758
00:37:42,300 --> 00:37:44,800
up is what difference does it 
make? 

759
00:37:44,800 --> 00:37:48,800
Because the developers need the 
same information to build the 

760
00:37:48,800 --> 00:37:51,700
right software correctly 
regardless of how they're 

761
00:37:51,700 --> 00:37:55,100
building it, they still need 
that same knowledge and so I 

762
00:37:55,100 --> 00:37:59,200
find the idea that requirements 
are all different on agile, 

763
00:37:59,200 --> 00:38:01,500
projects, kind of silly, 
frankly. 

764
00:38:01,900 --> 00:38:04,200
Now certainly there are 
differences between agile and 

765
00:38:04,200 --> 00:38:07,900
traditional projects in how they
slice and dice these practices 

766
00:38:07,900 --> 00:38:11,100
and you may do things in smaller
increments, you may not write 

767
00:38:11,100 --> 00:38:15,200
down as much which works fine. 
If you have a short timelines 

768
00:38:15,200 --> 00:38:17,100
and things aren't changing very 
rapidly. 

769
00:38:17,500 --> 00:38:19,900
And people are working close 
together day to day. 

770
00:38:19,900 --> 00:38:22,400
That's fine. 
But it doesn't change the nature

771
00:38:22,400 --> 00:38:24,700
of the information that people 
need to do the job. 

772
00:38:24,900 --> 00:38:28,600
So I think whether you call them
user stories or epochs that's a 

773
00:38:28,600 --> 00:38:34,600
Mystique, that's not substantive
my I think the idea of how you 

774
00:38:34,600 --> 00:38:39,400
phrase user stories is valuable 
by saying, as a particular type 

775
00:38:39,400 --> 00:38:44,300
of user, I need a certain 
capability because of some 

776
00:38:44,300 --> 00:38:46,900
justification. 
Some rationale that's helpful to

777
00:38:46,900 --> 00:38:50,100
put it into a context, that's 
more valuable and more 

778
00:38:50,100 --> 00:38:52,900
understandable. 
So people can see the whole 

779
00:38:52,900 --> 00:38:56,800
picture a little bit better, but
I think really quickly a column 

780
00:38:56,800 --> 00:38:59,100
user stories or not is not 
important. 

781
00:38:59,700 --> 00:39:05,200
One concern I do have Is that it
can do user stories well or like

782
00:39:05,200 --> 00:39:06,600
anything else, you can do them 
badly. 

783
00:39:06,600 --> 00:39:10,600
And if the user story becomes 
the only Quantum of 

784
00:39:10,600 --> 00:39:13,500
requirements, then, really, 
we're trying to take all those 

785
00:39:13,500 --> 00:39:16,500
different kinds of requirements 
knowledge that we talked about 

786
00:39:16,500 --> 00:39:19,200
at the beginning of our 
conversation and turn them into 

787
00:39:19,207 --> 00:39:21,700
user stories. 
And some of those stories might 

788
00:39:21,700 --> 00:39:24,800
be bits of functionality. 
Some could be full feature 

789
00:39:24,800 --> 00:39:29,000
descriptions, some could be 
non-functional requirements, 

790
00:39:29,000 --> 00:39:33,400
like security requirements, say 
our Real issues, some could be 

791
00:39:33,400 --> 00:39:36,000
business rules, some could be 
data definitions. 

792
00:39:36,000 --> 00:39:38,700
Well, those are all different 
kinds of information. 

793
00:39:38,700 --> 00:39:42,900
And if the only container you 
create to store requirements, 

794
00:39:42,900 --> 00:39:45,300
knowledge is this thing called a
user Story. 

795
00:39:45,700 --> 00:39:48,800
How do you tell those apart? 
How do you connect them? 

796
00:39:48,800 --> 00:39:51,100
How do you see that? 
Oh, here's some pieces of data, 

797
00:39:51,400 --> 00:39:54,600
which really tied together, 
multiple functional user stories

798
00:39:54,900 --> 00:39:57,400
or here are some business rules 
that apply to certain user 

799
00:39:57,400 --> 00:40:00,700
stories but not others or here 
are some performance 

800
00:40:00,700 --> 00:40:03,700
requirements. 
That affect certain user stories

801
00:40:03,700 --> 00:40:06,800
but not others. 
So, I think the taking any idea,

802
00:40:06,800 --> 00:40:10,800
you have about something called 
a requirement and forcing it 

803
00:40:10,800 --> 00:40:15,100
into a user story, construct, 
can be less than helpful at 

804
00:40:15,100 --> 00:40:17,700
times. 
Yeah, so I think some people 

805
00:40:17,700 --> 00:40:19,300
have always dismissing them are 
right. 

806
00:40:19,300 --> 00:40:22,200
So whenever they find, for 
example, the agile Manifesto, it

807
00:40:22,200 --> 00:40:25,400
is set that value collaboration 
more rather than writing 

808
00:40:25,400 --> 00:40:27,900
comprehensive documentation. 
So, that's the first thing. 

809
00:40:27,900 --> 00:40:31,800
And people also seems to refer 
to user story as the only way of

810
00:40:31,900 --> 00:40:34,200
Specifying requirements because 
we want to be a job. 

811
00:40:34,200 --> 00:40:36,800
But I think what I find 
challenging in my day-to-day 

812
00:40:36,800 --> 00:40:39,500
experience is that sometimes 
these are not enough, right? 

813
00:40:39,500 --> 00:40:43,200
Just one liner of sa Persona, 
what kind of things they want to

814
00:40:43,200 --> 00:40:46,700
do, or kind of business value. 
It brings is not sufficient for 

815
00:40:46,707 --> 00:40:49,200
developers to actually write the
software, right? 

816
00:40:49,200 --> 00:40:52,400
We need better specifications, 
we need better, business rules, 

817
00:40:52,400 --> 00:40:54,200
validations and things like 
that. 

818
00:40:54,200 --> 00:40:57,500
So I think sometimes this 
misnomer I think is something 

819
00:40:57,500 --> 00:41:00,600
that is frustrating. 
And what would you advise people

820
00:41:00,600 --> 00:41:02,600
to do? 
Then I mean if You have a user 

821
00:41:02,600 --> 00:41:05,900
story, do you also capture some 
business requirements somewhere 

822
00:41:05,900 --> 00:41:08,800
in the different templates so 
that you can actually correlate 

823
00:41:08,800 --> 00:41:12,000
between multiple user stories 
and a business requirement. 

824
00:41:12,000 --> 00:41:15,200
So maybe if you can give some 
practical tips here for people 

825
00:41:15,200 --> 00:41:17,900
to probably improve their 
software development process. 

826
00:41:18,700 --> 00:41:20,200
Yeah, I think that's a good 
idea. 

827
00:41:20,200 --> 00:41:23,100
In fact, the business 
requirements aspect, which 

828
00:41:23,100 --> 00:41:26,300
includes multiple kinds of 
information, the idea of 

829
00:41:26,300 --> 00:41:30,200
business requirements and you 
can see a template for a vision 

830
00:41:30,200 --> 00:41:33,300
and scope document from My book 
and both the software 

831
00:41:33,300 --> 00:41:35,800
requirements Essentials and the 
software requirements, book 

832
00:41:35,900 --> 00:41:39,100
contain a template for a vision 
of scope document and that's 

833
00:41:39,100 --> 00:41:41,900
just a container for business 
requirements. 

834
00:41:42,200 --> 00:41:45,000
So while I call these things 
documents, they can take many 

835
00:41:45,000 --> 00:41:47,200
different forms. 
They're just containers for 

836
00:41:47,200 --> 00:41:51,500
knowledge, but those kinds of 
things really don't have 

837
00:41:51,500 --> 00:41:54,100
anything to do with how you're 
going to build the product, what

838
00:41:54,100 --> 00:41:56,500
development lifecycle you're 
following, what are your 

839
00:41:56,500 --> 00:41:59,100
business objectives? 
How are we going to measure 

840
00:41:59,100 --> 00:42:01,200
whether we've achieved our 
business objectives? 

841
00:42:01,500 --> 00:42:04,800
What Our constraints that we 
have to work within what's our 

842
00:42:04,800 --> 00:42:08,500
vision of the product whether 
the limitations that we're going

843
00:42:08,500 --> 00:42:10,900
to have as exclusions. 
Like we talked about earlier 

844
00:42:10,900 --> 00:42:14,500
that aren't going to be there. 
These kinds of things really 

845
00:42:14,500 --> 00:42:16,600
don't have anything to do with 
how you build the product. 

846
00:42:16,600 --> 00:42:20,400
So I think they, they lay a 
solid foundation for any kind of

847
00:42:20,400 --> 00:42:22,300
project that you might be 
working on. 

848
00:42:22,600 --> 00:42:27,000
We need some way to tie together
the different pieces of 

849
00:42:27,000 --> 00:42:30,000
information that are related. 
Now if you have a whole bunch of

850
00:42:30,000 --> 00:42:35,000
user stories and Logically flat 
as opposed to hierarchically 

851
00:42:35,000 --> 00:42:37,800
grouped in some fashion. 
That's harder to manage. 

852
00:42:37,800 --> 00:42:40,600
I think if you have a big 
project and you have 500 user 

853
00:42:40,600 --> 00:42:42,800
stories and no, really good way 
to group them. 

854
00:42:42,800 --> 00:42:45,800
Then how do you manage that 
becomes a harder problem than if

855
00:42:45,800 --> 00:42:49,800
you can group them into features
and see the relationships there 

856
00:42:49,800 --> 00:42:52,000
and prioritize at that level and
so forth. 

857
00:42:52,300 --> 00:42:56,700
So I think it's important to 
identify for every project 

858
00:42:56,700 --> 00:43:01,300
really what's the best way for 
us to document at an 

859
00:43:01,300 --> 00:43:03,500
appropriate? 
Fiat level of detail at an 

860
00:43:03,500 --> 00:43:06,900
appropriate time to record the 
information. 

861
00:43:06,900 --> 00:43:09,500
That's essential to see how it 
fits in with all the other 

862
00:43:09,500 --> 00:43:11,500
information. 
We have to see the things that 

863
00:43:11,500 --> 00:43:15,200
span sets of use cases or of 
user stories and so forth. 

864
00:43:15,300 --> 00:43:17,100
Every project should decide how 
to do that. 

865
00:43:17,100 --> 00:43:19,100
And the point is not to be 
agile. 

866
00:43:19,100 --> 00:43:21,100
People sometimes get confused 
about that. 

867
00:43:21,100 --> 00:43:23,300
Who the hell cares? 
If you're agile, but they care 

868
00:43:23,300 --> 00:43:26,200
is, if you're effective, that's 
much more important. 

869
00:43:26,200 --> 00:43:29,200
So, I think the idea that, well,
we can't do that because it's 

870
00:43:29,200 --> 00:43:31,800
not part of scrum, that's just 
silly. 

871
00:43:32,300 --> 00:43:35,900
You're not trying to be scrum, 
you're trying to Be an Effective

872
00:43:35,900 --> 00:43:39,500
software development team. 
So let's keep that goal in mind.

873
00:43:39,500 --> 00:43:41,900
And then, let's choose those 
practices. 

874
00:43:41,900 --> 00:43:44,900
Those kinds of containers, those
levels of detail those role 

875
00:43:44,900 --> 00:43:47,600
assignments, all that, let's 
choose the approaches that are 

876
00:43:47,600 --> 00:43:51,300
going to help us be as effective
as we can be to build the right 

877
00:43:51,300 --> 00:43:53,500
Solutions. 
And if that means that you, 

878
00:43:53,500 --> 00:43:55,900
violate some agile rule, I can 
tell you. 

879
00:43:55,900 --> 00:43:57,800
The agile police are not going 
to come after you. 

880
00:43:57,800 --> 00:44:01,700
That that's not a threat. 
Yeah, that's a funny joke that 

881
00:44:01,800 --> 00:44:04,000
In Italy, but I think that 
brings really true, right? 

882
00:44:04,000 --> 00:44:06,300
So the point here is to Be an 
Effective and productive 

883
00:44:06,300 --> 00:44:08,900
software development teams and 
also, you minimize a lot of 

884
00:44:08,900 --> 00:44:11,400
rework as well, right? 
Especially if you didn't specify

885
00:44:11,400 --> 00:44:14,100
the requirements clearly and the
developers build something. 

886
00:44:14,100 --> 00:44:16,900
But turns out, oh actually, this
is not what I want. 

887
00:44:16,900 --> 00:44:20,400
So the developers come back, fix
it and the cycle goes on and on.

888
00:44:20,900 --> 00:44:23,200
So I think you mentioned about 
templates as well, so don't 

889
00:44:23,200 --> 00:44:27,000
forget for people who want to 
read the book also put a lot of 

890
00:44:27,000 --> 00:44:30,000
links to the websites of the 
book where you can find a lot of

891
00:44:30,000 --> 00:44:32,700
templates. 
So these templates As in relate 

892
00:44:32,700 --> 00:44:35,300
to any software development 
methodology that you use, you 

893
00:44:35,300 --> 00:44:38,300
can use it in any kind of 
projects so make sure to check 

894
00:44:38,300 --> 00:44:41,600
it out as well. 
You've mentioned, I think twice 

895
00:44:41,600 --> 00:44:45,200
now Henry a very, very important
word that I'd like to talk about

896
00:44:45,200 --> 00:44:48,500
for just a minute and that word 
is rework, you know, everybody 

897
00:44:48,500 --> 00:44:52,300
wants to be more productive. 
My first question then is okay, 

898
00:44:52,300 --> 00:44:55,100
well, why are you not already as
productive as you want to be? 

899
00:44:55,200 --> 00:44:57,600
What's the problem and very 
often? 

900
00:44:57,600 --> 00:45:00,900
The problem is that teams end up
spending more time than they 

901
00:45:00,900 --> 00:45:04,000
expect. 
Doing unplanned rework doing 

902
00:45:04,000 --> 00:45:06,300
over something that they thought
was already done. 

903
00:45:06,600 --> 00:45:09,600
And software teams that measure 
how much of their total effort 

904
00:45:09,600 --> 00:45:12,300
is spent on rework. 
Can get very scary numbers 

905
00:45:12,300 --> 00:45:14,000
Thirty or forty percent of your 
total time. 

906
00:45:14,000 --> 00:45:15,700
Might be spent doing things over
now. 

907
00:45:15,700 --> 00:45:18,400
Some of that's just the nature 
of what we do, okay, it is an 

908
00:45:18,400 --> 00:45:22,500
imperfect process things change 
people, learn more that's fine 

909
00:45:22,500 --> 00:45:25,500
so we have to expect some of 
that but you raised the point a 

910
00:45:25,508 --> 00:45:28,200
couple of times and I'm very 
glad you did because I think 

911
00:45:28,200 --> 00:45:30,800
people should be actively 
choosing approaches and 

912
00:45:30,800 --> 00:45:34,700
techniques to try to. 
Avoid the unnecessary rework of 

913
00:45:34,700 --> 00:45:37,000
having gone this way when you 
should have gone. 

914
00:45:37,000 --> 00:45:41,400
The other way, a lot of the 
effort we invest in requirements

915
00:45:41,500 --> 00:45:43,100
is not to pretend that we can 
get it. 

916
00:45:43,100 --> 00:45:44,800
All right. 
The first time and write it down

917
00:45:44,800 --> 00:45:46,500
once and then just go build the 
product. 

918
00:45:46,500 --> 00:45:50,800
It's to lower the risk of having
to do things over later on when 

919
00:45:50,800 --> 00:45:53,500
we planned to do something else 
instead. 

920
00:45:53,700 --> 00:45:57,000
So a lot of how much you choose 
to do around requirements, 

921
00:45:57,000 --> 00:46:01,000
really boils down to controlling
the risk of wasting time on 

922
00:46:01,000 --> 00:46:02,300
unnecessary. 
Riri work. 

923
00:46:02,300 --> 00:46:04,200
So I just wanted to pursue that 
thought a little bit. 

924
00:46:04,300 --> 00:46:06,800
Thank you. 
Yeah, thanks for emphasizing 

925
00:46:06,800 --> 00:46:07,900
that. 
So I think for software 

926
00:46:07,900 --> 00:46:10,800
development teams who haven't 
really measured the amount of 

927
00:46:10,800 --> 00:46:13,500
rework that you have to do, I 
think maybe you can do that 

928
00:46:13,500 --> 00:46:16,700
exercise and maybe you'll be 
surprised by the percentage just

929
00:46:16,700 --> 00:46:20,200
like what comments and it could 
be 30 40 percent or even 50%. 

930
00:46:20,500 --> 00:46:24,000
So in your book you break down 
the practices into multiple 

931
00:46:24,000 --> 00:46:26,300
areas like requirements 
elicitation analysis, 

932
00:46:26,300 --> 00:46:28,400
specification, validation and 
management. 

933
00:46:28,400 --> 00:46:29,700
We won't be covering all of 
them. 

934
00:46:29,900 --> 00:46:31,700
That's maybe fast-forward to the
last part. 

935
00:46:31,800 --> 00:46:33,600
Quadrants management, which I 
find. 

936
00:46:33,800 --> 00:46:36,700
Maybe it's also important to 
cover here in our conversation. 

937
00:46:37,000 --> 00:46:39,700
The practice number 19 is 
actually talking about 

938
00:46:39,700 --> 00:46:42,600
establishing and managing 
requirements based lines. 

939
00:46:42,900 --> 00:46:44,700
So first of all, what is 
Baseline? 

940
00:46:45,000 --> 00:46:47,700
And the second thing is why it 
is important to establish a 

941
00:46:47,707 --> 00:46:51,700
baseline, very good question, 
and that's one of those things 

942
00:46:51,700 --> 00:46:55,100
that could maybe turn off agile 
people's like, oh, Baseline. 

943
00:46:55,100 --> 00:46:56,800
Well, that sounds like old talk 
to me. 

944
00:46:56,800 --> 00:46:58,100
We don't do that stuff around 
here. 

945
00:46:58,100 --> 00:47:00,900
Well, of course you do a 
baseline, is really just an 

946
00:47:00,900 --> 00:47:03,600
agreement. 
It says that for somebody of 

947
00:47:03,600 --> 00:47:06,500
work, whether that's a single, 
it development, iteration or a 

948
00:47:06,500 --> 00:47:11,400
release or an entire project and
product, we're reaching an 

949
00:47:11,408 --> 00:47:13,800
agreement, among the key 
stakeholders about what's going 

950
00:47:13,800 --> 00:47:16,400
to be in that delivered piece of
software. 

951
00:47:16,700 --> 00:47:19,200
And that's all a bass line is, 
it's a reference point. 

952
00:47:19,200 --> 00:47:22,300
And as we're going along through
our requirements planning and 

953
00:47:22,300 --> 00:47:24,600
our project planning. 
Again, regardless of whether 

954
00:47:24,600 --> 00:47:26,900
you're doing agile or 
traditional or some hybrid 

955
00:47:26,900 --> 00:47:30,300
approach, we're iterating on 
that until we decide, okay? 

956
00:47:30,300 --> 00:47:33,000
This is what we are settling. 
Mine is being stuff that will 

957
00:47:33,000 --> 00:47:36,800
fit in the size of the box that 
we have for this upcoming work, 

958
00:47:36,900 --> 00:47:40,100
we're making agreements. 
We're making commitments at that

959
00:47:40,100 --> 00:47:43,200
point to other people. 
So they know what to expect 

960
00:47:43,200 --> 00:47:45,800
whether that's 41 percent of the
final product or a hundred 

961
00:47:45,800 --> 00:47:48,900
percent of the final product. 
So you do that kind of thing. 

962
00:47:48,900 --> 00:47:53,100
Basically on an agile project 
you do it iteration by iteration

963
00:47:53,200 --> 00:47:55,900
by saying okay these are the 
stories that we are planning to 

964
00:47:55,900 --> 00:47:58,500
implement in this iteration. 
That's a baseline. 

965
00:47:58,500 --> 00:48:00,100
It's not more complicated than 
that. 

966
00:48:00,300 --> 00:48:02,900
And that's your reference point 
for Or change, I mean, change 

967
00:48:02,900 --> 00:48:04,600
happens. 
We have to adapt to change and 

968
00:48:04,600 --> 00:48:07,400
that's actually practice. 
Number 20 is to manage changes 

969
00:48:07,400 --> 00:48:10,400
to requirements, effectively 
affects every project again. 

970
00:48:10,700 --> 00:48:13,100
And so, what we're doing is 
we're saying when a change comes

971
00:48:13,100 --> 00:48:17,700
along, how does that affect our 
current and future plans, does 

972
00:48:17,700 --> 00:48:20,200
it go into a current Baseline 
that's under development? 

973
00:48:20,200 --> 00:48:22,500
Well, that means, either, it's 
going to take longer to finish 

974
00:48:22,500 --> 00:48:24,500
that implementation or something
has to go. 

975
00:48:24,600 --> 00:48:27,000
Something has to wait. 
There's no right answer, but we 

976
00:48:27,000 --> 00:48:30,200
have to make those decisions and
so a baseline because the 

977
00:48:30,200 --> 00:48:33,600
reference point for Making those
changes, it becomes a reference 

978
00:48:33,600 --> 00:48:36,500
point for tracking our status 
toward achieving our objectives 

979
00:48:36,500 --> 00:48:40,100
for that development cycle. 
And I think reaching that clear 

980
00:48:40,100 --> 00:48:43,900
agreement is a lot more valuable
than saying, well, here go do 

981
00:48:43,900 --> 00:48:45,600
some stuff and call me when 
you're done and I'll let you 

982
00:48:45,607 --> 00:48:48,000
know if you're really done. 
That doesn't work so well. 

983
00:48:48,300 --> 00:48:50,300
So that's all we're talking 
about when we say defined 

984
00:48:50,300 --> 00:48:53,000
baselines and their different 
ways you can do that depending 

985
00:48:53,000 --> 00:48:54,500
on what lifecycle you're 
following. 

986
00:48:54,700 --> 00:48:58,000
But I think it's important for 
every project to do that you 

987
00:48:58,000 --> 00:49:00,200
know, thoughtful way. 
Right? 

988
00:49:00,200 --> 00:49:02,800
So Baseline is nothing but like 
an agreement, right? 

989
00:49:02,800 --> 00:49:06,000
A set of a commitment that the 
team is delivering, it could be 

990
00:49:06,100 --> 00:49:08,800
but iteration it could be per 
really cycle or it could be 

991
00:49:08,800 --> 00:49:10,800
anything. 
But the key thing here is that 

992
00:49:10,800 --> 00:49:12,200
you need to set a baseline 
right? 

993
00:49:12,200 --> 00:49:14,900
Because otherwise, you can't 
keep building things dynamically

994
00:49:14,900 --> 00:49:17,300
day by day. 
So you need a reference point 

995
00:49:17,300 --> 00:49:19,300
and speaking about coming to the
Baseline. 

996
00:49:19,300 --> 00:49:21,500
You also need to prioritize the 
requirements, right? 

997
00:49:21,500 --> 00:49:24,400
So maybe if we can touch on a 
little bit, how do we actually 

998
00:49:24,400 --> 00:49:27,500
prioritize requirements that we 
have, which could be a lot and 

999
00:49:27,500 --> 00:49:29,300
committed to a certain of 
Baseline. 

1000
00:49:29,500 --> 00:49:31,300
So how can we prioritize, 
better? 

1001
00:49:31,300 --> 00:49:34,100
Maybe that's the question. 
Well, they're certainly a lot of

1002
00:49:34,100 --> 00:49:37,800
Articles written about different
ways to prioritize requirements.

1003
00:49:37,800 --> 00:49:40,900
Different techniques there are 
valuable for it and we have a 

1004
00:49:40,900 --> 00:49:43,500
practice on that. 
Practice 13, says, prioritize 

1005
00:49:43,500 --> 00:49:47,200
the requirements and I think 
teams should prioritize things 

1006
00:49:47,200 --> 00:49:50,100
in the simple away as they can, 
if we can have a conversation 

1007
00:49:50,100 --> 00:49:52,300
and a handshake to agree on what
we do first. 

1008
00:49:52,300 --> 00:49:54,100
And what we do later, that's 
great. 

1009
00:49:54,200 --> 00:49:56,600
Sometimes you have to take a 
more analytical approach, you 

1010
00:49:56,600 --> 00:49:59,300
have to maybe get out of 
spreadsheet and use various 

1011
00:49:59,400 --> 00:50:01,500
Spreadsheet tools. 
Some of which I've developed 

1012
00:50:01,500 --> 00:50:04,100
myself. 
That help you think through the 

1013
00:50:04,100 --> 00:50:06,900
process of deciding which ones 
are more important than work 

1014
00:50:07,000 --> 00:50:11,200
urgent to do, there are a bunch 
of questions that you can think 

1015
00:50:11,200 --> 00:50:13,800
through and I think every team 
should decide well. 

1016
00:50:13,800 --> 00:50:17,500
How do we make those decisions? 
What factors are important to us

1017
00:50:17,700 --> 00:50:20,600
when we try to make priority 
decisions and you might consider

1018
00:50:20,600 --> 00:50:23,800
things like the customer or 
business value, it would deliver

1019
00:50:24,100 --> 00:50:26,900
how would contribute to the 
project or the development of 

1020
00:50:26,900 --> 00:50:30,400
relations goals, who requested 
that A particular feature 

1021
00:50:30,400 --> 00:50:33,400
compared to some other feature. 
How often is each one likely to 

1022
00:50:33,400 --> 00:50:37,100
be used and what's the cost or 
time or technical difficulties 

1023
00:50:37,100 --> 00:50:40,000
associated with implementing it?
So there are a lot of factors 

1024
00:50:40,000 --> 00:50:42,400
that's just a handful of them 
that you might want to consider.

1025
00:50:42,700 --> 00:50:44,900
So I would say first of all, 
each team should think about, 

1026
00:50:44,900 --> 00:50:47,600
what's its decision-making. 
Thought process about priorities

1027
00:50:47,800 --> 00:50:51,300
who even makes those decisions. 
Let's figure out who's going to 

1028
00:50:51,300 --> 00:50:54,000
have the authority and the 
responsibility for making those 

1029
00:50:54,000 --> 00:50:56,300
decisions. 
There are a lot of ways people 

1030
00:50:56,300 --> 00:50:58,900
have decided to do this. 
There's planning poker and 

1031
00:50:58,900 --> 00:51:02,400
there's Things like okay, here's
100 imaginary dollars. 

1032
00:51:02,400 --> 00:51:05,100
How do you allocate those? 
Do you try to rank order them? 

1033
00:51:05,100 --> 00:51:06,900
Which is fine if you have 15 
items? 

1034
00:51:06,900 --> 00:51:09,800
Not so fine if you have 300. 
So there's a lot of techniques. 

1035
00:51:09,800 --> 00:51:12,600
I wouldn't say there's any one 
particular technique that's 

1036
00:51:12,700 --> 00:51:16,000
always fits in every situation 
but the most important thing is 

1037
00:51:16,000 --> 00:51:20,200
for people to consider early on 
who makes the decisions, how do 

1038
00:51:20,200 --> 00:51:22,100
we make those decisions? 
What do we think through? 

1039
00:51:22,100 --> 00:51:24,200
What do we consider when we're 
going to do that? 

1040
00:51:24,400 --> 00:51:27,900
Because that drives the sequence
in which you build the work that

1041
00:51:27,900 --> 00:51:31,500
you have from your backlog of A 
pending possibilities and also 

1042
00:51:31,500 --> 00:51:34,100
helps you make decisions when 
we're considering changes. 

1043
00:51:34,200 --> 00:51:35,600
Okay. 
Something comes along new 

1044
00:51:35,600 --> 00:51:37,600
feature. 
Well, how important is that 

1045
00:51:37,600 --> 00:51:40,000
compared to these other things? 
We plan to do the next 

1046
00:51:40,000 --> 00:51:42,800
development cycle? 
Does one of those wait, because 

1047
00:51:42,800 --> 00:51:45,100
this is more important. 
Those are all part of the 

1048
00:51:45,100 --> 00:51:48,500
thought, process, very important
part and that's something I'm 

1049
00:51:48,508 --> 00:51:51,600
glad the agile teams have 
emphasized more but still every 

1050
00:51:51,600 --> 00:51:54,200
project team has to go through 
those same considerations. 

1051
00:51:54,800 --> 00:51:56,700
So what I hear you say? 
Just now you said that 

1052
00:51:56,700 --> 00:51:58,700
importance of knowing the key 
factors, right? 

1053
00:51:58,700 --> 00:52:01,700
So the team Need to be able to 
put down the trade-offs. 

1054
00:52:01,700 --> 00:52:04,000
What are the levers that you 
want to think about? 

1055
00:52:04,000 --> 00:52:06,900
So that the teams can make 
decisions uniformly, right? 

1056
00:52:06,900 --> 00:52:09,100
It's not like one day, you use 
this kind of a trade off. 

1057
00:52:09,100 --> 00:52:12,000
The next day is the different. 
The next day is, May be the 

1058
00:52:12,000 --> 00:52:14,900
highest person said something. 
Then you have to follow. 

1059
00:52:15,400 --> 00:52:19,000
So you have to probably Define 
the key factors that you want to

1060
00:52:19,000 --> 00:52:21,800
include in the privatization so 
that we can use it over and over

1061
00:52:21,800 --> 00:52:23,900
again. 
So speaking about managing 

1062
00:52:23,900 --> 00:52:26,200
changes, this is the last 
practice that you have practice.

1063
00:52:26,200 --> 00:52:28,600
Number 20 this is a real world, 
right? 

1064
00:52:28,600 --> 00:52:31,300
So things happen Open software 
requirements, change, sometimes 

1065
00:52:31,300 --> 00:52:35,100
in the middle of the iteration. 
That means also changing your 

1066
00:52:35,100 --> 00:52:38,000
Baseline, right? 
So how we can manage changes to 

1067
00:52:38,000 --> 00:52:41,100
requirements, effectively, I 
think for people who probably 

1068
00:52:41,100 --> 00:52:43,800
most likely are going to 
encounter this over and over 

1069
00:52:43,800 --> 00:52:46,600
again in their software 
development career, well, the 

1070
00:52:46,600 --> 00:52:50,600
first thing every team needs to 
do is to adopt I think very 

1071
00:52:50,600 --> 00:52:54,200
early on a change process. 
And again, that's something 

1072
00:52:54,200 --> 00:52:56,300
where some people might say, 
hey, well, you know, we don't 

1073
00:52:56,300 --> 00:52:58,000
have a process, we just got to 
get stuff done. 

1074
00:52:58,000 --> 00:53:01,000
Well, the process is just How 
you get stuff done, that's all 

1075
00:53:01,000 --> 00:53:03,300
it is. 
It doesn't have to be fancy but 

1076
00:53:03,300 --> 00:53:06,700
it has to be effective. 
So we have an example in the 

1077
00:53:06,700 --> 00:53:10,900
book of a flowchart, a process 
flow from an agile project. 

1078
00:53:10,900 --> 00:53:14,600
That shows the participants 
processing a change request and 

1079
00:53:14,600 --> 00:53:17,700
making decisions of what's its 
impact going to be for, you 

1080
00:53:17,707 --> 00:53:20,700
know, we need some information 
to be able to handle a change. 

1081
00:53:20,700 --> 00:53:22,600
You need to know what's being 
requested. 

1082
00:53:22,900 --> 00:53:24,700
You need to do a little impact 
analysis. 

1083
00:53:24,700 --> 00:53:27,200
You understand what? 
It's likely to cost and how it's

1084
00:53:27,200 --> 00:53:30,700
going to affect other pending or
Added work or other systems. 

1085
00:53:31,000 --> 00:53:35,000
When would that change be worked
into the development activities?

1086
00:53:35,300 --> 00:53:37,800
Who makes the decisions. 
Again, that's a very important 

1087
00:53:37,800 --> 00:53:39,400
part of it. 
Is who makes the decisions. 

1088
00:53:39,600 --> 00:53:41,100
And how did they make? 
Those decisions. 

1089
00:53:41,400 --> 00:53:44,300
We actually address that very 
important issue in the number 

1090
00:53:44,300 --> 00:53:47,500
five, which is to identify the 
empowered. 

1091
00:53:47,500 --> 00:53:49,300
Stakeholders are decision 
makers. 

1092
00:53:49,300 --> 00:53:51,700
Rather identify the empowered 
decision makers. 

1093
00:53:52,100 --> 00:53:56,500
So, having a process then, makes
it more systematic and Less ad 

1094
00:53:56,500 --> 00:54:01,200
hoc, we need to know who Seems 
the change request and how it 

1095
00:54:01,200 --> 00:54:03,200
gets processed that. 
Can be very simple. 

1096
00:54:03,200 --> 00:54:05,600
One person might do the whole 
thing that's fine. 

1097
00:54:05,800 --> 00:54:09,300
But if you're building a Boeing 
aircraft or something like that,

1098
00:54:09,300 --> 00:54:11,400
there's probably going to be 
more than one person involved 

1099
00:54:11,400 --> 00:54:13,500
with making a decision about 
something to change. 

1100
00:54:13,500 --> 00:54:16,400
So, everything in between a tiny
little app, You're Building 

1101
00:54:16,400 --> 00:54:20,000
yourself and building a huge 
complex systems project. 

1102
00:54:20,000 --> 00:54:22,700
So, adopt a process. 
And, you know, it's interesting 

1103
00:54:22,700 --> 00:54:25,200
because I've worked for Kodak 
for many years. 

1104
00:54:25,200 --> 00:54:28,200
Before I started my own software
consulting company process 

1105
00:54:28,200 --> 00:54:32,500
impact, And my last job at 
Kodak, I spent six months in the

1106
00:54:32,500 --> 00:54:36,000
development group for Kodak.com 
their website and that was 

1107
00:54:36,000 --> 00:54:39,900
before the web taken over 
everything in the late 90s and 

1108
00:54:39,900 --> 00:54:43,900
it was a very fast, moving very 
agile, kind of environment. 

1109
00:54:43,900 --> 00:54:46,600
And I came in for six months to 
lead some process Improvement 

1110
00:54:46,600 --> 00:54:49,800
activities for this group. 
And one thing that we put into 

1111
00:54:49,800 --> 00:54:52,600
place that was extremely 
helpful, was in fact, a defined 

1112
00:54:52,600 --> 00:54:56,500
change process which really 
helped them bring order out of 

1113
00:54:56,500 --> 00:55:02,000
the chaos so that they knew what
to Gone when and why and the 

1114
00:55:02,000 --> 00:55:04,200
people in the group had the 
exact correct attitude. 

1115
00:55:04,200 --> 00:55:07,700
They viewed this process not as 
a straitjacket but is a 

1116
00:55:07,700 --> 00:55:10,100
structure. 
So people shouldn't be afraid of

1117
00:55:10,100 --> 00:55:12,000
process. 
A good process helps, you get 

1118
00:55:12,000 --> 00:55:14,900
things done, more effectively, 
more, consistently more 

1119
00:55:14,900 --> 00:55:18,200
reproducibly, but if the process
doesn't work, people will find a

1120
00:55:18,200 --> 00:55:21,600
way to get around the process 
and they probably should. 

1121
00:55:21,700 --> 00:55:23,800
So that's a clue that. 
Hey, maybe your change process. 

1122
00:55:23,800 --> 00:55:27,200
Need some tune up, right? 
So regardless, whether you are 

1123
00:55:27,200 --> 00:55:30,800
an angel practitioners or motor,
Additional practitioners change 

1124
00:55:30,800 --> 00:55:32,500
process. 
I think is really crucial, 

1125
00:55:32,500 --> 00:55:34,300
right? 
Especially as we all know in any

1126
00:55:34,300 --> 00:55:37,700
software project or software 
product, you will have changes. 

1127
00:55:38,000 --> 00:55:41,200
You will have some kind of a new
ideas, new feature changes, 

1128
00:55:41,200 --> 00:55:43,200
right? 
Or nubuck somehow critical 

1129
00:55:43,200 --> 00:55:46,200
happening in your product, then 
the team will need to handle it 

1130
00:55:46,200 --> 00:55:48,700
as soon as possible. 
So, having the change process, 

1131
00:55:48,700 --> 00:55:51,600
the prioritization technique. 
All these will also play a part 

1132
00:55:51,600 --> 00:55:55,000
in to building a more effective 
software development team so 

1133
00:55:55,000 --> 00:55:58,900
called, I feel that we will not 
be able to stop talking right 

1134
00:55:59,000 --> 00:56:01,400
about Requirements, because 
there's so many great things 

1135
00:56:01,400 --> 00:56:04,000
that we can cover it. 
But unfortunately, we have to 

1136
00:56:04,000 --> 00:56:06,000
wrap up pretty soon because of 
the time. 

1137
00:56:06,300 --> 00:56:09,100
But if you still remember last 
time, I have one last question 

1138
00:56:09,100 --> 00:56:11,100
at the end of our conversation 
which is called the three 

1139
00:56:11,100 --> 00:56:14,000
technical leadership, wisdom, I 
will ask you the same question 

1140
00:56:14,000 --> 00:56:17,100
this time. 
So hopefully you will find a new

1141
00:56:17,100 --> 00:56:20,800
ones based on this new book, or 
maybe if you can refer to the 

1142
00:56:20,800 --> 00:56:23,600
previous ones, that's also fine.
So maybe if you can share your 

1143
00:56:23,800 --> 00:56:26,100
three technical leadership 
wisdom for this episode. 

1144
00:56:26,800 --> 00:56:28,500
Okay. 
I think that's a very good 

1145
00:56:28,500 --> 00:56:30,500
question. 
And the first thing, I would 

1146
00:56:30,500 --> 00:56:34,600
suggest that as you listen to 
this podcast, as you read the 

1147
00:56:34,600 --> 00:56:37,600
software requirements, 
Essentials book or other books. 

1148
00:56:38,100 --> 00:56:40,900
If you watch the videos that 
were putting out, I just 

1149
00:56:40,900 --> 00:56:44,700
recently actually, just today 
started, a series called the one

1150
00:56:44,700 --> 00:56:49,000
minute analyst, or I'm posting 
on my YouTube channel, some very

1151
00:56:49,000 --> 00:56:52,800
quick videos on these topics. 
Don't feel bad if you don't 

1152
00:56:52,800 --> 00:56:56,000
already do all these things on 
your project, okay? 

1153
00:56:56,000 --> 00:56:58,800
That's the first piece of wisdom
is, maybe you look at all these 

1154
00:56:58,800 --> 00:57:00,800
things. 
Should be doing and see sounds 

1155
00:57:00,800 --> 00:57:03,300
like a good idea and you say oh 
we're not doing that, you know, 

1156
00:57:03,300 --> 00:57:06,100
we're we're failing. 
No, don't feel bad. 

1157
00:57:06,100 --> 00:57:08,700
If you don't already perform all
those practices on your project 

1158
00:57:08,700 --> 00:57:10,300
that's fine. 
That's where everybody starts. 

1159
00:57:10,600 --> 00:57:13,700
The second one, then would be as
you go through this information,

1160
00:57:13,900 --> 00:57:17,500
try to identify those practices 
that you think would add the 

1161
00:57:17,500 --> 00:57:21,400
most value to your project. 
Look for opportunities to try 

1162
00:57:21,400 --> 00:57:24,600
them and situations whereas some
of these practices are 

1163
00:57:24,600 --> 00:57:28,300
techniques might yield better 
results for you might solve 

1164
00:57:28,300 --> 00:57:29,900
points of pain. 
That you're currently 

1165
00:57:29,900 --> 00:57:32,600
experiencing or might keep you 
out of trouble later in the 

1166
00:57:32,600 --> 00:57:35,400
project by reducing risk as we 
mentioned earlier. 

1167
00:57:35,700 --> 00:57:39,100
So that's the second point is 
look, actively for practices 

1168
00:57:39,100 --> 00:57:41,000
that you think would be worth 
trying. 

1169
00:57:41,300 --> 00:57:44,100
And finally, don't try to do 
everything at once. 

1170
00:57:44,300 --> 00:57:47,900
People can only absorb change 
organizations can only absorb 

1171
00:57:47,900 --> 00:57:51,400
change at a certain rate and 
remember that there's a learning

1172
00:57:51,400 --> 00:57:53,800
curve that's going to slow you 
down a bit. 

1173
00:57:53,800 --> 00:57:56,700
As you try to figure out how to 
make some new method, work for 

1174
00:57:56,700 --> 00:58:00,000
you and for your team. 
But over time These new ways of 

1175
00:58:00,000 --> 00:58:03,600
working based on these practices
that you feel confident or worth

1176
00:58:03,600 --> 00:58:05,600
trying out. 
Those will just become part of 

1177
00:58:05,600 --> 00:58:08,500
your business analyst toolkit 
and I'm pretty confident. 

1178
00:58:08,500 --> 00:58:10,900
You're going to get better 
results once that's happened. 

1179
00:58:11,100 --> 00:58:14,500
So, those are my three pieces of
advice, maybe wisdom, but at 

1180
00:58:14,500 --> 00:58:17,000
least advice, thanks, for 
sharing that. 

1181
00:58:17,000 --> 00:58:19,100
I still remember the last wisdom
that you mentioned, right? 

1182
00:58:19,100 --> 00:58:21,800
Don't do things at once. 
It's like your ultimate Pearl 

1183
00:58:21,900 --> 00:58:24,700
from your previous book, right? 
So we covered that also in the 

1184
00:58:24,700 --> 00:58:26,700
previous episode, thanks for 
sharing this. 

1185
00:58:26,700 --> 00:58:29,100
So we all want to be better, 
right? 

1186
00:58:29,200 --> 00:58:32,300
Especially knowing all this 
information from this podcast or

1187
00:58:32,300 --> 00:58:34,500
from YouTube videos books and 
things like that. 

1188
00:58:34,700 --> 00:58:37,400
But don't feel bad if we haven't
actually done any of these. 

1189
00:58:37,400 --> 00:58:39,400
So we can always start something
small. 

1190
00:58:39,500 --> 00:58:42,500
Do the things that bring us most
value or solving the biggest 

1191
00:58:42,500 --> 00:58:45,600
problem for us, right? 
So thanks for reminding that so 

1192
00:58:45,600 --> 00:58:48,900
of call for people who want to 
learn more about the book or 

1193
00:58:48,900 --> 00:58:52,100
maybe resources from the book. 
Is there a place where they can 

1194
00:58:52,100 --> 00:58:54,900
find you online or the book 
resources online? 

1195
00:58:55,700 --> 00:58:59,700
Definitely, I have two websites.
My personal website is Carl 

1196
00:58:59,700 --> 00:59:03,800
uyghurs.com, and that's i 
before, e, except after C or 

1197
00:59:03,800 --> 00:59:06,900
with the uyghurs. 
My Business website is processed

1198
00:59:06,900 --> 00:59:11,100
impact.com because my company is
called process impact and we 

1199
00:59:11,100 --> 00:59:13,500
have a website. 
Very simple website for the 

1200
00:59:13,500 --> 00:59:14,900
book. 
The book is software 

1201
00:59:14,900 --> 00:59:19,500
requirements, Essentials, and 
the URL is software, Rex, that's

1202
00:59:19,500 --> 00:59:24,800
software, reqs.com. 
And so people, there can see 

1203
00:59:24,800 --> 00:59:27,100
these videos. 
Those they can read a sample of 

1204
00:59:27,100 --> 00:59:29,900
the book, they can see the list 
of 20 practices. 

1205
00:59:29,900 --> 00:59:32,500
We've talked about several of 
them here today, but there's a 

1206
00:59:32,508 --> 00:59:35,800
lot more there and there's also 
a bunch of checklists and 

1207
00:59:35,800 --> 00:59:38,900
document templates spreadsheet, 
tools and other work AIDs that 

1208
00:59:38,900 --> 00:59:41,800
we've made available there. 
So, there's a lot of useful 

1209
00:59:41,800 --> 00:59:46,100
stuff at software x.com, right? 
And I would suggest people to 

1210
00:59:46,100 --> 00:59:48,200
also read the book, right? 
It's a very thin. 

1211
00:59:48,200 --> 00:59:49,900
It's not thick. 
Like a to the software 

1212
00:59:49,900 --> 00:59:52,400
requirements book. 
And I find any kind of role in 

1213
00:59:52,400 --> 00:59:55,000
software development team would 
benefit by reading this book 

1214
00:59:55,000 --> 00:59:57,600
because Then you will understand
the essentials of software 

1215
00:59:57,600 --> 01:00:01,700
requirements, which most likely 
is one of the biggest factor of 

1216
01:00:01,700 --> 01:00:05,100
building the successful product.
So, thanks for sharing this, and

1217
01:00:05,100 --> 01:00:08,000
thanks for writing this book. 
So, Cal, really a pleasure to 

1218
01:00:08,000 --> 01:00:09,500
have a chance to talk to you 
again. 

1219
01:00:09,700 --> 01:00:12,700
And hopefully, the book is 
becoming successful to transform

1220
01:00:12,800 --> 01:00:14,600
people to write better software 
requirements. 

1221
01:00:15,200 --> 01:00:17,600
Well, thanks Henry has been a 
pleasure to have another 

1222
01:00:17,600 --> 01:00:20,600
stimulating conversation with 
you and if we can send people 

1223
01:00:20,600 --> 01:00:24,000
away with one final message that
I've believed for a long time 

1224
01:00:24,000 --> 01:00:26,300
because I've been interested in 
It's for a long time. 

1225
01:00:26,300 --> 01:00:28,500
Is that if you don't get the 
requirements, right? 

1226
01:00:28,500 --> 01:00:30,900
It really doesn't matter how 
well you execute the rest of the

1227
01:00:30,900 --> 01:00:34,400
project, you will fail. 
Well, really well said. 

1228
01:00:37,200 --> 01:00:40,500
Thank you for listening to this 
episode and for staying, right 

1229
01:00:40,500 --> 01:00:42,900
until the end if you highly 
enjoyed it. 

1230
01:00:43,100 --> 01:00:45,400
I would appreciate if you share 
it with your friends and 

1231
01:00:45,400 --> 01:00:48,400
colleagues who you think would 
also benefit from listening to 

1232
01:00:48,400 --> 01:00:50,400
this episode. 
And if you are new to the 

1233
01:00:50,400 --> 01:00:53,400
podcast, make sure to subscribe 
and leave me your valuable 

1234
01:00:53,400 --> 01:00:56,000
review and feedback. 
It helps me a lot. 

1235
01:00:56,000 --> 01:00:58,000
In order to grow this podcast 
better. 

1236
01:00:58,500 --> 01:01:01,300
You can also find the full show 
notes of this conversation on 

1237
01:01:01,300 --> 01:01:05,400
the episode page, at Tech Legion
o.f website, including the full 

1238
01:01:05,400 --> 01:01:08,800
transcript enter, Resting quartz
and links to the resources 

1239
01:01:08,800 --> 01:01:12,800
mention from the conversation. 
And lastly, make sure to 

1240
01:01:12,800 --> 01:01:15,000
subscribe to the shows mailing 
list on package. 

1241
01:01:15,000 --> 01:01:18,600
You know, dot f to get notified 
for any future episodes. 

1242
01:01:19,100 --> 01:01:20,600
Stay tuned for the next 
technology. 

1243
01:01:20,600 --> 01:01:23,500
No episode. 
And until then goodbye.