1
00:00:00,000 --> 00:00:05,320
Well, hello, everybody. It's the 14th of July, 2009. And this is the Agile Executive Podcast

2
00:00:05,320 --> 00:00:11,820
number four, I think. But I could be wrong. Who knows? So last episode, as avid listeners,

3
00:00:12,000 --> 00:00:16,360
and I'm sure there's at least two or three of them may recall, Israel and I were like outside

4
00:00:16,360 --> 00:00:20,480
of a little coffee shop here in Austin. And we got to one of the topics we got to talking about

5
00:00:20,480 --> 00:00:28,020
was essentially the mixture of sort of agile software development or agile in general,

6
00:00:28,020 --> 00:00:34,040
sort of moving more into the IT world and a little bit of vice versa. And now, so this is

7
00:00:34,040 --> 00:00:39,460
obviously this is Michael Coté talking and Israel Gad is also on here. But I thought it would be nice

8
00:00:39,460 --> 00:00:43,480
to bring along one of the people that we mentioned in that podcast and someone that both of us have

9
00:00:43,480 --> 00:00:48,620
talked to on this topic who is, well, why don't we just let him introduce himself? Why don't you

10
00:00:48,620 --> 00:00:54,660
introduce yourself? This is Andrew Schaefer with Reductive Labs. We're the people behind Puppet,

11
00:00:54,660 --> 00:01:01,120
but I'm also deeply interested in agile software techniques, agile infrastructure, agile ops,

12
00:01:01,220 --> 00:01:03,840
and how businesses can deliver more value.

13
00:01:04,520 --> 00:01:09,440
And so a couple of days ago, Israel gave like a little teaser of what we're going to talk about

14
00:01:09,440 --> 00:01:14,540
today. But for the listeners, do you want to kind of give us a little summary of kind of the

15
00:01:14,540 --> 00:01:18,040
sort of loose idea we were thinking about in that teaser post, Israel?

16
00:01:18,680 --> 00:01:27,820
I will be glad to. We were thinking in terms of what stands between agile and IT. Namely,

17
00:01:27,980 --> 00:01:37,240
traditionally, we apply agile in software development. And the results have been so promising that

18
00:01:37,240 --> 00:01:44,820
various authorities, for example, Dean Leffingwell, started talking about applying it to other

19
00:01:44,820 --> 00:01:53,400
knowledge work. One of the adjacencies of agile is, of course, the business of deployment.

20
00:01:54,120 --> 00:02:01,080
Namely, you can do agile very, very quickly and then lose all the time with the software being on the

21
00:02:01,080 --> 00:02:09,100
shelf if your deployment is not speedy. If you are able to develop quickly and to deploy quickly,

22
00:02:09,980 --> 00:02:20,620
the advantages are compounded. And they are compounded on quite a few dimensions. We are talking about time

23
00:02:20,620 --> 00:02:29,500
to value being much shorter. We are talking about making various decisions in terms of actual customer

24
00:02:29,500 --> 00:02:38,800
feedback rather than hypothesized customer feedback. And we are talking about the combination of

25
00:02:38,800 --> 00:02:47,060
developed software and deployed software in efficient manner as being a low-cost input in the overall

26
00:02:47,060 --> 00:02:55,120
economics. So this is a subject that has been intriguing me for some time now. And I'm very,

27
00:02:55,260 --> 00:02:56,500
very happy to dig into it.

28
00:02:56,760 --> 00:03:03,060
Yeah. And, you know, I think when we were talking about it back at the cafe there, you know, we were

29
00:03:03,060 --> 00:03:08,520
kind of digging into kind of like what that looks like as far as some examples we could think of. And I

30
00:03:08,520 --> 00:03:14,860
remember I was cooking up some kooky example of what having essentially to narrow down to one thing,

31
00:03:14,960 --> 00:03:20,380
being able to deploy things much more quickly on a daily if not sort of multi or within a daily basis to

32
00:03:20,380 --> 00:03:27,540
be very extreme about it. And, you know, I think the interesting thing, you know, that kind of Andrew can bring to this

33
00:03:27,540 --> 00:03:33,560
discussion is, you know, his work at Reductive Labs and just thinking about the topic in general.

34
00:03:33,960 --> 00:03:39,400
There's a lot of these sorts of things of like what exactly this, to use the phrase for it here, what this sort of more

35
00:03:39,400 --> 00:03:46,300
agile like operations or IT sort of looks like and kind of examples of people using it to their benefit.

36
00:03:46,540 --> 00:03:52,840
And with that sort of layup there, I mean, where do you see agile and IT kind of coming together in your

37
00:03:52,840 --> 00:03:53,360
world, Andrew?

38
00:03:54,060 --> 00:04:00,740
So let me start by commenting on what Israel just said. And I think in my mind, this idea of agile

39
00:04:00,740 --> 00:04:07,200
infrastructure and agile operations is much larger than just deployment. And hopefully we'll explore that

40
00:04:07,200 --> 00:04:13,980
through the, you know, either this podcast or in the future. But in general, your traditional

41
00:04:13,980 --> 00:04:23,160
operations has built up a resistance to change. Change causes outages and operations wears pagers

42
00:04:23,160 --> 00:04:30,560
and they don't really like waking up and putting out fires. So they tend to adopt heavyweight

43
00:04:30,560 --> 00:04:37,220
processes to essentially slow the change and protect themselves from their own organization.

44
00:04:38,140 --> 00:04:45,840
But the fact is that change happens. Change has to happen. Change is what enables the business. You might as well

45
00:04:45,840 --> 00:04:50,720
embrace it. You might as well enable it. But you want to mitigate your risks as much as you can.

46
00:04:51,560 --> 00:04:59,900
And in general, if you think about agile, I break agile into sort of two piles. I break it into a pile of sort of

47
00:05:00,320 --> 00:05:17,240
engineering and process techniques and then a pile of engineering techniques. And in the engineering pile, the basis of every agile technique in my mind is being able to build your application from source.

48
00:05:18,200 --> 00:05:27,380
So you can't talk about anything else, test driven development, version control, all that stuff. Well, version control, I guess, is sort of a baseline. But you need to be

49
00:05:27,380 --> 00:05:56,200
able to build from source before you can rebuild their servers from scratch. But not very many people can rebuild their servers from scratch. If you go through most organizations and look at every server, which, you know, ostensibly these are serving business critical applications, if you just threw that server out the window or blew up that part of the building,

50
00:05:56,200 --> 00:06:15,580
everything, then how fast can you get those services back online? And I think that's sort of the fundamental question is, if you can't rebuild your servers, your services from scratch in an automated way, then you can't really talk about being agile in ops, in my opinion.

51
00:06:15,920 --> 00:06:26,180
And I think just to make sure that, you know, to focus on this, there's, there's a little bit of like a leap that you made there between development and operations. And that's sort of the kind of the way

52
00:06:26,180 --> 00:06:56,160
you put it in a recent post was to look at your infrastructure as, as your application, essentially, or as part of or an application. And then, you know, when you start to think of the servers and the middleware and all that junk, essentially, as part of your application, rather than the thing you run your application on, then it starts to become more natural to think about how do we build that part of the application from source, if you will. And so the source may not be like the source code for the operating system and all of drivers and all this business. But the point being that,

53
00:06:56,160 --> 00:07:08,680
you, you have control over as, you have control over as, as sort of, I don't know, as hopefully as quickly and hopefully as easily as you can sort of build your application, you can also build the infrastructure that is part of that application, if you will.

54
00:07:09,160 --> 00:07:38,640
Exactly. And to be clear, you know, participating in this and watching this, I feel like this is essentially being driven by web operations. And one thing that becomes, if your application is a web application, if that's the business, if the business centers on a web application, what you've essentially done is you've, you've traded all the headaches that you had, you know, trying to make sure that this application would run on every version of Windows and Linux and Mac or whatever.

55
00:07:39,140 --> 00:07:53,920
And giving yourself some operations issues that you have to keep up. So at the end of the day, if you don't have the infrastructure, you don't have an application. It doesn't matter how good your idea is, how good your source code is.

56
00:07:54,140 --> 00:08:13,480
If you don't have an application. So you have to kind of abandon some of these ideas. And this is something that in some agile thoughts, it just, it kind of gets to me, but you have this idea of a non-functional requirement. Is anyone familiar with this term?

57
00:08:13,480 --> 00:08:30,720
Sure. It's sort of like the bane of sort of product management and agile for all sides, because there's always people who want, I remember like one infamous thing, which there was some team I was on and we wanted to upgrade the JVM, the Java runtime.

58
00:08:30,720 --> 00:08:48,160
And it was, it was kind of difficult to figure out how to position that correctly and sort of like, you know, the motivation for getting an agile, like requirement in, because it was essentially a non-functional sort of thing that didn't have like direct or obvious or intuitive sort of user impact, if you will.

59
00:08:48,720 --> 00:08:51,160
But, uh, so yes, at least I'm pretty familiar with that.

60
00:08:51,780 --> 00:09:02,560
So in general, my opinion of that perspective is that on one level you're looking at, okay, we have business value, we deliver to the customer, we can charge them X amount of dollars.

61
00:09:02,560 --> 00:09:09,520
On the other hand, you have a whole bunch of stuff that you just kind of don't do that ends up costing your team tons of time and money.

62
00:09:10,420 --> 00:09:23,420
And I think on some level rejecting this notion of a non-functional requirement, because in my opinion, a lot of these go right to ops, they go right to things that make developers and operations lives a lot easier.

63
00:09:24,140 --> 00:09:30,880
And, and some of them, and the majority of them, if you don't fulfill those requirements, then your application is non-functional.

64
00:09:31,420 --> 00:09:34,560
So that's why I think they call them non-functional requirements.

65
00:09:34,560 --> 00:09:41,600
I would actually like to take your good point and make one additional step with it, if I may.

66
00:09:41,860 --> 00:09:44,280
And tell me if I'm putting words in your mouth, please.

67
00:09:45,220 --> 00:09:50,640
To me, uh, one can run in one of two modes.

68
00:09:51,400 --> 00:10:00,400
The one mode is when you have 10 or 20 or 50 or 100 versions of your software for your top customers.

69
00:10:00,680 --> 00:10:09,300
So you make a special one for top customer number one, and it's another special for top customer number two, and so on and so forth.

70
00:10:10,080 --> 00:10:20,260
So what happens, sooner or later, you have produced, let's say, 100 versions of your application and of your infrastructure.

71
00:10:21,200 --> 00:10:29,960
And you are stuck maintaining all those, and usually when you branch of a branch, you start getting into big trouble,

72
00:10:30,780 --> 00:10:33,720
or trying to get back into the trunk of the code.

73
00:10:34,700 --> 00:10:45,300
In contrast, in web applications, the way you relate to them, we might have produced 100 versions of the software and the infrastructure.

74
00:10:45,960 --> 00:10:51,140
However, at any point in time, only one version rebates.

75
00:10:51,480 --> 00:10:58,500
So rather than having all those specialized versions, each for every top customer,

76
00:10:59,460 --> 00:11:11,880
instead we have everything merge immediately into the trunk and serve as, so to speak, the single source of truth in terms of what we are running.

77
00:11:11,880 --> 00:11:22,380
So the benefits in terms of maintenance, in terms of currency, in terms of responsiveness, to me are immense.

78
00:11:23,380 --> 00:11:23,980
Sure.

79
00:11:24,980 --> 00:11:34,420
Just to be clear, there's a conference called Velocity Conference, which in my opinion is sort of at the forefront of what is the emergent practices,

80
00:11:34,620 --> 00:11:42,420
the emergent ops practices that are sort of on the verge of where XP was for programming 10 years ago, in the late 90s.

81
00:11:43,500 --> 00:11:47,620
And all those talks, or a majority of those talks are online.

82
00:11:47,740 --> 00:11:50,300
You can get them on Blip TV.

83
00:11:50,500 --> 00:11:51,520
Just search for Velocity Conference.

84
00:11:51,620 --> 00:11:52,940
So I'm sure Codec could put the link up.

85
00:11:53,300 --> 00:12:00,360
But one of the things that John Alspaugh said in his talk about dev and ops cooperation at Flickr was always ship trunk,

86
00:12:01,360 --> 00:12:03,680
which is essentially echoing what you just said.

87
00:12:05,120 --> 00:12:08,400
Well, I wasn't actually aware of that.

88
00:12:08,400 --> 00:12:15,720
I have seen the slides that John has presented, but I have not had the opportunity to listen to his live recording.

89
00:12:16,560 --> 00:12:20,840
To me, it's, you know, a wonderful confirmation.

90
00:12:21,760 --> 00:12:27,960
Obviously, the data that he is using is completely independent of the data and experiences that I use.

91
00:12:28,820 --> 00:12:35,200
And yet, completely independently, we reached identical conclusion, what you call always ship trunk.

92
00:12:37,900 --> 00:12:43,020
Well, they had a – their focus of that talk was the operations and dev cooperation.

93
00:12:43,920 --> 00:12:50,680
And they're advocating that you always ship trunk and that you have a shared version control between your dev and your ops team.

94
00:12:51,580 --> 00:12:55,560
And that allows you to communicate and everyone always knows where to look.

95
00:12:55,620 --> 00:13:06,800
If you have a bunch of branches and you're managing multiple branches, anyone who's been deeply into the development process knows that that can be a bit of a headache sorting things out and knowing, you know,

96
00:13:06,800 --> 00:13:17,960
okay, well, I made this change in this branch to get into this other branch and it's just a bit of, you know, code accounting that becomes overhead and unnecessary in a web app.

97
00:13:18,020 --> 00:13:26,360
And what they do at Flickr and what sort of other people advocate is that you – instead of branching, you protect –

98
00:13:26,360 --> 00:13:31,100
you basically put branches in the code that allow you to turn features off and on.

99
00:13:31,860 --> 00:13:41,460
And that further allows you to protect yourself when you have a deployment that's causing problems with the infrastructure, you know, because of bad SQL or whatever.

100
00:13:41,560 --> 00:13:42,600
You can turn off features.

101
00:13:43,320 --> 00:13:49,740
So it gives you knobs to control the impact of your deploys until you can get those sorted.

102
00:13:50,740 --> 00:14:00,520
Well, you know, along those lines and also the sort of, like, IT developer culture conflicts that we were kind of alluding to earlier.

103
00:14:01,060 --> 00:14:12,620
And I'm curious, like, you know, definitely, like you're saying, like this year at Velocity, you kind of saw a lot of how web companies are bumping up against and doing this sort of thing.

104
00:14:12,660 --> 00:14:16,960
And there's always, like, the granddaddy example of Flickr with their five releases a day or whatnot.

105
00:14:17,380 --> 00:14:26,960
And, you know, a lot of the cases I see of people doing this are, to your point, are sort of consumer-based public web companies.

106
00:14:27,100 --> 00:14:32,900
And I'm curious when these ideas – and I've kind of been curious about this since I've heard about this sort of stuff.

107
00:14:33,000 --> 00:14:40,780
Like, how these ideas spread to sort of the rest of the IT world, you know, whether it's just, like, boring enterprise stuff or business stuff or whatever.

108
00:14:41,000 --> 00:14:42,920
Or, I don't know, maybe they don't or something.

109
00:14:43,120 --> 00:14:51,920
And I'm curious if – like, what examples you guys have encountered as far as, like, just, like, the humdrum IT department is doing this kind of stuff?

110
00:14:52,720 --> 00:14:59,600
So, just like I mentioned a minute ago that I feel like the, you know, the ideas and the people are participating in things like the Velocity Conf.

111
00:14:59,640 --> 00:15:04,200
And there's some discussions and groups that are also moving things forward.

112
00:15:04,360 --> 00:15:11,360
But, in general, just like, you know, XP, people said they're doing XP or they're hiring XP 10 years ago.

113
00:15:11,860 --> 00:15:20,480
The kind of osmotic distribution of those types of practices has been underwhelming, in my opinion.

114
00:15:20,720 --> 00:15:24,500
And on some level, people talk about it, but they don't really do it.

115
00:15:25,180 --> 00:15:36,400
So, I'm sure that there are tons of practices that are fairly simple and easy to implement that would provide a ton of benefit in a lot of organizations.

116
00:15:36,560 --> 00:15:55,620
But, in general, I'm not terribly optimistic that they will adopt them unless they – unless someone could tie it to money or to some sort of business driver upstream, then sort of the grassroots adoption of these types of practices is often a losing battle.

117
00:15:57,160 --> 00:16:02,160
That's sort of where the executives – that's why I'm hoping Israel can help spread the word.

118
00:16:02,740 --> 00:16:12,780
Well, I'm actually wondering, Andrew, and tell me whether the following way of reasoning makes sense to you.

119
00:16:13,900 --> 00:16:16,300
Why does change happen?

120
00:16:16,700 --> 00:16:23,680
Change happens because the environment within which a company is operating changes.

121
00:16:24,600 --> 00:16:30,060
And this is particularly true, has been particularly true over the past seven, eight months or so.

122
00:16:30,560 --> 00:16:33,200
So, change – change is endemic.

123
00:16:34,520 --> 00:16:40,820
Part of this change reflects itself, manifests itself in the IT environment.

124
00:16:42,100 --> 00:16:53,920
And the point to me is the function of IT or the objective of IT is not to minimize change in order to get the highest availability.

125
00:16:55,180 --> 00:16:59,540
The objective of IT is the objective of IT is to serve the needs of the business.

126
00:17:00,500 --> 00:17:00,900
Absolutely.

127
00:17:01,700 --> 00:17:06,400
If the business changes, then IT needs to change in accord.

128
00:17:07,060 --> 00:17:10,760
There is no point, of course, in changing for changing sake.

129
00:17:11,500 --> 00:17:26,440
But to be in IT and to say we would be deliberately very slow on change because we don't want to take the risk, to me, does not weigh the pros and cons in an equitable manner.

130
00:17:27,100 --> 00:17:32,880
Yes, the risk of going down might be increased by 1%.

131
00:17:32,880 --> 00:17:37,360
At the same time, the business benefits might easily outweigh it.

132
00:17:37,360 --> 00:17:50,280
An example that I would give you along those lines, years ago, the CTO of a company named Algorithmics discussed with me applying agile with some of his banking clients.

133
00:17:51,280 --> 00:18:00,220
And I was shocked by the large growth of programmers that the banking were using for all kinds of hedging schemes, etc.

134
00:18:01,640 --> 00:18:10,360
And I told this guy, look, I don't really understand why this very, very wasteful way of developing software.

135
00:18:11,360 --> 00:18:22,580
And he said, Israel, you don't understand, they recoup years of investment in software in one good trade, in Wall Street or London or Tokyo or whatever it was.

136
00:18:23,340 --> 00:18:35,000
So the benefits to the business are such that they easily outweigh the benefits that a more efficient development would have given.

137
00:18:35,740 --> 00:18:49,640
So this is a kind of fine line that I think IT needs to embrace, namely, you can't change too frequently or too haphazardly because you might paralyze the business.

138
00:18:50,160 --> 00:19:02,480
At the same time, you can't be pushing back about change all the time because you would paralyze the business in a different manner by not letting it respond to change.

139
00:19:04,600 --> 00:19:07,000
Yeah, I agree with everything you're saying.

140
00:19:07,120 --> 00:19:17,340
If you go back to John Alspaugh, who's a rock star, he had a slide that said exactly what you said, that ops job is not to keep the machines up and stable.

141
00:19:17,500 --> 00:19:19,520
Ops job is to enable the business.

142
00:19:20,020 --> 00:19:28,400
And so you want to be able to take advantage of everything that is an opportunity requires change in almost every case.

143
00:19:28,400 --> 00:19:37,060
So if you can't change or you're afraid to change or it's expensive to change or you change and it brings down all your applications, then that's not very agile.

144
00:19:37,180 --> 00:19:41,620
And I think it was in his talk, and you can go watch a bit.

145
00:19:41,720 --> 00:19:44,660
He said that – and they used the word agile in their talk.

146
00:19:44,720 --> 00:19:54,120
He said if you bring your machines down, you know, if you have downtime or outages 10 times a day, that's not being agile.

147
00:19:54,240 --> 00:19:54,980
That's just retarded.

148
00:19:57,000 --> 00:19:59,620
I certainly agree with that.

149
00:19:59,620 --> 00:20:09,460
And I would actually like to highlight your good points in the following manner.

150
00:20:10,460 --> 00:20:29,420
Years ago, you know, we had similar things with development, namely before we got into iterative methods, then this business of adhering to a rigid plan was, you know, paramount for a variety of reasons in the way we did software.

151
00:20:30,160 --> 00:20:47,420
In many ways, when I hear sometimes from IT centers about their adherence to a very, very rich install and deployment process, I have the sense that it is déjà vu.

152
00:20:47,840 --> 00:20:56,760
Maybe the same disciplines that we used to apply to software development seem to apply sometimes within the IT center.

153
00:20:56,760 --> 00:21:07,900
And I see no reason that things that have proven themselves so well in software development would not be applicable with the right modification, of course, to IT.

154
00:21:09,120 --> 00:21:10,180
I agree.

155
00:21:10,540 --> 00:21:15,020
One of my favorite quotes is that no plan survives the initial contact with the enemy.

156
00:21:15,940 --> 00:21:25,320
And I kind of feel like no requirements document survives the initial contact with the developers from personal experience.

157
00:21:25,320 --> 00:21:33,760
Yeah, I think what Israel is saying gets to kind of like the next thing I was interested in talking about.

158
00:21:33,900 --> 00:21:39,960
And like, so, I mean, we have this idea of sort of like agile developer practices sort of meets the IT world, if you will.

159
00:21:40,120 --> 00:21:48,420
And then, of course, as we actually covered pretty well, to use the old enterprise phrase, you know, IT is concerned with this business IT alignment,

160
00:21:48,420 --> 00:21:55,260
which is basically like helping the business make money rather than, you know, retarding it, as it were.

161
00:21:55,600 --> 00:21:55,720
Right.

162
00:21:55,800 --> 00:22:02,460
Or just wasting cash, which would be the lesser evil than just kind of like grinding the business side of the house to a stop.

163
00:22:02,920 --> 00:22:12,080
And so, you know, I mean, we started out at the beginning like talking about one of the practices, you know, sort of like a principle level and then a practice level kind of.

164
00:22:12,580 --> 00:22:12,900
Absolutely.

165
00:22:12,900 --> 00:22:20,220
In the sense of sort of like somehow modeling your IT and your servers and everything such that you can treat it like source code, if you will, your infrastructure.

166
00:22:20,400 --> 00:22:28,060
And I'm curious, like in addition to that sort of principle and practice, as you guys are kind of looking at this idea,

167
00:22:28,220 --> 00:22:34,060
like what other sort of principles and practices you see emerging from kind of like this agile IT are?

168
00:22:36,400 --> 00:22:47,060
So the first step that – this was a reoccurring theme at velocity that was brought up by more than one person in both talks and hallway discussions.

169
00:22:47,360 --> 00:22:50,160
But you basically – you need to automate your infrastructure.

170
00:22:50,400 --> 00:22:52,800
That's the basic starting point, right?

171
00:22:52,860 --> 00:23:03,140
That's the – if you can't build those servers from bare metal to running services, then you're going to have – you're going to spend all this time doing that.

172
00:23:03,140 --> 00:23:13,140
And I think another thing that's happened is it used to be that the capacity planning was a long process and then, you know,

173
00:23:13,140 --> 00:23:14,640
obviously take some analysis.

174
00:23:15,180 --> 00:23:23,080
But then if you want to add capacity, you add – you make a purchase order and then some machines got put on a truck somewhere

175
00:23:23,080 --> 00:23:26,080
and they eventually come to your building or your data center.

176
00:23:26,560 --> 00:23:28,200
And then you have to rack and cable those.

177
00:23:28,320 --> 00:23:34,040
And then, you know, if you are really in the dark ages, you have to go put CDs or something.

178
00:23:34,460 --> 00:23:39,960
If you have, you know, one level of automation, you can pixie boot and bring machines up.

179
00:23:40,280 --> 00:23:44,400
And then if you have to configure those with kind of traditional methods, that might be a lot of work.

180
00:23:44,500 --> 00:23:48,640
There's a guy in the puppet community by the name of Paul Lathrop.

181
00:23:48,740 --> 00:23:52,960
He's a senior systems engineer at dig.com.

182
00:23:53,140 --> 00:23:55,880
And he came on the list one day and he was very excited.

183
00:23:55,880 --> 00:24:05,560
This is a couple months ago that he just rebuilt 60 machines from bare metal to running services and it had taken him two hours.

184
00:24:06,200 --> 00:24:10,220
And he was mostly a spectator using Puppet and some – it was five.

185
00:24:10,420 --> 00:24:15,180
So they were – it was Debian machines brought up from the network and then Puppet built out the services.

186
00:24:15,800 --> 00:24:23,960
And he said that a year ago, that same job, rebuilding those 60 machines, would have taken two full days of work and working the whole time.

187
00:24:24,900 --> 00:24:30,120
So that's an order of magnitude at least improvement in time efficiency.

188
00:24:30,540 --> 00:24:30,880
Right, right.

189
00:24:31,100 --> 00:24:37,840
I mean it reminds me of – there's all those little – there's a handful of like neglected corners of like ITIL and service management.

190
00:24:37,980 --> 00:24:42,620
There's the one that's like – I forget what it's called, but it's basically just like acquisition of stuff.

191
00:24:43,260 --> 00:24:43,600
Sure.

192
00:24:43,720 --> 00:24:50,360
And, you know, there's also capacity planning, which I always thought was sort of like much embarrassed by virtualization consolidation.

193
00:24:50,740 --> 00:24:56,600
It's sort of like whatever capacity planning we were doing had left that much spare capacity on the table that could be consolidated.

194
00:24:57,160 --> 00:25:05,020
But without getting down that rabbit hole, it seems like there is a certain amount of – beyond just once you actually have everything, you know, sort of racked in cable,

195
00:25:05,020 --> 00:25:12,600
like the actual getting stuff before that, getting to that state where you can actually just turn the machine on and start doing things with it.

196
00:25:13,040 --> 00:25:13,480
Absolutely.

197
00:25:13,480 --> 00:25:13,500
Absolutely.

198
00:25:14,500 --> 00:25:21,740
Coté, I think you are out of something which I would pose as a question.

199
00:25:22,660 --> 00:25:24,060
And the question is as follows.

200
00:25:25,200 --> 00:25:35,140
In our social development circuits, we oftentimes contrast waterfall methods with agile or iterative methods.

201
00:25:36,500 --> 00:25:52,220
The question that comes to my mind when you are mentioning ITIL is whether it would be appropriate to draw the analogy that ITIL for the data center is in many ways like waterfall to social development.

202
00:25:53,340 --> 00:25:58,960
Does this analogy make sense to you or do you think I'm smoking something strong?

203
00:25:59,960 --> 00:26:07,820
So I'd like to make a quick comment there because I think in the – you know, and obviously if you follow how I talk and what I write about, you know,

204
00:26:07,860 --> 00:26:15,320
I embrace agile as sort of an idealized concept but I'm not always impressed with how agile manifests itself.

205
00:26:15,960 --> 00:26:23,320
And in some cases, the agilists tend to kind of demonize this mythical waterfall creature.

206
00:26:23,320 --> 00:26:28,260
And in reality, most places don't necessarily have waterfall.

207
00:26:28,900 --> 00:26:36,680
They have some ad hoc homegrown special snowflake process that doesn't look like any other process any other place.

208
00:26:36,880 --> 00:26:53,780
And I think when you start to contrast that with ITIL, there's a recent report that came out about ITIL and CMDBs and less than 5% of these enterprises who supposedly buy into this stuff are implementing a CMDB.

209
00:26:54,160 --> 00:27:04,960
So on one level, I totally agree with you as sort of this slow-moving, you know, impedance that is easy to demonize.

210
00:27:05,260 --> 00:27:10,040
You know, obviously you guys – Kode, you probably – you just did a podcast with the IT skeptics.

211
00:27:10,540 --> 00:27:11,200
That's right.

212
00:27:11,440 --> 00:27:14,000
So I'm sure he had plenty to say on this topic.

213
00:27:14,300 --> 00:27:19,220
On the other hand, not very many people are really implementing ITIL just like they're not implementing waterfall.

214
00:27:19,400 --> 00:27:19,800
Yeah.

215
00:27:20,020 --> 00:27:28,920
You know, I mean – and I'll have to put a link to that thing now, that IT management podcast, because this is one of the – this is in a roundabout way.

216
00:27:29,220 --> 00:27:35,560
It's similar to something that we were talking about with the guy, Rob England, who also goes by the moniker, the IT skeptic.

217
00:27:36,200 --> 00:27:45,400
And, you know, I mean, his – as his name would imply, he tends to be quite a rock thrower against like ITIL and CMDBs and things like that.

218
00:27:45,400 --> 00:27:52,540
But in reality, a lot of the – he's a lot more into what I sort of call – I always like to stick pragmatic in front of something.

219
00:27:52,740 --> 00:28:06,120
And he's always trying to get people to do pragmatic CMDBs and pragmatic ITIL and things like that, which essentially means, you know, it's one thing to sort of like map 100% of your IT infrastructure in a CMDB.

220
00:28:06,300 --> 00:28:13,040
It's like a huge task, which is very expensive and may indeed slow you down as far as like delivering that service management.

221
00:28:13,260 --> 00:28:21,060
But, you know, there's other more adaptive things you can do where you only map as much as you need into a CMDB or you only do so much of the process that you need.

222
00:28:21,060 --> 00:28:37,600
But the important thing, which he emphasizes over and over again, not to put too many words in his mouth, is to sort of like figure out those goals that you're trying to do and figure out between tools and people and process that you have, like if you can sort of meet those goals, essentially just doing change management, which is –

223
00:28:37,600 --> 00:28:40,000
The simplest thing that could possibly work.

224
00:28:40,100 --> 00:28:40,500
Exactly.

225
00:28:40,760 --> 00:28:43,540
And so that's – see, there's a very agile principle right there applied.

226
00:28:43,540 --> 00:28:59,440
And I think, you know, his point, like to use one of his examples that we talked about in that recording yesterday is essentially, you know, when you're trying to get the maximal amount, the waterfall ITIL, I guess, you could think, you know, what we need –

227
00:28:59,440 --> 00:29:04,880
the problem that we have is all of this process and knowledge is trapped in someone's head or some people's heads.

228
00:29:04,900 --> 00:29:08,880
And we need to get it out of their heads and into the CMDB such that it's always stored somewhere.

229
00:29:09,360 --> 00:29:16,120
And, you know, one of his sort of anecdotal points is, well, maybe you don't really need to get all of it out of someone's head.

230
00:29:16,300 --> 00:29:17,420
I mean, you have a process.

231
00:29:17,660 --> 00:29:25,020
It may not be sort of like a Fortune 50 optimized process that defense contractors can use that doesn't rely on people.

232
00:29:25,180 --> 00:29:32,700
But for some organizations, relying on people to kind of know parts of what's happening in the process might be sufficient for you and it might work out.

233
00:29:32,980 --> 00:29:48,160
And then instead of getting all worked up and bothered about modeling everything and storing everything and locking everything into whatever ITIL enablement tools that you have, you might rely on people and you might rely on tools.

234
00:29:48,620 --> 00:29:59,840
But the important thing above all of that is that no matter if it's sort of like, to use one of Andrew's terms, sort of like a meat cloud or a whatever type of other cloud, like you have the same process that both of them are plugging into.

235
00:30:00,100 --> 00:30:08,960
And I think that's – as with – I mean, this is the same sort of – you could kind of go through and do a search and replace of everything I just said with like RUP versus Agile.

236
00:30:09,140 --> 00:30:22,000
And it would be a similar sort of discussion where it's really easy with ITIL and all the tools that are embodied in it to sort of like – as I always like to think, you know, we used to have those big rational and RUP process charts.

237
00:30:22,300 --> 00:30:27,060
And, you know, in reality, you were supposed to sort of pick and choose and customize the stuff from RUP that you wanted to use.

238
00:30:27,160 --> 00:30:31,460
But everyone would be obsessed with having everyone doing everything on that giant chart.

239
00:30:31,460 --> 00:30:49,860
Whereas I think ITIL is a similar sort of thing where you're more interested in not necessarily buffeting it and picking and choosing, but you pick out the amount of effort you want to put in to kind of reach the same goals and enable the same process, whether it's sort of like spending all your time updating CMDBs or just, you know, updating your Post-it notes.

240
00:30:49,940 --> 00:30:53,120
And that ends up delivering the same nice process for change management.

241
00:30:53,680 --> 00:31:07,320
Allow me to bring up a question here, which is what amount of choosing between the options is appropriate, and what amount is overwhelming?

242
00:31:08,120 --> 00:31:18,960
Certainly my experience with system management has been time and time again that we as an industry generally offer too many options to our customers.

243
00:31:18,960 --> 00:31:28,500
And oftentimes the customers start with eliminating 95% or some such percentage of what we offer.

244
00:31:29,500 --> 00:31:46,240
Now, the definition of what is appropriate in terms of flexibility that I provide to my customers and what is not appropriate obviously has tremendous economical value.

245
00:31:46,520 --> 00:32:01,680
In addition, I think it has a great effect on the way things change, and I, for one, believe that tools, and certainly the right tools, can really change behavior.

246
00:32:02,800 --> 00:32:10,160
Is that something that you, Andrew, when you call upon puppet shops as witnessing?

247
00:32:12,000 --> 00:32:13,780
Yes, yes and no.

248
00:32:14,060 --> 00:32:21,720
So I think that this is a very interesting topic, and it could probably be a separate hour by itself.

249
00:32:21,880 --> 00:32:30,620
But in general, you have tools that enable different processes, but you also have a lot of habits and inertia.

250
00:32:30,620 --> 00:32:43,580
And in general, you have the technical problems and the technical tools, but there is a lot of social engineering that's required in order to adopt and leverage those tools most effectively.

251
00:32:44,260 --> 00:32:53,880
And quite often, this happens more than I'd like to admit, but I'll be in a conversation, and we're trying to help people use puppet.

252
00:32:53,880 --> 00:33:09,800
And there's something where, to me, it seems really obvious and really simple, and you say, well, all you have to do as an ops team is be able to communicate with the dev team because they're used to throwing these tar bowls over the wall.

253
00:33:09,800 --> 00:33:26,860
And what I want you to be able to do is talk to them about how they are going to configure this application and maybe potentially write the puppet code together that would configure that application, considering how the developers know how to use it and the ops guys are going to manage it.

254
00:33:27,580 --> 00:33:34,140
And more often than I'd like, people will say, well, we can't do that.

255
00:33:35,340 --> 00:33:37,560
There's no way we can talk to our dev teams.

256
00:33:38,200 --> 00:33:40,120
And it's sad, but it's true.

257
00:33:42,260 --> 00:33:52,600
Well, I hear you loud and clear, and I would like to make a suggestion along the lines that you have stated at the beginning of your answer.

258
00:33:52,800 --> 00:34:16,500
You indicated that this is a fascinating topic, which is sufficiently substantive to require a full hour just for discussing of change, change management, and how it works or does not work within development, within deployment, and in various cultural contexts.

259
00:34:16,920 --> 00:34:24,240
Why don't we pick this topic to be the subject we discuss in our next podcast?

260
00:34:27,240 --> 00:34:28,300
It works for me.

261
00:34:28,480 --> 00:34:31,300
I think that that's a very interesting topic.

262
00:34:31,480 --> 00:34:41,840
And in some ways, it's the root of all – if you talk about Agile, and going back to what I said earlier about how people haven't adopted some of these practices,

263
00:34:42,180 --> 00:34:44,920
I think that that's sort of the root of all these things, right?

264
00:34:44,920 --> 00:34:57,860
So you look at what Agile and engineering practices enable, and being able to take and TDD and use the tools that have evolved and are still evolving in the most effective way,

265
00:34:58,000 --> 00:35:02,480
it requires a lot of habits to kind of die hard.

266
00:35:02,900 --> 00:35:07,480
And that's a big problem from, you know, the top of the organization to the bottom.

267
00:35:08,480 --> 00:35:17,720
Yeah, it's the classic technology retirement problem, which, you know, sort of encapsulates the slowest, easiest way to solve that issue.

268
00:35:17,840 --> 00:35:19,720
But it's definitely not the desirable one.

269
00:35:20,260 --> 00:35:24,260
Well, I mean, if you're talking about TDD, then that's certainly true.

270
00:35:24,340 --> 00:35:32,120
But when you get to organizations where they have a different manager or a different vice president that's managing development versus engineering or ops,

271
00:35:32,560 --> 00:35:41,120
then it's even more complicated because it's not only the time that has to pass to kind of phase out these old things,

272
00:35:41,120 --> 00:35:46,680
but you actually have a separate tribe and a wall of confusion between you.

273
00:35:47,080 --> 00:35:49,660
And that might go all the way up to the top of the organization.

274
00:35:50,420 --> 00:35:55,940
And until you can figure out ways to sort of dissolve that and open up the lines of communication,

275
00:35:56,200 --> 00:36:00,620
then the tools themselves are never going to be utilized at their full potential.

276
00:36:00,920 --> 00:36:05,860
Yeah, you have the issue of even if you can do your own internal culture change,

277
00:36:05,980 --> 00:36:10,120
you have to tell the rest of your organization how different new services you can provide

278
00:36:10,120 --> 00:36:14,380
because they're so used to the way things used to be and that being how they interact with IT.

279
00:36:14,600 --> 00:36:21,780
Like to the point of the financial thing, I mean, if IT is such a small cost, efficient or not, you know,

280
00:36:21,780 --> 00:36:27,800
for doing financials and banking, then suddenly giving them these new abilities that are more efficient

281
00:36:27,800 --> 00:36:34,500
and can introduce change faster, there's a lot of adapting that the business has to do as well to hook into that.

282
00:36:35,080 --> 00:36:37,620
Sure, I've discussed this with Israel in the past.

283
00:36:37,900 --> 00:36:46,840
You have, you know, you take and you transform the speed and the quality that a dev team can produce the software,

284
00:36:47,060 --> 00:36:50,160
and that has implications that ripple through marketing and sales.

285
00:36:50,160 --> 00:36:56,900
And unless you have, you know, the skills to kind of manage that cultural shift, then that can cause real problems.

286
00:36:57,500 --> 00:37:01,960
Yeah, well, you know, I think that's a good place to wrap up part one of the discussion here, then.

287
00:37:02,200 --> 00:37:06,560
And we've hit on some of the, like, little practices that people, you know,

288
00:37:06,660 --> 00:37:09,860
we've gone from the base level practices of things you could actually do

289
00:37:09,860 --> 00:37:12,840
and then kind of what that sort of enables and modes and everything.

290
00:37:13,060 --> 00:37:17,780
So unless you guys had anything else you wanted to weigh in on, we might as well close this part out.

291
00:37:18,900 --> 00:37:21,820
So I guess we're talking about social engineering next time?

292
00:37:22,340 --> 00:37:22,980
That's right.

293
00:37:23,980 --> 00:37:25,020
Ways to get passwords.

294
00:37:26,200 --> 00:37:27,400
Nature versus nurture.

295
00:37:29,720 --> 00:37:35,740
I will drink to that and will lovingly dig into it.

296
00:37:36,400 --> 00:37:37,280
Always a pleasure.

297
00:37:37,720 --> 00:37:38,640
Until next time.