1
00:00:00,000 --> 00:00:05,200
Well, hello, everybody. It's the 5th of August, 2009, and this is the Agile Executive Podcast,

2
00:00:06,000 --> 00:00:12,480
episode number six, which is exciting. And this is a continuation of a conversation we were having

3
00:00:12,480 --> 00:00:19,840
between Andrew Schaefer, Israel Gatt, and myself about applying Agile notions to not only just

4
00:00:19,840 --> 00:00:24,300
the operations department, if you will, the people who are managing all the machines and servers and

5
00:00:24,300 --> 00:00:29,980
applications once they're developed, but as we'll probably get into the IT department itself,

6
00:00:30,000 --> 00:00:36,240
as a more Agile way of delivering, as we would say in the IT management world, business services and

7
00:00:36,240 --> 00:00:41,820
things along those lines. And to recap, last time we essentially talked about the sort of effect

8
00:00:41,820 --> 00:00:46,660
of being more Agile, and a lot of that had, some of the examples we talked about had to do with things

9
00:00:46,660 --> 00:00:54,000
like having more frequent but smaller delivery of software, and then, of course, with that comes

10
00:00:54,000 --> 00:00:58,120
the ability to be able to actually deploy that stuff into production and all of the IT management

11
00:00:58,120 --> 00:01:02,920
that comes along with it, which we spent a fair amount of time hashing over and discussing,

12
00:01:03,060 --> 00:01:08,420
because classically, in the IT management world, you're not really interested in deploying things

13
00:01:08,420 --> 00:01:13,280
extremely frequently. In fact, change is often the enemy, so this whole prospect of getting a whole

14
00:01:13,280 --> 00:01:18,260
bunch of software from the Agile world requires you to start thinking differently as far as the process

15
00:01:18,260 --> 00:01:24,100
that you use, because you're being called upon to deliver things a lot more quickly and more frequently

16
00:01:24,100 --> 00:01:31,800
and so forth and so on. And last time we left off, basically wondering, you know, now that we have these, like,

17
00:01:32,000 --> 00:01:37,140
the excellent sort of business benefits of being able to deliver more software more quickly that people

18
00:01:37,140 --> 00:01:42,680
actually like or deliver software that has value in it to call back to another Agile executive podcast with

19
00:01:42,680 --> 00:01:49,340
Jim Highsmith, then the question becomes, well, so that's like a great, you know, goal in Candyland for us all to get to,

20
00:01:49,400 --> 00:01:54,680
but how do we actually get over the rainbow and get over there from the sort of traditional and sort of

21
00:01:54,680 --> 00:02:00,900
fundamentalist IT that we might be existing in currently. And, you know, I think that's, this is always the

22
00:02:00,900 --> 00:02:07,640
question that after you have a nice little hour-long presentation of fantastic Agilism, you sort of get to the

23
00:02:07,640 --> 00:02:13,020
process of the point of, how can we do this? And I think that's one of the things that we're going to sort of

24
00:02:13,020 --> 00:02:18,760
gloss over here in this podcast and in so much as we can get into it in a half hour or so recording.

25
00:02:19,400 --> 00:02:27,280
And so to that end, after that lengthy summarization, you know, what, to throw the question out there broadly,

26
00:02:27,880 --> 00:02:33,240
once you guys have sort of had this conversation to sort of have people let you in the door, so to speak,

27
00:02:33,880 --> 00:02:41,200
and sort of want to change their organization around a little bit. Like, what are the first steps that you see groups or

28
00:02:41,200 --> 00:02:46,020
organizations getting to when they want to make IT more of an agile environment?

29
00:02:48,840 --> 00:02:55,880
Well, this is Andrew. I think that in general, that's sort of a green field.

30
00:02:55,880 --> 00:03:02,660
And that's not something that's necessarily happened or happening. That's something that I think will

31
00:03:02,660 --> 00:03:11,460
happen in the next coming years. Right now, I think that people, that there's certainly a group of

32
00:03:11,460 --> 00:03:17,760
people that are working on agile system administration. But in general, the organizations

33
00:03:17,760 --> 00:03:25,280
themselves aren't making that decision so much as people that are actually developing their

34
00:03:25,280 --> 00:03:30,760
infrastructure, developing their operations are sort of doing at a grassroots level. And I think that

35
00:03:30,760 --> 00:03:37,800
this is, this sort of speaks to the difference between early adoption and crossing the chasm and that

36
00:03:37,800 --> 00:03:44,140
whole metaphor. So there's sort of a piecemeal approach where the pieces, of course, are people,

37
00:03:44,140 --> 00:03:49,160
and they're starting to do these practices on their own rather than starting from the top, if you will.

38
00:03:50,560 --> 00:03:58,440
Well, you have, so the agile has been shown to have some success. It's also had some interesting

39
00:03:58,440 --> 00:04:03,520
implementations along the way. But there's, there's sys admins who've been exposed to these ideas,

40
00:04:03,520 --> 00:04:09,720
who are adopting agile practices in what they're, they're doing and they're exploring it. And then

41
00:04:09,720 --> 00:04:15,640
as we sort of alluded to, there's, there's also emergent best practices that are being driven by

42
00:04:15,640 --> 00:04:22,960
the sort of the scale and, and the SLAs that are involved building these large web applications.

43
00:04:22,960 --> 00:04:29,040
And, and that's sort of driving, I think the, the confluence of both of those things are, are sort of

44
00:04:29,040 --> 00:04:34,960
creating this emergent, um, what I'm calling agile infrastructure, agile operations, um, best practices.

45
00:04:34,960 --> 00:04:46,280
I would second Andrew with respect to actually an experience that I had a few years ago with agile

46
00:04:46,280 --> 00:04:56,200
development. It is not about IT management, but I think the lesson applies. Uh, I was starting an agile rollout

47
00:04:56,200 --> 00:05:05,520
and I was expecting that, uh, it will be 50-50. Namely, 50% would be bottom-up, 50% would be top-down.

48
00:05:05,520 --> 00:05:16,200
What I very quickly realized is that I only needed to do about 20% top-down and 80% came bottom-up.

49
00:05:16,200 --> 00:05:27,520
I asked one of the developer, development directors, well, why did you not, guys, why did you guys not do agile before?

50
00:05:27,520 --> 00:05:39,520
And I got the answer. Your predecessor would not allow us. So to me, the natural gravitation issues of people

51
00:05:39,520 --> 00:05:47,560
are solving the actual problems at hand. And people in the trenches, as they have, they first have knowledge

52
00:05:47,560 --> 00:05:55,020
and experience with the various problems, tend to figure out, uh, things that help solving,

53
00:05:55,420 --> 00:06:01,840
even if they don't have a full theory behind it or do not have the support from the executive level

54
00:06:01,840 --> 00:06:02,840
to make it happen.

55
00:06:03,840 --> 00:06:08,400
Yeah, that, that, that raises a, you know, an interesting question when it gets to, uh, to change management.

56
00:06:08,400 --> 00:06:13,120
And that's like looking at the, uh, looking at the operations people or the IT department

57
00:06:13,120 --> 00:06:17,060
as a whole, like what, when, when, when you're having these discussions, like what do you see

58
00:06:17,060 --> 00:06:22,020
as the, um, I don't know exactly what you'd call it, but what, what are the motivations people

59
00:06:22,020 --> 00:06:26,520
have to change or not change? Like what's motivating them to like, look at the way they do things

60
00:06:26,520 --> 00:06:30,080
and do something differently? Like what's the frame and context for that?

61
00:06:31,880 --> 00:06:37,280
Well, I think that, that's, that speaks to the human condition. And I think you, you kind

62
00:06:37,280 --> 00:06:41,280
of have to look at the culture, uh, that's built and what people are trying to deliver.

63
00:06:41,600 --> 00:06:48,380
You know, if you have a, a culture that at the top doesn't value the work that's done at the bottom,

64
00:06:48,380 --> 00:06:55,460
then that it's in my experience leads to a group of people that are, you know, just punching the

65
00:06:55,460 --> 00:07:00,720
clock, trying to get whatever they can done. Um, you know, if they're, if they're on fire all day

66
00:07:00,720 --> 00:07:05,940
and they, they keep saying, help me, help me. And they don't get any support from the organization

67
00:07:05,940 --> 00:07:11,900
to put out fires and they become less and less, um, it's sort of a learned, a learned hopelessness,

68
00:07:11,980 --> 00:07:12,820
learned helplessness situation.

69
00:07:13,820 --> 00:07:16,980
So, so their, their goal is sort of just to pass the time and get paid for it.

70
00:07:17,080 --> 00:07:22,620
Sure. And, and I have, I feel when you, so this is if you start a new job, because I've never,

71
00:07:22,880 --> 00:07:27,980
I've never really been an executive, uh, in the capacity that Israel has. I've never managed

72
00:07:27,980 --> 00:07:32,160
thousands of people. Uh, you know, I've worked on, on small teams and startups and,

73
00:07:32,160 --> 00:07:39,800
and when you start a new, uh, position in my opinion, and I'm sort of, uh, I, I, I like things

74
00:07:39,800 --> 00:07:45,300
to, to be better, whatever that means. That's sort of a nebulous thing. But when you, when you first

75
00:07:45,300 --> 00:07:51,400
come to, uh, to an organization, you sort of have a window of opportunity to, to influence the way

76
00:07:51,400 --> 00:07:57,480
things that are, are being done. And you come in and you, you analyze what's happening and you

77
00:07:57,480 --> 00:08:02,400
analyze what needs to be done and, and you can make suggestions. And, and if you have successes,

78
00:08:02,400 --> 00:08:09,020
uh, at the team level, then, then that gives you some, some social capital to, to maybe do

79
00:08:09,020 --> 00:08:14,320
something again. And if you do that, I've, I've, I've in the, in the past, and we can talk about

80
00:08:14,320 --> 00:08:21,340
some of these in specific, um, had some success managing up and having, uh, you know, relationships

81
00:08:21,340 --> 00:08:27,480
with my managers and the executives and getting some, some buy-in for, for ideas about how I wanted

82
00:08:27,480 --> 00:08:32,180
to, to change things and how I want to do things. And as you get success with that, then, then that's

83
00:08:32,180 --> 00:08:37,860
what keeps going along. And in my experience, and, and I, I'd certainly love to hear Israel's

84
00:08:37,860 --> 00:08:45,680
perspective on this. You, you generally have success, uh, with agile, when there is a, a knowledgeable,

85
00:08:45,680 --> 00:08:54,680
um, and capable sort of agile champion who can, who can make it happen. Um, not by himself or herself,

86
00:08:54,780 --> 00:09:02,260
but by, uh, by, uh, by influencing and by, um, adding ideas to the discussion and by pointing

87
00:09:02,260 --> 00:09:07,920
people to resources and, and essentially leading people to water, if, if you will, except the

88
00:09:07,920 --> 00:09:15,000
metaphor. Right, right. How about yourself, Israel? Well, I think that there are two aspects

89
00:09:15,000 --> 00:09:24,240
to it. And Andrew, you clearly highlighted one aspect, which is the know-how and, uh, you know,

90
00:09:24,240 --> 00:09:29,680
years ago, we might not have had the know-how with respect to agile, but at this point in

91
00:09:29,680 --> 00:09:38,600
time, there is, uh, a body of knowledge which is available to anyone who really wants to get

92
00:09:38,600 --> 00:09:45,100
into it. And I'm very much hoping that we should start developing, uh, this kind of know-how

93
00:09:45,100 --> 00:09:53,700
with respect to agile in IT. For example, Andrew's first coming presentation in agile 2009 in a few

94
00:09:53,700 --> 00:10:03,140
weeks. Now, the other aspect of it, which I deem to be the executive responsibility is creating

95
00:10:03,140 --> 00:10:13,720
the conditions under which the natural desire of, of folks to do better can be implemented. And I would

96
00:10:13,720 --> 00:10:25,160
say if the overall equation of what needs to happen is overly constrained, for example, it must be

97
00:10:25,160 --> 00:10:33,160
delivered in three months even if it's, it's against the rules of physics, then the executive cannot tap

98
00:10:33,160 --> 00:10:43,080
into the natural desire of folks to do better. If the executive is able to set up, uh, the overall operation

99
00:10:43,080 --> 00:10:52,520
in such a manner that they, uh, do, uh, that they do better desire, has an opportunity to spark,

100
00:10:52,520 --> 00:11:04,520
then it will. So I consider it to be a major responsibility to try to construct an environment

101
00:11:04,520 --> 00:11:13,960
within which the natural tendency of employees can add up and build on one another. And when this does

102
00:11:13,960 --> 00:11:21,400
not happen, I usually, uh, look into what I'm doing and trying to see where I am. But the desire

103
00:11:21,400 --> 00:11:27,960
to do better, I think is universal. And all you need to do is give the fertile ground in the place, uh,

104
00:11:27,960 --> 00:11:31,400
for which to really take off.

105
00:11:31,400 --> 00:11:35,400
Yeah, it's, it's interesting. I mean, there's one of the, the common threads from,

106
00:11:35,400 --> 00:11:39,400
from a small organization, like, uh, whether it's a startup or whatever, or you're, or if you're

107
00:11:39,400 --> 00:11:43,720
managing from the bottom, if you will, if you're taking a bottom-up approach like Andrew was talking

108
00:11:43,720 --> 00:11:50,120
about, and then the sort of, uh, larger organization and, and, and managing from the top or, uh, a top-down

109
00:11:50,120 --> 00:11:54,840
approach like Israel is talking about. One of the, the common thing there is to, I mean, and this is,

110
00:11:54,840 --> 00:12:00,360
this is true of change management of any type, but essentially to set yourself up for very small,

111
00:12:00,360 --> 00:12:05,400
successful wins in order to not only demonstrate that these things work, but more importantly,

112
00:12:05,400 --> 00:12:10,040
when it comes to changing the, the cultural and the people to sort of, I mean, to put it one way,

113
00:12:10,040 --> 00:12:13,720
just to sort of raise morale that things can actually get done and that this stuff is actually

114
00:12:13,720 --> 00:12:19,320
going to work and to make people happy with it. And it seems like in, in both capacities,

115
00:12:19,320 --> 00:12:24,600
there's, there's ways you can set up projects, if you will, such that you can initially have a lot

116
00:12:24,600 --> 00:12:29,080
of small successes that you can sort of bank up the credit for, if you will, to start getting

117
00:12:29,080 --> 00:12:34,520
bigger successes. But it seems like you have to build up to having larger successes either way.

118
00:12:36,120 --> 00:12:45,560
Well, I would say the art of agile, uh, in many ways is accumulating those, uh, small successes

119
00:12:46,520 --> 00:12:54,440
to add up to a much larger success. So in a way, it's a little bit like trees and forests.

120
00:12:55,400 --> 00:13:01,640
You are definitely focused on succeeding with this iteration. And then next week or the week after,

121
00:13:01,640 --> 00:13:09,000
you are focused on the succeeding with the next iteration. At the same time, you need to see all

122
00:13:09,000 --> 00:13:19,800
of those and plan for all those successes to add up in a way, uh, where the whole is bigger than the

123
00:13:19,800 --> 00:13:27,880
sum of the parts. And I would say there is a fascinating analogy here between the technical side and the

124
00:13:27,880 --> 00:13:36,520
managerial side. I believe good agile programmers are able to, while focusing on their current task,

125
00:13:37,160 --> 00:13:43,960
at the same time, to be able to keep in their head the overall layout of the land of the release.

126
00:13:44,680 --> 00:13:52,600
In a similar manner, a good manager, while celebrating each and every accomplishment,

127
00:13:53,640 --> 00:14:06,600
has, at the same time, the bigger success of the whole organization in mind, and he or she builds to us by a sequence of small successes which build one on top of the other.

128
00:14:08,440 --> 00:14:17,080
So this was a few, a few months ago, probably five, six months ago, uh, Lisa Crispin was at the, the Salt Lake City Agile roundtable.

129
00:14:17,080 --> 00:14:26,520
She was coming through town and, and she stopped in and she, she wrote a book about agile testing and, and she's, uh, got some ideas of her own.

130
00:14:26,520 --> 00:14:35,160
But, well, one of the things that she said during that roundtable that, that stuck with me, and it was something I, I knew, um, from personal experience,

131
00:14:35,160 --> 00:14:43,920
but she articulated it in a way that just really struck me, was that the, the business that she was in, that, that there was this transformation at some point,

132
00:14:43,920 --> 00:14:55,680
when, when the, the testers, um, the developers and everyone went from having their roles and, and their jobs to really understanding the business.

133
00:14:56,480 --> 00:15:02,520
And, and I think this, this sort of goes to the, and, and correct me if I'm wrong, but sort of the heart of what you're talking about,

134
00:15:02,520 --> 00:15:13,260
that if you understand this larger context and, and particularly if you have a culture where, where the testers can, can talk to the developers and, and, and make suggestions.

135
00:15:13,260 --> 00:15:20,420
And the testers, because they understand the business and because there, there's a culture of respect, they can talk to the, to the business people.

136
00:15:20,420 --> 00:15:23,060
They can talk to the, to the marketing people and the sales people.

137
00:15:23,060 --> 00:15:28,280
And they're constantly, they're not just thinking about their responsibility, does this feature pass?

138
00:15:28,520 --> 00:15:34,920
But since they're thinking about, does this application fulfill the, the, the mandate of this company?

139
00:15:35,120 --> 00:15:40,780
Are, are we going to be able to, you know, for lack of a better metaphor, make some money?

140
00:15:40,780 --> 00:15:51,780
Um, and, and, and I think that once you get a culture that everyone understands, um, not just what they're doing, uh, for their, you know, particular task of the day,

141
00:15:51,780 --> 00:16:00,680
but what the business does, why the business exists and, and kind of internalizes that in a way that they're proud of.

142
00:16:00,680 --> 00:16:05,260
And then, then I think that's, that's one of the things that, that really unlocks the, the potential.

143
00:16:05,660 --> 00:16:11,600
And, you know, this is, this is sort of, you know, obviously a, a kind of purposely naive and, and somewhat rhetorical question.

144
00:16:11,600 --> 00:16:18,620
But anytime there's these kind of basic precepts that, that I come up against, I'm always curious in, in asking the question, like, why is that important?

145
00:16:18,620 --> 00:16:28,220
And, and I think this, this issue that, you know, you get to of having, uh, whatever you want to call them, individual contributors or, or sort of individual employees,

146
00:16:28,220 --> 00:16:37,800
kind of understanding the overall business context they operate in is, uh, you know, it, it seems like something that would be, uh, that would be valuable.

147
00:16:37,800 --> 00:16:42,960
And yet for as much as people talk about achieving that, obviously it's something that doesn't really happen very often.

148
00:16:42,960 --> 00:16:46,380
It seems in, uh, in, especially in larger companies.

149
00:16:46,380 --> 00:16:53,860
And so, I mean, I'm curious, like from the both of you, like what, especially in the context of, of whether it's, you know, in the context of the IT department,

150
00:16:53,860 --> 00:17:03,920
whether you're developing software or helping deliver that software, like what value that the individuals get by sort of understanding the overall business context or the serve,

151
00:17:04,040 --> 00:17:05,760
the business stuff that they're delivering?

152
00:17:07,660 --> 00:17:15,160
Well, I think that it, it creates, if it's done properly, it creates a community of interest.

153
00:17:15,160 --> 00:17:29,620
And, and I think, and this is all just hand-waving and observation anecdotes, but if you have a culture that values that whole organism,

154
00:17:29,620 --> 00:17:38,740
that, that whole company, that whole, there's respect between every, every worldview, then, then you get a different kind of sense of pride.

155
00:17:38,740 --> 00:17:42,520
Uh, and, and, and you want to go, you want to go to work.

156
00:17:42,520 --> 00:17:54,300
And if you have a culture that, that hoards information and, and has, uh, sort of a habit of blaming, uh, the other side of the boat for, for the leak,

157
00:17:54,300 --> 00:17:59,020
then, then, then, then, then it's destructive.

158
00:17:59,020 --> 00:18:02,420
There's a, there's a book called the, the five dysfunctions of a team.

159
00:18:02,620 --> 00:18:08,900
And the, the last, the last dysfunction is, is not focusing on results.

160
00:18:09,300 --> 00:18:20,240
And, and what comes out in that is you have situations where the, the company's failing, but, but different organizations don't think it's their fault

161
00:18:20,240 --> 00:18:27,220
because they did X, we did, we did, we did great on X. Um, but it's those other guys over there in, in IT

162
00:18:27,220 --> 00:18:33,460
or those other guys over there in, in development or it's in software. It's always QA's fault, right?

163
00:18:33,460 --> 00:18:38,940
If anything's wrong, it's always QA's fault. I don't understand that mentality, but it seems to be pervasive.

164
00:18:39,080 --> 00:18:46,020
So it, it, it, it seems like, you know, what you're saying is, is, um, part of understanding the context is there,

165
00:18:46,020 --> 00:18:53,100
there, there's sort of another step in there and that's sort of, uh, wanting to care about being successful at the larger context

166
00:18:53,100 --> 00:18:55,620
or the larger business that, service that you're delivering.

167
00:18:56,180 --> 00:19:02,340
And so if you actually care about, if you up, if you up your caring beyond your individual role, so to speak,

168
00:19:02,820 --> 00:19:08,800
and you're more concerned as, that IT's doing their job to the overall company, you know, using IT to help support

169
00:19:08,800 --> 00:19:14,880
whatever business the company organization is doing, then even though something may not directly be your responsibility

170
00:19:14,880 --> 00:19:20,880
or it may be easy for you to sort of like slack off, essentially, you'll be more likely to make sure

171
00:19:20,880 --> 00:19:25,080
that IT is doing their job at, you know, at, at a, at a quality level, if you will.

172
00:19:25,200 --> 00:19:30,860
And then ideally what that means is that there's less leaks in the boat or when leaks occur, as they so often do,

173
00:19:30,960 --> 00:19:36,160
they get fixed a lot faster because you spend a lot less time worrying about whose job it is to fix the leak

174
00:19:36,160 --> 00:19:37,360
and you just go and fix it.

175
00:19:38,020 --> 00:19:38,220
Right.

176
00:19:38,820 --> 00:19:45,340
I think, uh, this is, this is borrowing from Alistair Coburn, um, but there, there is only us.

177
00:19:45,780 --> 00:19:51,340
If, if you can create a culture where everyone, everyone believes there's only us

178
00:19:51,340 --> 00:19:57,380
and it's not developers and IT and QA and, and sales and marketing or whatever,

179
00:19:57,680 --> 00:20:03,560
then you, you can do a lot of things that you can't think about if everyone's worried about covering their,

180
00:20:03,560 --> 00:20:06,140
their proverbial donkey all the time.

181
00:20:06,160 --> 00:20:07,260
That's right.

182
00:20:08,020 --> 00:20:11,200
Oh, let me ask you a question, uh, Andrea.

183
00:20:11,840 --> 00:20:17,520
Uh, like you, I am very, very fond of Alistair's, uh, quick, there is only us.

184
00:20:18,960 --> 00:20:29,780
I can, however, interpret it in two possible ways and maybe both, uh, uh, you know, both are appropriate and that's where I would like to have, uh, uh, your own good counsel.

185
00:20:30,780 --> 00:20:40,540
One thing is that in terms of the resources that are available to carry out a certain task, there are, there is only us.

186
00:20:41,820 --> 00:20:55,520
Another interpretation is that it's not a matter of I doing this task, you doing that task, what I'm doing another task, but that there is a business of us as a team doing things together.

187
00:20:56,680 --> 00:21:12,800
I would, I would say, and, and I don't want to put words in Alistair's mouth because, yeah, God help us.

188
00:21:13,060 --> 00:21:21,140
But I would say it's the latter, uh, that there, that the, the, the sense of unity more than the sense of the limits of our resources.

189
00:21:22,660 --> 00:21:44,820
Well, you know, this is fascinating as in my practice, usually I watch for one indicator, which tells me that the R&D director or vice president with which I, to whom I consult, reached a certain level of comfort with me.

190
00:21:45,060 --> 00:22:06,500
And this is when he or she usually says, after we talked about in introductory meetings, after we talked about millions of things related to the do it this way and the do it that way, et cetera, when he or she says, we need to have more, uh, appreciation of each other here.

191
00:22:07,200 --> 00:22:22,800
And when I dig a little bit into, uh, this kind of thing, usually the true story about the dynamics between professional services and sales and customer support and engineering come, uh, come out loud and clear.

192
00:22:23,300 --> 00:22:32,400
And then it's relatively, once you get that, it's relatively easy to start working on the right model of governance for this kind of environment.

193
00:22:32,980 --> 00:22:45,780
But to me, what I have found, as long as we are talking about the technical aspects of agile in one fashion or another, the conversation is usually not deep enough.

194
00:22:46,320 --> 00:22:55,480
It's when the person on the client side says, well, and we need to be able to appreciate each other better here when we get into the root of the problem.

195
00:22:58,760 --> 00:23:18,280
Yeah, you know, I mean, this discussion makes me think of another sort of, uh, change conflict issue, if you will, in the sense that there's, uh, no, no, no matter what you're doing in, in IT, if you're developing software or delivering it or whatever, there's, there's certain roles that are defined by the technologies that you're using.

196
00:23:18,280 --> 00:23:33,100
You know, if, if you're in the process that you're using, like if you're, if you're doing, if you're a tester doing the QA stuff versus someone developing the software versus a system administrator or a DBA sort of taking care of the technology in a running state, there's definitely skill sets involved.

197
00:23:33,360 --> 00:23:46,780
And it seems like, well, it's more than it seems like the organizational structure that we have to take care of that is to assign people is to make someone's role into what their job is, which translates into what their identity is within a company.

198
00:23:47,020 --> 00:23:55,560
And then everything, of course, when it comes to, uh, compensation and all sorts of things gets tied to what your, uh, your job is, what your sort of identity is.

199
00:23:55,820 --> 00:24:02,620
And yet for, you know, you know, taking the, the sort of extreme version of the metaphor, there's no, you know, there's only us or whatever.

200
00:24:02,900 --> 00:24:12,120
You start to get this conflict where it seems like the, uh, the organization wants very much so there to be individuals instead of us's people who aren't interchangeable.

201
00:24:12,420 --> 00:24:15,020
You know, you don't, you don't want people to be interchangeable necessarily.

202
00:24:15,340 --> 00:24:17,420
They're very specific in what they do.

203
00:24:17,720 --> 00:24:19,420
They're a specific type of cause.

204
00:24:19,700 --> 00:24:30,320
And so I wonder when, uh, you know, when, when you guys are thinking about or when you've seen IT departments sort of trying to get into this more fluid us state, if you will,

205
00:24:30,320 --> 00:24:35,740
like how they can cope with the more static nature of jobs and roles that companies typically have.

206
00:24:37,540 --> 00:25:00,300
Well, I, uh, I, uh, I don't necessarily want to throw too big of a monkey wrench in the middle of this, but I think one of the things that is, is often, uh, neglected in discussions about implementing agile or implementing technology in general is, and, and, and while you want to create a culture, uh, of us,

207
00:25:00,320 --> 00:25:10,220
there, there, there, there is, uh, a potential for, uh, what's, what's, what's the right word? Incompetence in, in every level of your organization.

208
00:25:10,920 --> 00:25:32,340
And if you don't create a culture that, well, on one, on one hand, you want to have a culture of tolerance and a culture of trust and a culture of respect at some level, you need a way to, uh, eliminate certain, certain people, uh, from that circle of us, um, circle of trust.

209
00:25:32,340 --> 00:25:41,000
And, and, and I'm not sure how, I, I've, I've, I've never seen people do that very well.

210
00:25:41,080 --> 00:25:47,720
It always seems to be, uh, clumsy and bloody and you end up carrying, uh, some people along too, too much.

211
00:25:47,720 --> 00:25:50,500
And, and that's, that's, that's a drain and it's bad for morale.

212
00:25:51,260 --> 00:25:53,260
And yeah, I don't know.

213
00:25:53,540 --> 00:25:57,320
I'd, I'd like to hear your thoughts on that type of topic, Israel.

214
00:25:58,200 --> 00:26:06,660
Well, I think in every one of us, there is a tremendous urge, desire to belong.

215
00:26:07,520 --> 00:26:27,160
And the phenomenon that he described, namely, who is us and who is not us, uh, and the reason that sometimes we carry people, uh, longer than, uh, perhaps we should have, I think it's because at a certain level, we all have this as a universal urge in us.

216
00:26:27,160 --> 00:26:28,560
We want to belong, we want to belong.

217
00:26:29,220 --> 00:26:50,720
I caught a talk a little bit, uh, earlier about the identity and I think particularly to people in our profession, namely software engineers, uh, a big part of our identity is really tied into what we do and the groups that, uh, you know, we belong to.

218
00:26:50,720 --> 00:27:11,240
So, for example, not all of my identity, but part of my identity at this point in time is agile and the fact that I am accepted by, uh, various people, uh, as, uh, you know, as an agileist means, uh, means a lot to me.

219
00:27:11,940 --> 00:27:25,940
So, uh, so, who, uh, belongs and who does not belong is something that, uh, you know, by the nature of the strong desire is always, as you called it, bloody.

220
00:27:26,500 --> 00:27:34,820
It's not, uh, you know, it's not something that is easy to define a line and to execute to it.

221
00:27:35,600 --> 00:27:37,000
Does it make sense to you?

222
00:27:37,560 --> 00:27:38,620
I think so.

223
00:27:38,780 --> 00:27:41,860
I'm going to, I'm going to further, uh, take us off course here.

224
00:27:41,940 --> 00:27:58,100
The, uh, have you guys seen some of the, there's an article, uh, that came out about how, uh, we as humans, we, we prefer essentially confidence, uh, to, to actual competence in, in many cases.

225
00:27:58,580 --> 00:27:59,400
Oh, yeah.

226
00:28:00,000 --> 00:28:00,440
That's it.

227
00:28:00,520 --> 00:28:02,780
It's like preferring sugar to whole wheat bread.

228
00:28:03,420 --> 00:28:03,640
Yeah.

229
00:28:04,660 --> 00:28:05,400
I don't know.

230
00:28:05,400 --> 00:28:11,920
It's been passed around on Twitter for a while, but this article came out that said that in, in general, we'll put our faith,

231
00:28:11,940 --> 00:28:15,280
in our trust in, in someone with a lot of competent or confidence.

232
00:28:15,840 --> 00:28:27,720
Um, and I think in, in some cases it's because we don't have a, a way to measure, uh, competence, but we can clearly, you know, on a psychological sort of intuitive level, we can, we can tap into confidence.

233
00:28:28,080 --> 00:28:28,600
Right.

234
00:28:28,600 --> 00:28:36,400
And you, and then you, you kind of cross the implications of that with, with something like the, the Dunning-Kruger effect.

235
00:28:36,540 --> 00:28:38,640
Are, are you familiar with the Dunning-Kruger effect?

236
00:28:39,200 --> 00:28:40,320
Not that I remember.

237
00:28:40,560 --> 00:28:41,120
What is it?

238
00:28:41,760 --> 00:28:45,720
So, so the Dunning-Kruger effect is a, it's a cognitive bias.

239
00:28:46,300 --> 00:28:54,880
And basically it says that, that people, uh, incompetent people will reach erroneous conclusions and make unfortunate choices.

240
00:28:54,880 --> 00:29:00,580
Uh, but their incompetence robs them of the, uh, metacognitive ability to realize it.

241
00:29:01,580 --> 00:29:02,260
Okay.

242
00:29:02,260 --> 00:29:07,640
Uh, incompetent individuals tend to overestimate their own level of skill.

243
00:29:08,100 --> 00:29:13,160
Uh, they tend to fail to recognize genuine skill in others.

244
00:29:14,280 --> 00:29:21,300
They, they fail to, yeah, it's, uh, you can, you're, you're basically not smart enough to realize you're not smart enough.

245
00:29:22,380 --> 00:29:22,980
Exactly.

246
00:29:24,300 --> 00:29:28,660
Which is, it's a, it's a, that's a, uh, that's a terribly recursive condition to be in.

247
00:29:29,140 --> 00:29:39,260
But, but I think you have, uh, a situation in, in IT, uh, and in, in software development and in agile where, where people have, have confidence.

248
00:29:40,600 --> 00:29:46,020
And, and they can certainly do some things, but they don't necessarily have a high level of competence.

249
00:29:46,720 --> 00:29:51,080
And they don't, and they don't have, uh, proper feedback to, to recognize that.

250
00:29:51,120 --> 00:30:00,000
And this is a metaphor that you might not understand this metaphor, Israel, but hopefully someone, all two of you that are listening to this podcast are, are young enough.

251
00:30:00,000 --> 00:30:03,980
And, and maybe, uh, I don't know, geeky enough to, to understand this reference.

252
00:30:03,980 --> 00:30:11,720
But there's, uh, people play video games and, and you play a game like, this is a, maybe dating myself, but you play a game like StarCraft.

253
00:30:11,980 --> 00:30:15,540
And you, and you play this game and, and you think you're good.

254
00:30:15,740 --> 00:30:19,540
And then you, you know, you play with all your buddies and, and you're the best one.

255
00:30:19,760 --> 00:30:26,640
And then you go on online and you play on Battle.net and there's 14 year olds that play this game 24 hours a day and they'll destroy you.

256
00:30:27,520 --> 00:30:34,140
And, and I think in, in a lot of IT organizations, you have someone who's sort of the, the expert, the best one.

257
00:30:34,220 --> 00:30:37,720
They've been there forever and, and they're not necessarily pushed to learn.

258
00:30:37,720 --> 00:30:41,520
They, they're, they're the best one on, you know, in their neighborhood.

259
00:30:41,840 --> 00:30:52,480
They play in the, you know, the, the game at a certain level, but because they're not exposed to how that game could be played on a higher level, they never really get any better.

260
00:30:53,580 --> 00:30:54,020
Right.

261
00:30:54,100 --> 00:30:56,880
They don't have very effective benchmarking for rating their skills.

262
00:30:56,880 --> 00:31:07,520
Even if you have, even if you have something like, you know, in, in, uh, in a lot of agile sort of processes, if you will, and, and in other processes to be fair, but agile has a,

263
00:31:07,520 --> 00:31:17,780
has a particularly an emphasis on faster feedback cycles, meaning that hopefully you find out faster that you're doing well or you're doing poorly a lot faster than you would in a longer iteration.

264
00:31:17,780 --> 00:31:26,000
So in theory, you should have more data that sort of allows you to make a judgment about the, uh, uh, the success or failure of whatever you're doing.

265
00:31:26,140 --> 00:31:27,920
But now that's definitely, definitely.

266
00:31:28,040 --> 00:31:32,040
If you, but if you're staying in the basement with your guys, that's right.

267
00:31:32,080 --> 00:31:36,000
If you're in the confines of your own organization, you have nothing to compare it to except yourself.

268
00:31:36,200 --> 00:31:46,460
So all, you know, is basically percentages, you know, if you're doing better or worse, but you don't know, like if you're doing, you don't know how it, what, what your rating is versus everyone else in the world necessarily.

269
00:31:47,060 --> 00:31:49,320
I can't remember where I can't remember where I first heard this.

270
00:31:49,320 --> 00:31:56,220
And obviously it's more complicated situation than, than being able to actually implement this every time.

271
00:31:56,220 --> 00:32:03,460
But there's a saying that if you're the, if you're the smartest one in your, in your IT organization, it's time to look for a new job.

272
00:32:05,460 --> 00:32:17,780
You know, Michael Ma, who is an associate and a wonderful metaphor about measuring, uh, software performance metrics.

273
00:32:18,560 --> 00:32:22,100
He basically says, look, it's like riding in an elevator.

274
00:32:22,940 --> 00:32:32,960
When you are in the elevator, you know, of course, uh, what the other folks are in the elevators, in the elevator are doing, and towards what floor you are heading.

275
00:32:33,820 --> 00:32:43,080
However, you have no idea whatsoever about who is in the other elevators in the building and what they are doing and where they are heading.

276
00:32:43,920 --> 00:32:58,280
It's only when you step out of your own elevator and look, look at the dashboard indicating where the various elevators are, that you start getting a sense of what you are doing versus what other folks are doing.

277
00:32:59,380 --> 00:33:13,900
And his, uh, metaphor is about software benchmarking, namely the fact that I or my team or we think that we are doing things greatly, uh, we are doing great things.

278
00:33:14,200 --> 00:33:28,340
Well, to itself, uh, maybe it's a confidence, but it's not really meaningful unless you compare it to other folks who are doing software in a similar field.

279
00:33:28,880 --> 00:33:42,840
And my own experience at BMC at the time when we did the study with Michael was that the data that he provided us against industry norms was of immense importance

280
00:33:42,840 --> 00:33:58,480
in terms of our understanding of what we do well, what we do not do so well, and what are some of the things that we can derive out of comparing to a much broader context than our own development show.

281
00:33:59,120 --> 00:34:20,660
Going back to Andrew's metaphor about the person who plays our video games very, very well, I think the metaphor holds up to a point, namely, we have data coming at us, not necessarily from within our own development team or our own IT team,

282
00:34:21,180 --> 00:34:33,460
but from things that happen in the world, it's a little bit more, I believe, like a chess player, I get additional data, and I analyze it by looking at the games of the greats,

283
00:34:33,460 --> 00:34:52,540
looking at new games that just have been published, looking at analysis, and in the technology area, this is basically the technology trends that get added, and had better be added, to what we are doing on an ongoing basis.

284
00:34:54,220 --> 00:35:07,560
I think, I agree with you to an extent, in the sense that you need data that's coming from outside, I think that there's other avenues where you can get information,

285
00:35:07,840 --> 00:35:15,300
and it's not necessarily pure numbers, it's not necessarily pure data, but for example, if you are a developer in 2009,

286
00:35:15,300 --> 00:35:26,300
there is a lot of information available on blogs, on mailing lists, on IRC channels, on Twitter, and getting involved in those discussions,

287
00:35:26,820 --> 00:35:39,040
if you're being honest with yourself, and you haven't got a case of Dunning-Kruger, then you can quickly assess where your deficiencies are relative to these discussions,

288
00:35:39,920 --> 00:35:51,840
and I think maybe, in a roundabout way, this is what I'm getting at, that at the heart of Agile, whether you're talking about IT, or development, or applying it to business process,

289
00:35:51,840 --> 00:36:05,200
or anything else, in my mind, the secret sauce is being able to reflect and adapt, and if you can't get to a level where you have some self-awareness of your deficiencies,

290
00:36:05,200 --> 00:36:10,500
and you're being honest, and you can get rid of whatever self-deceptions you might have,

291
00:36:10,840 --> 00:36:17,600
then it's very, very difficult for you to adapt in a meaningful way, or reflect for that matter.

292
00:36:18,780 --> 00:36:27,460
And I think this ties nicely into the business of the confidence versus competence that you mentioned a few minutes ago, Andrew.

293
00:36:27,460 --> 00:36:42,300
So, to me, the confidence or the environment within which a confidence can flourish and the people feel safe is a major executive responsibility.

294
00:36:43,080 --> 00:36:51,780
Namely, at the point in time in which I can get criticism, constructive criticism from my peers or from a blog, etc.,

295
00:36:51,780 --> 00:36:56,380
and say, "Well, I'm actually not too good at doing X, Y, Z,"

296
00:36:56,380 --> 00:37:03,720
then the impediments to progress, you know, are taking out of the way.

297
00:37:03,720 --> 00:37:15,340
It's when I am feeling insecure, and extremely worried that Andrew would outshine me, or Coté would do a better job than me, etc.,

298
00:37:15,340 --> 00:37:17,940
and I refuse to admit it.

299
00:37:17,940 --> 00:37:27,880
This is when I stop developing as an individual, and the team does not move forward towards there is only us."

300
00:37:27,880 --> 00:37:30,480
So, I will agree.

301
00:37:30,480 --> 00:37:33,480
I think that's a great summary.

302
00:37:33,480 --> 00:37:36,480
Well, with that, we should wrap up this episode.

303
00:37:36,480 --> 00:37:42,520
I think we've actually hit upon some interesting things that sort of, like, dips beyond, as I always like to do,

304
00:37:42,520 --> 00:37:48,540
sort of dips beyond the motherhood and apple pie statements, like, "We've got to change," and "Change is good," and so forth and so on.

305
00:37:48,540 --> 00:37:54,480
There's some nice, meaty things to latch on here when you're sort of trying to tackle these problems.

306
00:37:54,480 --> 00:38:00,080
So maybe next time, we'll talk about things that are more technical.

307
00:38:00,080 --> 00:38:02,080
That's right.

308
00:38:02,080 --> 00:38:06,080
Well, you've always got to lay the foundation for technical things, right?

309
00:38:06,080 --> 00:38:14,080
But maybe that is, like, the open question is, like, what, you know, this being in the realm of technology, of course.

310
00:38:14,080 --> 00:38:21,080
Like, what are the technologies that, once you have the sort of, like, confidence and skills and you're thinking about us instead of me and everything,

311
00:38:21,080 --> 00:38:24,680
like, how is it that we can use technology to make that even better?

312
00:38:24,680 --> 00:38:28,680
Because otherwise, we might as well just be, you know, working with a bunch of rocks and sticks and everything.

313
00:38:28,680 --> 00:38:32,680
You can navel-gaze about anything, Coté.

314
00:38:32,680 --> 00:38:33,680
That's right.

315
00:38:33,680 --> 00:38:36,680
Usually people have a navel, so it's always handy.

316
00:38:36,680 --> 00:38:41,680
So on that note, unless you guys wanted to add anything else, I think we might as well wrap up.

317
00:38:41,680 --> 00:38:51,520
I'll just add one little note that I think that there's – people say that it's dangerous to go meta, and certainly that's not Alistair Coburn.

318
00:38:51,520 --> 00:38:58,980
But I think that meta is only good if you can bring something back, if you can bring something that changes your behavior.

319
00:38:59,320 --> 00:39:05,840
So I think that on some level, what we just walked through was a lot of sort of meta-analysis.

320
00:39:06,840 --> 00:39:16,760
But if you can't bring that into the concrete practices and behavior, then it's just – that's where you get the pejorative navel-gazing.

321
00:39:17,420 --> 00:39:25,000
And let's do the meta, or bring the meta to the pragmatic, the topic of our next podcast.

322
00:39:26,800 --> 00:39:28,040
That sounds good to me.

323
00:39:28,260 --> 00:39:31,380
Well, with that, thanks, everyone, for listening, and we'll see you next time.