1
00:00:00,000 --> 00:00:04,640
Well, hello, everybody. This is another edition of the agileexecutive.com podcast.

2
00:00:05,160 --> 00:00:09,820
And as always, this is one of your hosts, Michael Coté, available at peopleoverprocess.com,

3
00:00:09,880 --> 00:00:13,700
as well as the agileexecutive.com. And we've got another guest with ourselves today.

4
00:00:13,760 --> 00:00:14,760
Would you like to introduce yourself?

5
00:00:15,640 --> 00:00:17,280
Sure. Hi, I'm Dean Leffingwell.

6
00:00:18,120 --> 00:00:22,280
And so what exactly do you do in the agile world?

7
00:00:22,660 --> 00:00:33,480
Well, currently, I'm mostly gainfully employed as a consultant and enterprise transition expert for very large software enterprises,

8
00:00:33,720 --> 00:00:40,920
transitioning to agile. Started this work back four or five years ago, working primarily with BMC Corporation.

9
00:00:41,300 --> 00:00:46,780
I was the executive mentor and coach working with Israel Gott there, which is probably how you hook me up here.

10
00:00:47,080 --> 00:00:53,020
And that was my first larger scale agile transformation, one that touched, you know, in the hundreds of people.

11
00:00:53,520 --> 00:01:00,300
And it was kind of fun because it was a Greenfield model and we were able to do all in, meaning we just, you know, started from scratch.

12
00:01:00,460 --> 00:01:08,640
We, you know, eliminated the, you know, the governance model and all the constraints and procedures and documentation protocols associated with the waterfall.

13
00:01:09,080 --> 00:01:11,740
And did that transformation starting in 2006.

14
00:01:11,740 --> 00:01:20,000
In 2007 or maybe early 2008, they published a case study, which you could find, you know, googling BMC Agile or on my blog.

15
00:01:20,480 --> 00:01:22,260
Since then, I've done a couple of things.

16
00:01:22,420 --> 00:01:27,880
I've written a book called Scaling Software Agility, which is probably the thing that captures my thoughts the best.

17
00:01:28,440 --> 00:01:30,600
I actively blog on enterprise agile.

18
00:01:31,880 --> 00:01:37,440
Off and on, a CEO, had a startup two years ago in the internet identity space and got that launched okay.

19
00:01:38,260 --> 00:01:39,420
Formerly, I've been an executive.

20
00:01:39,600 --> 00:01:40,860
I was co-founder of Requisite Inc.

21
00:01:41,300 --> 00:01:43,280
In the 90s, sold that to Rational.

22
00:01:43,560 --> 00:01:47,880
I worked at Rational for four years and, frankly, just had a blast working with some very talented people.

23
00:01:47,880 --> 00:01:49,880
So you're a Requisite Pro guy then?

24
00:01:50,380 --> 00:01:52,240
I am actually the founder of Requisite Pro.

25
00:01:52,440 --> 00:01:52,540
Yeah.

26
00:01:52,940 --> 00:01:55,140
That still comes up all the time.

27
00:01:55,400 --> 00:01:59,180
Like Red Monk, the firm I'm with, does a lot of work with IBM.

28
00:01:59,180 --> 00:02:01,720
And Requisite Pro comes up all the time.

29
00:02:02,000 --> 00:02:07,360
It's sort of like, it seems like it's been around for a while and everyone's used to it.

30
00:02:07,440 --> 00:02:11,420
And everyone's kind of afraid of what's next, if you will.

31
00:02:11,440 --> 00:02:14,940
They're concerned about migrating to the next sort of thing that Rational might give them.

32
00:02:15,560 --> 00:02:16,240
I understand.

33
00:02:16,500 --> 00:02:18,980
Requisite Pro has been around for a while.

34
00:02:19,060 --> 00:02:23,560
I think the first cut was 96 or so, maybe 95.

35
00:02:24,280 --> 00:02:30,400
I actually continued my responsibilities with Requisite Pro at Rational, but I also took on responsibility for the Rational Unified process.

36
00:02:31,260 --> 00:02:34,260
So at the time that I joined the company, it was a process called Objectory.

37
00:02:34,860 --> 00:02:43,680
And it was kind of an odd but really potentially powerful use case-driven approach.

38
00:02:43,980 --> 00:02:45,520
And we rolled that into Rational.

39
00:02:45,600 --> 00:02:47,180
That became the Rational Unified process.

40
00:02:47,440 --> 00:02:51,100
So launching and marketing that was one of my most interesting projects.

41
00:02:51,100 --> 00:02:53,880
I also had responsibility for Rational University.

42
00:02:54,400 --> 00:02:59,580
And I also had the privilege of working with the UML authors, Brady Butch and Ivar Jakobson and James Rumbaugh.

43
00:03:00,000 --> 00:03:05,620
So I was also, because of the tight coupling to the RUP, I had responsibility for methodology and courseware.

44
00:03:06,120 --> 00:03:08,480
So that was a great career until about 2001.

45
00:03:08,720 --> 00:03:10,480
I left just before the IBM acquisition.

46
00:03:10,680 --> 00:03:14,920
I'm not sure if they had sussed it out and knew I would never make the cut or I just got lucky.

47
00:03:15,500 --> 00:03:17,780
But in any case, I didn't go along with the ride for IBM.

48
00:03:17,940 --> 00:03:22,820
And basically, since about 2002, 2003, hooked up with some people at Rally Software.

49
00:03:23,400 --> 00:03:27,540
Ryan Martins, who is certainly one of my mentors and taught me much of what I know about Agile.

50
00:03:27,540 --> 00:03:31,900
And I might have taught him a few things about large-scale software development.

51
00:03:32,440 --> 00:03:40,780
So basically, since about 2003, I've been pretty fully dedicated to Agile, other than the last startup I did, which was, of course, fully dedicated to Agile, too.

52
00:03:40,860 --> 00:03:42,340
But we were a commercial vendor.

53
00:03:42,460 --> 00:03:45,560
We used Agile as our process model, not as a means to itself.

54
00:03:46,100 --> 00:03:50,600
So I have experience as both a CEO and a consultant in actually applying Agile development.

55
00:03:50,880 --> 00:03:58,660
Well, you know, while it's sort of a foil for Agile, if you will, but since you were involved in a lot of rough work,

56
00:03:59,040 --> 00:04:05,300
I'm always curious, like, you know, as, I guess I sort of grew up as a programmer during the rough age, if you will.

57
00:04:05,420 --> 00:04:10,900
And it seemed like, it seemed like rough at, you know, this might be a little retrospectively looking at it,

58
00:04:10,940 --> 00:04:14,920
but it seemed like it was sort of like a box of process that you could assemble into whatever you wanted.

59
00:04:15,400 --> 00:04:23,540
And somehow, instead of being sort of a flexible process, when it was thrown out to the industry, both on the selling and buying side,

60
00:04:23,580 --> 00:04:30,620
it was sort of combined into everything in that giant poster that you would have, instead of sort of being guidance for assembling things together.

61
00:04:31,260 --> 00:04:37,380
And so, you know, for someone who's probably as familiar, you know, as you are with it, I mean, I wonder, you know,

62
00:04:37,380 --> 00:04:40,200
it's not so much like the snarky question of, like, what went wrong there?

63
00:04:40,320 --> 00:04:48,600
But, like, what was the, what would be that, what's the misalignment between what seemed like a pretty reasoned out, flexible sort of process,

64
00:04:48,600 --> 00:04:52,760
and then the rigidity that people seem to get upset about RUPP so much about?

65
00:04:53,600 --> 00:04:58,720
Well, you know, RUPP has a couple things going in its favor.

66
00:04:58,860 --> 00:05:03,040
And one of the first is it's the first real codified iterative and incremental development model.

67
00:05:03,680 --> 00:05:10,660
And shops are able to apply RUPP in a highly iterative and agile fashion, but that's not always the case.

68
00:05:10,660 --> 00:05:15,800
And because of the lifecycle overlays of inception, elaboration, construction, and transition,

69
00:05:16,140 --> 00:05:19,580
I would say that, in general, you know, this was not the fault of the user.

70
00:05:19,680 --> 00:05:20,640
This was our fault.

71
00:05:20,740 --> 00:05:25,300
It was often misapplied as basically a set of iterations inside a waterfall model.

72
00:05:25,860 --> 00:05:29,740
The reason it seemed inflexible is that it was really big and it was delivered as a website.

73
00:05:30,260 --> 00:05:35,320
So while you could tailor it, it was no mean feat to sit down and actually tailor it.

74
00:05:35,360 --> 00:05:37,000
And then you had revision management issues.

75
00:05:37,000 --> 00:05:38,740
So it was easier to use it out of box.

76
00:05:39,360 --> 00:05:44,440
Now, since we were rational and we supported large customers, you know, clients like Ericsson, I remember,

77
00:05:44,660 --> 00:05:48,380
was probably our number one licensed user of many of our tool kit kits.

78
00:05:49,040 --> 00:05:50,260
RUPP had to be extremely broad.

79
00:05:50,800 --> 00:05:52,880
So it had to be really broad.

80
00:05:53,020 --> 00:05:55,240
It had to be reasonably deep.

81
00:05:55,840 --> 00:05:58,840
And it had to do both in a codified way.

82
00:05:59,200 --> 00:06:02,420
So it ran into hundreds and hundreds and hundreds of pages.

83
00:06:02,820 --> 00:06:07,560
And while there were smaller instances that were tailored, if you just got it off the shelf, it was just big.

84
00:06:08,020 --> 00:06:11,100
And because it was big and a website, it didn't feel particularly tailorable.

85
00:06:11,820 --> 00:06:16,540
And then if you add that to the fact that there are the lifecycle phases, which, you know, many applications go through.

86
00:06:16,540 --> 00:06:23,000
But we think far more of, you know, streaming models now than we do lifecycle development.

87
00:06:23,200 --> 00:06:30,220
You know, none of the programs we ever develop, that we develop ever really die, or at least not within a decade or so.

88
00:06:30,660 --> 00:06:33,960
So I think that the streaming Agile mode, I think, is just a better mental model.

89
00:06:34,480 --> 00:06:44,320
But if you took that overlay out of those kind of assumed waterfall-like phases, it was, you know, really a well-structured and well-thought-through iterative model.

90
00:06:44,660 --> 00:06:48,020
Now, with respect to Agile, it's a lot more iterative than the waterfall.

91
00:06:48,300 --> 00:06:56,460
But at the same time, if you're dealing with a RUP shop, in some senses, it's harder to convert them to Agile because they're already iterating.

92
00:06:57,180 --> 00:07:01,360
And in many cases, they don't have quite the pain that the waterfall companies do.

93
00:07:01,540 --> 00:07:10,460
So it's not so easy to run into a, you know, a highly embedded RUP shop doing everything with use cases and move them to a more Agile model.

94
00:07:10,920 --> 00:07:14,440
Even though I like to do that, it's not a trivial thing.

95
00:07:14,660 --> 00:07:23,140
Yeah, no, I mean, there's a lot of sort of artifact friction, if you will, between moving between those two processes that seems like it would be hard to resolve.

96
00:07:23,140 --> 00:07:32,400
But, you know, going over sort of like you were mentioning, sort of maintaining long-running software projects and code bases, if you will.

97
00:07:32,680 --> 00:07:38,860
And what with the sort of enterpriseness of the enterprise Agile that you see a lot of.

98
00:07:38,940 --> 00:07:47,860
One thing I'm always curious about is a lot of the discussion around Agile that I see and I have with people is sort of about the first few versions of some software project.

99
00:07:48,100 --> 00:07:53,700
Like we're like making the new version, then we'll have the supported version, then who knows what's going to happen in two years.

100
00:07:54,160 --> 00:07:58,920
And I wonder, like, usually enterprise connotes it's been around a long time.

101
00:07:59,000 --> 00:08:01,280
Like we're working on version 12 of something, essentially.

102
00:08:01,920 --> 00:08:08,060
And I wonder, like, if you've seen, like, does Agile change when you're working on old software?

103
00:08:08,320 --> 00:08:09,920
Like how do things apply differently?

104
00:08:09,960 --> 00:08:14,220
Because I don't really read a whole lot about, like, Agile and maintenance mode, if you will.

105
00:08:14,220 --> 00:08:27,220
Well, you know, if you look at a group of just, say, any enterprise with, I'll just pick a fairly large, medium to large project team of 500 people.

106
00:08:27,760 --> 00:08:31,440
What are the odds that those people are all working on new stuff, right?

107
00:08:31,820 --> 00:08:32,580
Pretty low.

108
00:08:33,780 --> 00:08:39,480
They're probably, they may have 60 or 70 percent devoted to existing product lines, maybe 80 percent.

109
00:08:39,660 --> 00:08:44,760
And of that, they may have 30 or 40 percent of that time or even more doing ongoing maintenance.

110
00:08:45,500 --> 00:08:50,360
So, you know, in the enterprise, you find more legacy code because you find more code.

111
00:08:50,900 --> 00:09:00,080
Now, the way I look at legacy code is if I take a Greenfield project and look, you know, look at that same project, two days later, I have new legacy code, right?

112
00:09:00,160 --> 00:09:01,280
All code is legacy code.

113
00:09:01,380 --> 00:09:02,560
The only question is how old it is.

114
00:09:02,940 --> 00:09:03,040
Right.

115
00:09:03,100 --> 00:09:05,880
You know, it might be three hours old because it was my last iteration.

116
00:09:06,220 --> 00:09:20,280
Now, good agile development creates legacy code that's more maintainable because if you follow, really do agile right and you embed, you know, many of the XP principles and practices along with the scrum project management practices, you'll create more maintainable code.

117
00:09:21,240 --> 00:09:27,820
Now, having said all of that, when it comes to the basic scrum-like software project management practices, it's the same.

118
00:09:28,280 --> 00:09:39,400
I mean, even doing, it's in some ways easier to do, start something like maintenance with scrum with a daily stand-up and a short prioritized backlog and setting objectives rather than just, you know, fixing what we can.

119
00:09:39,400 --> 00:09:49,640
And trying to theme a sprint or a maintenance release to provide value added in some domain or some kind of requirements area where you gather together a few defects and try to make an impact.

120
00:09:49,820 --> 00:10:09,440
So I would say in many cases it's relatively straightforward to add agile to the enterprise, but then you hit test and test automation and people freak because they can't possibly go back and add test automation to their legacy code any more than an agile shop would touch, you know, the code they wrote two years ago and say, okay, we're going to add test automation around all that.

121
00:10:09,600 --> 00:10:10,580
It mostly doesn't happen.

122
00:10:11,180 --> 00:10:14,820
So whether it's Greenfield or not, I think you mostly have to approach it incrementally.

123
00:10:14,920 --> 00:10:18,460
And what I try to get teams to focus on is let's worry about the new code.

124
00:10:18,760 --> 00:10:28,940
What's one of the interesting experiences that I just have with an agile team is in transitioning, it's about 110 folks, 30 or 40 of whom work on a particular client-side application.

125
00:10:29,740 --> 00:10:31,760
And they had built a lot of inventory.

126
00:10:31,940 --> 00:10:34,760
They had a lot of code that was written and untested and undeployed.

127
00:10:35,080 --> 00:10:38,400
And consequently, they couldn't put anything new through the system because it was bottlenecked.

128
00:10:38,460 --> 00:10:47,380
And it was, you know, basically like a bunch of unflow-soldered circuit boards sitting in front of the flow-soldering machine.

129
00:10:47,480 --> 00:10:48,900
So you couldn't push anything new through.

130
00:10:49,480 --> 00:10:53,220
And we got them very oriented on moving their inventory out.

131
00:10:53,300 --> 00:10:55,300
And what they meant by that was testing what they had.

132
00:10:55,680 --> 00:11:01,160
And they became very, you know, kind of conscious and started doing test automation and realized, oh, my gosh, this is coding.

133
00:11:01,420 --> 00:11:03,660
And it's not drudge work.

134
00:11:03,820 --> 00:11:04,980
It's not just manual testing.

135
00:11:05,220 --> 00:11:07,720
It's really hard work, and you really have to think through it.

136
00:11:08,300 --> 00:11:11,880
And we had some discussions then about the next new release, which was about ready.

137
00:11:11,980 --> 00:11:13,160
And all the new stuff had been tested.

138
00:11:13,220 --> 00:11:20,880
And they said, well, we're not really comfortable yet because we haven't really been able to add much test or test automation around the rest of the application.

139
00:11:21,360 --> 00:11:25,580
And we had to remind them that the rest of that application was already deployed to something like 10,000 users.

140
00:11:25,880 --> 00:11:30,420
So we probably couldn't stop right now and add additional automation to what was already deployed.

141
00:11:30,420 --> 00:11:30,780
Right.

142
00:11:31,320 --> 00:11:37,600
There was no sense in converting your customer-based, you know, unit tests to code-based unit tests, I guess.

143
00:11:38,140 --> 00:11:41,420
Yeah, I mean, it was just – and the problem becomes kind of imponderable.

144
00:11:41,560 --> 00:11:42,940
So you've got to, you know, not go overboard.

145
00:11:43,060 --> 00:11:46,380
And like I said, I like to focus on, you know, what could be done incrementally.

146
00:11:46,580 --> 00:11:50,440
You know, what's the next thing we can do to, you know, lay down some new good code?

147
00:11:50,780 --> 00:11:54,520
And, you know, if you're a good XP fan, you understand refactoring.

148
00:11:54,580 --> 00:11:56,520
And when you touch a piece of code, you try to improve it.

149
00:11:56,980 --> 00:11:57,620
Yeah, definitely.

150
00:11:58,060 --> 00:12:03,780
So getting back, you know, also to the enterprise part of Enterprise Agile.

151
00:12:03,780 --> 00:12:08,740
And actually, you know, I was at BMC myself during all that.

152
00:12:08,940 --> 00:12:14,040
And I think I remember seeing the back of your head from the back of those giant rooms where we'd have meetings.

153
00:12:14,260 --> 00:12:15,500
The big planning meetings.

154
00:12:15,620 --> 00:12:15,780
Okay.

155
00:12:15,960 --> 00:12:16,280
There you go.

156
00:12:16,360 --> 00:12:16,600
Right.

157
00:12:16,760 --> 00:12:28,140
And, you know, the thing that I found when we were doing all that at BMC and then subsequently when I switched over to the dark side of industry analystdom, I guess, when I was talking with people about it,

158
00:12:28,140 --> 00:12:36,800
is that, you know, while there's a lot of sort of entrenched developers and even QA people who get all upset about switching to Agile,

159
00:12:36,800 --> 00:12:45,280
the sort of, like, next challenge becomes, like, plugging it into, like, the product management and the marketing and, like, the whole – the sales and the whole rest of the organization.

160
00:12:45,820 --> 00:12:54,340
But, you know, essentially any process, software development process you have or methodology is sort of a leaky abstraction that sort of drives what goes on in the rest of the company.

161
00:12:55,000 --> 00:12:55,400
Absolutely.

162
00:12:55,680 --> 00:12:56,000
Absolutely.

163
00:12:56,120 --> 00:13:06,380
You probably remember when we were moving the, you know, the internal release cycles on the BMC product from, you know, on the order of 12 or 16 months down to four months.

164
00:13:06,620 --> 00:13:13,120
We thought that would be infinitely good food until we started talking to training and support and the sales team and service level agreements.

165
00:13:13,860 --> 00:13:15,840
And, you know, it really hit the fan at that point.

166
00:13:15,940 --> 00:13:22,400
And that was just – I think that reflects our own naivete about how much impact Agile does have in the enterprise.

167
00:13:23,120 --> 00:13:35,740
So while that is absolutely an issue and I deal with it a lot, we see, you know, conflicting governance models, issues of, you know, not being able to do what I call the Agile release train, building PSIs because people think that's a release.

168
00:13:36,100 --> 00:13:42,940
And if you call it an internal release and everybody knows you're going to release it and, you know, the hackles go up everywhere and we're not going to release that often or whatever.

169
00:13:43,360 --> 00:13:44,460
There are a lot of challenges there.

170
00:13:44,520 --> 00:13:53,540
Well, I have to tell you, though, there are second-order challenges because the first-order challenge in an organization of three, four, five hundred developers and testers is can they write code in an Agile manner?

171
00:13:53,860 --> 00:13:56,560
You know, can they build code in a time box?

172
00:13:56,980 --> 00:13:58,460
I have it tested and ready to ship.

173
00:13:58,920 --> 00:14:06,660
So I don't – when I approach organizations, unless they've already hit that problem, I don't lead with the issues you're going to yet discover.

174
00:14:06,880 --> 00:14:07,800
Oh, sure, sure.

175
00:14:07,960 --> 00:14:10,300
Because, you know, the Agile process will expose them.

176
00:14:10,400 --> 00:14:11,280
They will be there.

177
00:14:11,740 --> 00:14:15,240
But I try to be concerned about those on a just-in-time basis.

178
00:14:15,680 --> 00:14:20,360
And if the teams can't get more reliable about the release dates, there's no sense in bragging about how fast they're going to be anyway.

179
00:14:20,740 --> 00:14:21,180
Yeah, yeah.

180
00:14:21,780 --> 00:14:27,180
There's a certain – you know, you've got to worry about your own health before you worry about your future wardrobe, I guess.

181
00:14:27,480 --> 00:14:27,920
Absolutely.

182
00:14:27,920 --> 00:14:28,500
And what you might be wearing.

183
00:14:28,500 --> 00:14:38,720
But so when you do get to the point of the future wardrobe, I mean, how – are there sort of, like, standardized ways of working with sort of the rest of the company?

184
00:14:38,820 --> 00:14:41,540
Or does it end up being sort of, like, customized for each company?

185
00:14:41,720 --> 00:14:42,820
Because, you know –

186
00:14:42,820 --> 00:14:51,400
A ton depends upon the size and scope and strength of, you know, the project office or the PMO.

187
00:14:51,920 --> 00:14:53,700
And that varies tremendously.

188
00:14:53,700 --> 00:15:02,760
I mean, I work in enterprises where that is basically, you know, to tease a little bit, the mothership of all impediments, right?

189
00:15:02,940 --> 00:15:03,340
Right.

190
00:15:03,860 --> 00:15:08,380
From the standpoint of, no, those are just kind of project managers and they kind of help the teams.

191
00:15:08,820 --> 00:15:17,920
A really robust project office, you know, PMO, is a pretty – I don't know.

192
00:15:18,840 --> 00:15:24,960
It could be a potentially really large adversary because they've built their whole world around a couple of things.

193
00:15:25,120 --> 00:15:31,860
Basically, commitments that they like to think they can make on a very long term that none of us ever meet and we're all embarrassed.

194
00:15:32,280 --> 00:15:41,340
But if you take away even the pretense of a long-term commitment, it, you know, it undermines their whole – kind of their whole thought processes.

195
00:15:41,700 --> 00:15:58,240
And then if you take away all the governance things they use, you know, the design complete milestones and the test plan complete milestones, but you haven't put in place actual agile development where you're creating, you know, code in – you know, potentially shippable increments short term, you've given them nothing.

196
00:15:58,660 --> 00:16:03,620
So I would suggest that the way not to approach that is as follows.

197
00:16:03,720 --> 00:16:08,340
You go there and say, look, we don't make those long-term commitments anymore and we don't need your bleeding milestones.

198
00:16:08,540 --> 00:16:11,200
We're agile because you will lose that argument.

199
00:16:11,380 --> 00:16:15,280
Those are big, beefy boys and girls and they have organizational prowess.

200
00:16:15,360 --> 00:16:16,380
They understand the politics.

201
00:16:16,940 --> 00:16:19,780
They have controls on all the, you know, the quality assurance guidelines.

202
00:16:19,880 --> 00:16:20,880
They interface to the customer.

203
00:16:20,880 --> 00:16:26,280
Many of them really are effectively the Uber product managers because they drive programs into the market.

204
00:16:26,880 --> 00:16:37,120
So you've got to really approach that, you know, that – those gates with some healthy and hefty respect for the problem that is ahead.

205
00:16:37,800 --> 00:16:42,620
And in many organizations, they're small or they're, you know, they morph very quickly.

206
00:16:42,980 --> 00:16:45,720
And others, like I said, they are the mothership of embeddements.

207
00:16:45,720 --> 00:16:54,720
And you have to take that on not, you know, not in a frontal assault way because that brings up the wrong connotation, but directly and persistently.

208
00:16:55,360 --> 00:17:08,980
And you have to be smart enough to understand that just because, you know, these new scrum masters and these new ex-peers have some ways they think that are better, those aren't really arguments that sell well in their project office.

209
00:17:09,240 --> 00:17:11,160
They don't get scrum.

210
00:17:11,240 --> 00:17:11,880
They don't write code.

211
00:17:12,060 --> 00:17:12,840
That's not what they do.

212
00:17:13,560 --> 00:17:22,360
So – and you can't talk about XP practices and the philosophies are just, you know, a piece of it that they don't necessarily ascribe to as well.

213
00:17:22,740 --> 00:17:25,460
You know, the teams are empowered and then the best decisions are local decisions.

214
00:17:26,140 --> 00:17:34,800
So it's kind of a, you know, a worthy adversary and we are the barbarians at those gates.

215
00:17:34,800 --> 00:17:45,480
Yeah, it seems like sort of pulling together a couple of things you've, you know, you've said about the development, the agile development team fitting into the rest of the organization.

216
00:17:45,480 --> 00:17:58,960
It's almost as if you have an existing process, if you will, that you have to apply a sort of like old design pattern where you kind of have a facade going on where you interact with the rest of the organization in whatever way they're used to interacting.

217
00:17:59,160 --> 00:18:04,260
Meanwhile, you're transforming yourself and slowly you're changing what those interfaces are to the rest of the world.

218
00:18:04,340 --> 00:18:15,580
Just to pick one, like, you know, until – to your point, until the development teams have become agile themselves, they can't really give good metrics that fit into the rest of the organization that's always expecting metrics.

219
00:18:15,580 --> 00:18:15,840
Correct.

220
00:18:15,840 --> 00:18:17,960
So that's iterations or testing or things like that.

221
00:18:18,260 --> 00:18:29,100
And it seems like if in flight you want to change stuff, there's a bit of – there's a lot of overlap of reporting in the old style and interfacing in the old style until you can convert everything over to an agile way of doing things.

222
00:18:29,500 --> 00:18:35,380
One large organization I worked with with about 1,000 practitioners had a very stiff PMO.

223
00:18:35,820 --> 00:18:45,960
And yet at the same time, you know, at the team level and at the software engineering management level, they recognized that they needed to go to agile in order to be able to survive and thrive.

224
00:18:47,460 --> 00:18:55,060
And what they ended up doing was coming up with a set of adapters because there were design review milestones, if you will, and test plan complete milestones.

225
00:18:55,920 --> 00:19:00,880
And, you know, defect counts that had to be at a certain level before you could ship software.

226
00:19:01,240 --> 00:19:06,480
And those were really orthogonal and in many ways in conflict with the agile process.

227
00:19:07,100 --> 00:19:14,740
So it's not that agile development that people don't do designs, but it's unlikely they have a thing that they could ship for review by others.

228
00:19:15,520 --> 00:19:29,540
And that basically building the friction of, you know, stopping that team and saying, okay, you need to pass this milestone before you go on, builds all these non-lean delays into the process and just really, you know, frustrates the pig, if you will, on the agile teams.

229
00:19:30,220 --> 00:19:33,100
So even with adapters, it's not a trivial problem.

230
00:19:33,760 --> 00:19:39,920
And, you know, you just have to take each organizational context into space and you indicate, sorry, into mine.

231
00:19:40,020 --> 00:19:46,880
And you look at each case specifically and say, how far can we go here before we get into what kind of trouble?

232
00:19:47,320 --> 00:19:48,620
And do we need adapters?

233
00:19:48,740 --> 00:19:51,120
Do we need, you know, some PMO people on our team?

234
00:19:51,200 --> 00:19:52,200
Can that be restructured?

235
00:19:52,580 --> 00:19:55,860
Can we lighten the milestones, you know, to less milestones?

236
00:19:55,980 --> 00:19:57,740
You know, what can we do to soften that up?

237
00:19:58,160 --> 00:20:07,220
Because at the enterprise level, if you're seriously dedicated as a team and you're talking about teams of teams, let's take 500 people.

238
00:20:07,720 --> 00:20:13,880
Ask yourself the question, how long will it be before those 500 people are really agile and able to ship a PSI every 60 days?

239
00:20:13,920 --> 00:20:16,200
And the answer is a year or two.

240
00:20:16,740 --> 00:20:19,520
Well, that can be a pretty long time to deal with all those adapters as well.

241
00:20:19,580 --> 00:20:26,460
And yet the alternative is worse, which is you don't get to be agile or you basically go into water scrumming mode, which is you go as far as you can.

242
00:20:26,540 --> 00:20:33,520
You have design iterations and then you show your design review and then you have development iterations and you show your code and the defect count.

243
00:20:33,520 --> 00:20:44,780
And then you have, you know, quality iterations where you add test automation and you end up programming yourself backwards into the waterfall model, which is what those governance milestones were generally designed to enforce.

244
00:20:45,260 --> 00:20:45,720
Yeah, yeah.

245
00:20:45,920 --> 00:20:47,060
That's interesting.

246
00:20:47,980 --> 00:20:52,680
And so I had a follow-up question, but I seem to have forgotten it.

247
00:20:53,100 --> 00:20:57,400
But it does seem like – well, on a somewhat related topic.

248
00:20:57,400 --> 00:21:02,160
So having been from BMC, I do a lot of sort of IT management following and coverage.

249
00:21:02,440 --> 00:21:16,700
And I've been noticing, especially with a lot of the sort of cloud computing talk that goes on nowadays, it seems like there's a lot of IT department and operations people who are sort of like discovering some ideas of agile, right?

250
00:21:17,020 --> 00:21:25,500
And it seems like there's some interesting potential for sort of agile operations, if you will, or like people applying agile things to setting up IT infrastructure.

251
00:21:25,500 --> 00:21:44,880
But pulling back a little bit to the here and now, especially since you said you were running a sort of an online identity sort of thing, I wonder how you've seen sort of the development team, like delivering fast iterations, fixing in with the IT department or the administrators who are just sort of the ones who – you know, this is the cynical way of putting it.

252
00:21:44,900 --> 00:21:48,460
But you throw the software over the wall, but you throw the software over the wall, and these people are in charge of making sure it's up and running.

253
00:21:48,900 --> 00:21:54,720
And, you know, it seems like even more so than PMO folks, these people don't want anything to change.

254
00:21:55,180 --> 00:21:58,920
I mean, their ideal world is I set something up and I never have to touch it again.

255
00:21:59,600 --> 00:22:19,600
I agree, and there are certainly challenges there, but I would have to say that I think the challenge there is more just coordination and cooperation with IT who has, you know, distinct milestones, you know, IP addresses they need to set up, servers they need to stand up, firewalls that need to be breached or whatever that can really affect your development model.

256
00:22:20,160 --> 00:22:25,760
And, you know, these ships generally run in largely, you know, parallel universes.

257
00:22:26,020 --> 00:22:28,060
IT actually has a fairly fast duty cycle.

258
00:22:28,500 --> 00:22:34,340
In many ways, you know, they can do things in some cases much faster than the development team laying down greenfield code.

259
00:22:34,780 --> 00:22:44,940
So what we try to do is basically invite them to play, and at the enterprise level, the invitation gets extended primarily at the release planning boundaries and try to kind of influence their model that way,

260
00:22:44,940 --> 00:22:49,960
make sure they have their stories and they know what iterations they're in, and influence them over time.

261
00:22:50,020 --> 00:22:56,900
Such as eventually, you know, they will tend to adopt the agile model, and I've got a couple cases right now where IT is getting it.

262
00:22:57,000 --> 00:22:59,880
They're involved, you know, after the third or fourth release planning session.

263
00:23:00,300 --> 00:23:01,220
They're doing better.

264
00:23:01,320 --> 00:23:02,540
They may have a daily stand-up.

265
00:23:02,700 --> 00:23:06,360
They know to attend the demos because they have stories for their IT work.

266
00:23:06,660 --> 00:23:08,080
So you can get them ingrained.

267
00:23:08,360 --> 00:23:19,840
I wouldn't say that, you know, the PMO, because we've taught them essentially our waterfall model over the last 20 or 30 years, in many ways is philosophically misaligned, you know, long-term.

268
00:23:19,880 --> 00:23:27,180
Big, you know, enterprise class, you know, aircraft carrier commitments.

269
00:23:27,960 --> 00:23:31,360
Because it's a huge commitment, then we have to have all the design done by March.

270
00:23:31,760 --> 00:23:34,160
You know, we've taught them models that don't work very well.

271
00:23:34,220 --> 00:23:36,480
I don't think we've taught IT models that don't work very well.

272
00:23:36,800 --> 00:23:41,920
I think IT has been largely on its own with their, you know, their kind of quick fixes and patches and upgrades, et cetera.

273
00:23:42,560 --> 00:23:45,400
So it's not a killer with IT.

274
00:23:45,600 --> 00:23:50,460
I think in some ways it's easier than the project office, especially if it's a pretty stiff project office.

275
00:23:50,960 --> 00:23:53,160
It's just one more impediment to work through.

276
00:23:53,660 --> 00:24:06,260
I would say that in general when you start the agile process and you increase the communication with those folks and you talk to them every day or every sprint, a lot of your fears really go away because it turns out, you know, their paycheck is exactly the same.

277
00:24:06,660 --> 00:24:08,060
They come from the same gene pool.

278
00:24:08,280 --> 00:24:09,340
They live in the same city.

279
00:24:09,600 --> 00:24:14,100
And even though they've been in this other department, they're really trying hard to do a good job.

280
00:24:14,580 --> 00:24:30,160
And when the development teams realize that they've also got to, you know, upgrade, you know, whatever, their whole IT infrastructure or, you know, a new vignette release at the same time that they've got to stand up this new server so I can deploy my new web application, you start to get an appreciation of the problem.

281
00:24:31,020 --> 00:24:35,320
And I think that appreciation causes each of you to look at each other a little bit differently.

282
00:24:35,500 --> 00:24:36,880
It's a less jaundiced eye.

283
00:24:37,240 --> 00:24:38,720
We're all working here and it's hard.

284
00:24:38,940 --> 00:24:42,740
And once you understand each other better, you can build trust because of the understanding.

285
00:24:43,140 --> 00:24:46,900
Whereas right now, you don't know what they're doing, but they're not doing the stuff you want them to do.

286
00:24:46,980 --> 00:24:48,640
And that doesn't matter which side of the fence you're on.

287
00:24:49,100 --> 00:24:50,320
The developers are working on stuff.

288
00:24:50,400 --> 00:24:52,920
They don't really understand what real deployed infrastructure is like.

289
00:24:53,660 --> 00:24:56,080
The IT people are doing God only knows what.

290
00:24:56,080 --> 00:25:02,260
They're upgrading Exchange server, but I can't get a web app stood up for the life of me.

291
00:25:02,740 --> 00:25:04,340
So really, just communication.

292
00:25:04,820 --> 00:25:05,680
Yeah, I mean, exactly.

293
00:25:06,000 --> 00:25:13,840
Both literally and figuratively, a lot of these, like you keep coming back to the problems get solved when you get to people in the same room for some amount of time.

294
00:25:14,040 --> 00:25:28,580
And just like have them understand each other, which for as much as we're probably both smiling about it, is an extremely difficult thing to do in the overall IT department with developers and all the different stakeholders and IT folks.

295
00:25:28,580 --> 00:25:30,560
But it was hard for us, too.

296
00:25:30,700 --> 00:25:38,060
I mean, we had firewalls or literal walls between developers and testers, and that was the test department, and you didn't go over there.

297
00:25:38,180 --> 00:25:47,820
And I know one organization that had this document they called Tech Specs, which as near as I can tell, were detailed design docs you wrote for the purpose of not having to actually talk to a tester.

298
00:25:48,680 --> 00:25:49,040
Exactly.

299
00:25:50,000 --> 00:25:54,980
So, you know, when you put those people together, yeah, it's awkward at first, but then pretty soon they're forming a team.

300
00:25:55,240 --> 00:26:00,900
And, you know, the face-to-face communication of the Agile Manifesto, that's a really big hit.

301
00:26:01,340 --> 00:26:06,040
And I don't think it was any easier to get our developers and testers to talk than it was to get IT ingrained.

302
00:26:06,420 --> 00:26:10,860
And I just look at it as a kind of a continuous envelope of enhanced communication.

303
00:26:11,240 --> 00:26:16,980
I tend to structure that around release planning, which is, you know, kind of my mantra, you know, the cyclical cadence.

304
00:26:17,160 --> 00:26:20,740
I think that, you know, release planning is for the enterprise what a sprint is for the team.

305
00:26:21,160 --> 00:26:29,720
And once I have that kind of cadence locked in, then I know when I need to talk to them, and I know what commitments I need to try to get from them and what commitments I need to deliver to them.

306
00:26:30,060 --> 00:26:32,640
And then all of a sudden, it's, you know, it's just one big team.

307
00:26:33,000 --> 00:26:40,080
So a lot of it is this, you know, this concentric circle of a small team, a little larger team, a team all the way through the PMO, and eventually the enterprise.

308
00:26:40,500 --> 00:26:43,120
It's just that it takes, you know, years to achieve that.

309
00:26:43,520 --> 00:26:50,920
You know, even if at all levels everybody wants to do the right thing and they know they want to be more agile, I think one of the problems we face is who doesn't want to be more agile, right?

310
00:26:51,340 --> 00:26:53,780
Oh, of course, we want to be more agile, but what does that mean?

311
00:26:54,300 --> 00:26:59,860
So it's just, you know, a growing ring of influence that starts in my mind with the credibility of the team.

312
00:27:00,040 --> 00:27:03,440
Yeah, everyone loves a homemade pie, but no one wants to cook it.

313
00:27:03,900 --> 00:27:10,940
One of the groups I was with, we basically were doing our release planning, and we were multiplexing between kind of too many code lines.

314
00:27:11,360 --> 00:27:14,480
And we decided that it would be best if we would, you know, kill one.

315
00:27:14,580 --> 00:27:20,980
And in so doing, there were going to be some pains, and there was going to be this deliverable plan that might not happen on the plan that we had.

316
00:27:21,000 --> 00:27:27,700
And we went and discussed that with the CEO, and basically it was kind of funny because he didn't think the team was going to be on time anyway.

317
00:27:28,260 --> 00:27:32,100
So when they came up with a credible way to improve their performance, he supported it fully.

318
00:27:32,400 --> 00:27:36,860
So we didn't even have enough credibility in that case to make good arguments.

319
00:27:37,260 --> 00:27:44,780
So you start by regaining that credibility by getting, you know, the essence of trust generally is to make a commitment, meet your commitment to somebody.

320
00:27:45,320 --> 00:28:01,400
So if a team can say, okay, in two weeks we're going to do this, and they do it, and then 10 teams do it, and then 30 teams do it, and then that thing becomes, you know, a big increment, an internal release, or maybe even a release, then the whole organization says, wow, I think we can trust these guys.

321
00:28:01,400 --> 00:28:11,540
And by the way, they have some issues to discuss, versus, hey, they're the developers, they're always late, code quality is crap, and they're telling us we need to change our behavior.

322
00:28:12,180 --> 00:28:17,420
Yeah, no one really trusts what they regard to be a bunch of bozos, so you have to establish that credibility.

323
00:28:19,120 --> 00:28:29,480
It's almost, you know, you have to use the old sort of like the positive transference of negative energy or like judo stuff to basically pander to low expectations ahead of time.

324
00:28:29,480 --> 00:28:41,280
Like if this person doesn't think you're ever going to deliver anyways, then even if you do like half a bad of a job as you could do, that's still tons more than they thought was possible, and you can just will down until you actually do a good job.

325
00:28:42,160 --> 00:28:59,040
Undercommit and overperform, and then when you engage with teams, they have all these huge worries, you know, like the PMO and milestones and what are we going to do about IT, and, you know, I generally put those worries aside, and I have to say is that when the teams are performing, those worries come into context, and also they evolve.

326
00:28:59,480 --> 00:29:04,020
So the fear that you had, and I know a number of situations where we feared that this would be a big challenge.

327
00:29:04,100 --> 00:29:10,780
By the time we got there, it wasn't, and something else was in its place, but none of it really matters until a team of teams can actually build some software that works.

328
00:29:11,320 --> 00:29:22,920
So you just try to talk to the teams, let's not worry about that, let's get some credibility, let's see what we can do in two weeks or a sprint or 60 days, and, you know, in maybe six months or so, we'll be fairly decent at that.

329
00:29:23,480 --> 00:29:27,760
And by nine months, we're going to have real credibility, and then the impediments will actually be more obvious.

330
00:29:27,900 --> 00:29:29,800
They'll start to be seen before we even get there.

331
00:29:30,080 --> 00:29:35,460
It's not like the rest of the institution is stupid, you know, the buzz and the rumor mill and all the politics.

332
00:29:35,700 --> 00:29:39,560
They'll work in advance, and people will see those things coming, and the problems will actually move.

333
00:29:39,960 --> 00:29:49,180
So if you started a natural transformation, you said our problem is A, B, and C, and yet the teams couldn't yet write code that worked, by the time you get there, they're going to be D, E, and F.

334
00:29:49,340 --> 00:29:50,360
So why bother?

335
00:29:50,980 --> 00:29:57,680
You know, it's not the last responsible moment to worry about that next-level problem when you're trying to get a team to write good quality code that works.

336
00:29:57,700 --> 00:30:01,320
Yeah, yeah, there's no sense building road humps when you don't even have roads yet.

337
00:30:01,600 --> 00:30:03,300
It seems like the main issue.

338
00:30:03,380 --> 00:30:08,900
Well, great, well, unless there was anything else you wanted to mention, I think we had a nice little episode there.

339
00:30:09,360 --> 00:30:16,120
No, it's, you know, I kind of talked about the things that I'm currently engaged in, and you got your questions in, so I'm good if you are.

340
00:30:16,280 --> 00:30:16,980
Well, that sounds great.

341
00:30:17,040 --> 00:30:19,300
Well, thanks so much for spending this time to talk with us today.

342
00:30:19,560 --> 00:30:20,540
That was good stuff.