1
00:00:00,000 --> 00:00:06,000
Here we are at the BMC Austin campus. Would you like to introduce yourself?

2
00:00:06,000 --> 00:00:13,000
Hello, I'm Israel Gart. I'm the Vice President in charge of Distributed System Management for BMC.

3
00:00:13,000 --> 00:00:19,000
And so what exactly is your umbrella there for Distributed Systems Management?

4
00:00:19,000 --> 00:00:25,000
There are three product lines, actually. The first product line is monitoring.

5
00:00:25,000 --> 00:00:32,000
You may know of our classic product here, Patrol Classic.

6
00:00:32,000 --> 00:00:41,000
We now have a more modern offering using today's technology called BMC Performance Manager or BPM for short.

7
00:00:41,000 --> 00:00:46,000
The second product line is about event and impact management.

8
00:00:46,000 --> 00:00:56,000
It basically utilizes the data coming from the first product line in order to give deeper meaning of what is going on for the customer.

9
00:00:56,000 --> 00:01:08,000
And the third one is Distributed Recovery. Once something has gone bad and I need to recover my operations, this is a set of techniques and tools which enable you to do this.

10
00:01:08,000 --> 00:01:15,000
When you came here, one of the main things that trickled down to affect me was we started switching over to doing Agile software development.

11
00:01:15,000 --> 00:01:21,000
And I've talked with Chip Holden, one of my colleagues at the time and an architect now about that a couple of times.

12
00:01:21,000 --> 00:01:30,000
And I'm curious, when you first came in, what was sort of your plan as far as how you were going to apply Agile?

13
00:01:30,000 --> 00:01:39,000
There was no grand plan. The plan was actually to start small and see how it goes.

14
00:01:39,000 --> 00:01:49,000
However, and as a matter of fact, the first two projects had nothing to do with BPM whatsoever.

15
00:01:49,000 --> 00:02:01,000
However, what happened is that at a certain point in time, Mary Smart, who was my boss at the time, was quite interested in accelerating the speed of BPM.

16
00:02:01,000 --> 00:02:12,000
And we decided that we are willing to take architectural changes simultaneously with methodical changes instead of taking each dimension, so to speak, separately.

17
00:02:12,000 --> 00:02:27,000
And at this point in time, the other thing that was very lucky, many of the people in Walter Bodwell's team had done Agile or Quasi-Agile in the past and were very anxious to come back to it.

18
00:02:27,000 --> 00:02:33,000
So after a little bit of a top-down effort, most of the work was done bottom-up.

19
00:02:33,000 --> 00:02:45,000
And people did it not because I or anyone else said you have got to do it, but because they really had their heart in it.

20
00:02:45,000 --> 00:02:58,000
The results, as we know from a recent Qatar Consortium study, is that we are about faster in implementing than 97% of the projects.

21
00:02:58,000 --> 00:03:09,000
7,000 or so that are kept in the metrics database of the so-called slim metrics database of the Qatar Consortium.

22
00:03:09,000 --> 00:03:21,000
So the rewards that we got in terms of after three short years of implementing a child, the rewards are very, very significant.

23
00:03:21,000 --> 00:03:36,000
Michael Mamma himself, the Qatar Consortium, consultant with whom we work, is starting to talk in terms of phenomenon that after two years of a child, the speed starts being phenomenal.

24
00:03:36,000 --> 00:03:44,000
And I would certainly say this has been our experience and his experience has been that this was happening with other companies as well.

25
00:03:44,000 --> 00:03:51,000
So I'm curious as you started with those two base projects and you moved on to BPM and applied it to other projects.

26
00:03:51,000 --> 00:04:01,000
I've never found the role of someone in your position documented extremely well, as opposed to the role of the ongoing team and so forth.

27
00:04:01,000 --> 00:04:08,000
And so I wonder, like, what you sort of figured out from experience are sort of the best, to use an old metaphor,

28
00:04:08,000 --> 00:04:18,000
sort of the best ways you can pull the levers or sort of direct things or, I don't know, essentially what role your leadership plays when you're taking a bottom-up approach to using Agile.

29
00:04:18,000 --> 00:04:28,000
Well, you would laugh, I think the most important thing is staying out of the way, namely the fact that I happen to do it or like to do it in a certain way,

30
00:04:28,000 --> 00:04:37,000
is not necessarily the right prescription, so to speak, to a team in Pune, India, who is trying to do it.

31
00:04:37,000 --> 00:04:52,000
So once I saw that bottom-up was really catching up big time, I primarily focused on being an evangelist for the methodology within BMC and outside BMC.

32
00:04:52,000 --> 00:05:01,000
Namely, I would make certain that the teams would have whatever they need, for example, software, for example, consulting services,

33
00:05:01,000 --> 00:05:12,000
and that we should be doing the important methodical things like retrospectives in, you know, in a rigorous manner.

34
00:05:12,000 --> 00:05:19,000
At the same time, the bigger part of, you know, as of the time that we got traction,

35
00:05:19,000 --> 00:05:35,000
the bigger part of my activity was around writing papers and giving presentations of the subject, publishing about, you know, publishing about the topic,

36
00:05:35,000 --> 00:05:44,000
encouraging people in the organization to go into more and more industry forums to present what we do and to learn from other people,

37
00:05:44,000 --> 00:05:51,000
making my superiors, my peers, and other people who had the interest, know our experience.

38
00:05:51,000 --> 00:05:57,000
So, actually I had to do very little in terms of directing.

39
00:05:57,000 --> 00:05:59,000
Inward facing, as it were.

40
00:05:59,000 --> 00:06:03,000
Yeah. It picked up after a short period, pretty much on its own.

41
00:06:03,000 --> 00:06:10,000
And the fact of the matter, people like Paul Beavers and Walter Botwell perfected it in ways which were unforeseen,

42
00:06:10,000 --> 00:06:17,000
by Rally Software Development with whom we were working at the time, and by myself.

43
00:06:17,000 --> 00:06:27,000
And I would say the variant of a child that we use today at BMC is quite, you know, quite a special variant,

44
00:06:27,000 --> 00:06:32,000
very possibly very different from other people's implementation of the child.

45
00:06:32,000 --> 00:06:33,000
Yeah.

46
00:06:33,000 --> 00:06:34,000
What do you think some of those differences are?

47
00:06:34,000 --> 00:06:43,000
I would say they may look trivial, or the example I'm going to give you might look trivial, but it makes all the difference in the world.

48
00:06:43,000 --> 00:06:54,000
For example, we have a single unified backlog for all the sites, whether they are in the continental United States or whether they are not.

49
00:06:54,000 --> 00:06:55,000
We only use one backlog.

50
00:06:55,000 --> 00:07:04,000
As a result, we were able really to harness themes which are geographically far apart into the overall effort.

51
00:07:04,000 --> 00:07:12,000
Rather than creating some kind of segregation, you only do X and you don't know anything beyond.

52
00:07:12,000 --> 00:07:21,000
The small act of a unified backlog across all sites which work on a project turned out to pay huge dividends.

53
00:07:21,000 --> 00:07:36,000
The other thing, and here at DAIL, Pundits might be a little upset at me, we are actually looking at whether the deadline of a project in certain cases should be relaxed.

54
00:07:36,000 --> 00:07:50,000
Namely, we have done such a good progress in terms of agility and speed over the past few years that now we are oftentimes in a situation where marketing and sales are not too happy to get too many new releases in a given year.

55
00:07:50,000 --> 00:08:08,000
So, the business of the adherence to a strict deadline and only playing on the dimension of which features will and which features will not be included is something that we are more and more looking into relaxing.

56
00:08:08,000 --> 00:08:15,000
And we might have pretty soon a variant of agile where you have two dimensions to play with.

57
00:08:15,000 --> 00:08:26,000
One being the backlog itself and the other one being the time EU, RTM or G8.

58
00:08:26,000 --> 00:08:37,000
And I think as long as we maintain the high professionalism that we have been maintaining, are maintaining here, this could be quite an appropriate trade-off to strike.

59
00:08:37,000 --> 00:08:38,000
Right.

60
00:08:38,000 --> 00:08:40,000
And so it's not in the classical theory of agile.

61
00:08:40,000 --> 00:08:57,000
Yeah, there was always an interesting, I don't want to say counter-intuitive is the wrong word, but it's something where potentially, and it sounds like in your case, the software development organization is sort of producing software faster than the rest of the organization wants to deal with it.

62
00:08:57,000 --> 00:09:03,000
Whereas, you know, what you're used to is it being exactly the opposite where you're not getting the software out quickly enough.

63
00:09:03,000 --> 00:09:22,000
And so I've always, I've always been curious sort of how you sort of adapt the rest of the organization to the agile, the agile processes that you're using as far as it's sort of leading into the sales organization if they sort of can take that rapid delivery of software or if they need the big bang approach to that.

64
00:09:22,000 --> 00:09:38,000
The way we try to harmonize two different frequencies is by the paradigm that marketing itself do not necessarily need to use each and every release we produce.

65
00:09:38,000 --> 00:09:57,000
So the fact that we pretty soon in October issue release 2.5 of BPM is not necessarily a reason for marketing to put millions and millions of dollars into promoting it and sales to run with it full speed ahead.

66
00:09:57,000 --> 00:09:58,000
Right.

67
00:09:58,000 --> 00:10:10,000
So the need of the operating system to operate at its own frequency, in my opinion, does not stand in the way of ourselves producing more and more.

68
00:10:10,000 --> 00:10:14,000
They have a degree of freedom of taking it at the right point.

69
00:10:14,000 --> 00:10:21,000
Another thing that we should probably pretty soon get into is the business of segment of one or market of one.

70
00:10:21,000 --> 00:10:35,000
Namely, we have got at this point in time the velocity that would enable us for major customers to tailor releases, not only iterations, but full releases to their own requirements.

71
00:10:35,000 --> 00:10:46,000
So the ability to move ahead very, very fast when it comes to the needs of the customer, this is usually a major selling point.

72
00:10:46,000 --> 00:10:58,000
So being able to tell to the customer, look, we should come back here in two weeks and we should show you a crude, you know, a crude demo of requirements XYZ.

73
00:10:58,000 --> 00:11:01,000
And in a month, we should show you a mature demo.

74
00:11:01,000 --> 00:11:04,000
Would I have you check after we do that?

75
00:11:04,000 --> 00:11:07,000
Because you will be getting the whole thing in two months.

76
00:11:07,000 --> 00:11:12,000
This is a very strong sales technique.

77
00:11:12,000 --> 00:11:25,000
And while there is commonality amongst the requirement of various customers, the ability to tailor that to their own very, very specific needs, I think is of great value.

78
00:11:25,000 --> 00:11:35,000
How do you segment out the customers that you'll do that sort of, the customer of one for versus people that, I mean, when do you make the decision that we'll customize the software for you?

79
00:11:35,000 --> 00:11:44,000
I would say we have already a list of 95 customers that we support beyond the call of duty.

80
00:11:44,000 --> 00:11:55,000
This is the so-called TLC program where we assign a person from engineering to accompany the customer and the account team.

81
00:11:55,000 --> 00:12:09,000
And the responsibility of the person is to not only know our products that the customer uses very well, but know the configuration and the issues that the customer shows very well.

82
00:12:09,000 --> 00:12:12,000
I would say this possibly could be a very good start.

83
00:12:12,000 --> 00:12:18,000
Namely, if you were to say to those 95 customers, look, in addition to the extra level of support that we provide you,

84
00:12:18,000 --> 00:12:41,000
in addition to extra level of support that we will be providing you, we will be taking your requirements and embedding them in our product in a much faster clip than you normally did.

85
00:12:41,000 --> 00:12:42,000
Right.

86
00:12:42,000 --> 00:12:56,000
I would say this would be a very good, you know, a very good way of utilizing a job to the, what was at the time, a desire but not a reality among internet circles to move into market and run.

87
00:12:56,000 --> 00:12:57,000
Right.

88
00:12:57,000 --> 00:13:17,000
So I see it's not any different from various clothing outfits where, you know, I can give them my measures and they would be producing, let's say, my jacket or my pants or something for me according to how slim I am or how unslim I am.

89
00:13:17,000 --> 00:13:18,000
That's right.

90
00:13:18,000 --> 00:13:26,000
So to me this is taking this kind of very, very powerful technique and moving it into the software arena.

91
00:13:26,000 --> 00:13:32,000
In your experience, how does that compare toward to sort of the more traditional way of going about enterprise software sales?

92
00:13:32,000 --> 00:13:40,000
What, the way we usually do it is we send a lot of professional services people to the customer side to do the customizations.

93
00:13:40,000 --> 00:13:41,000
Right.

94
00:13:41,000 --> 00:13:43,000
Here we are changing the paradigm.

95
00:13:43,000 --> 00:13:45,000
We will be doing it straight from the lab.

96
00:13:45,000 --> 00:13:53,000
So the customization, it's not only in terms of work to be conducted on the customer premises.

97
00:13:53,000 --> 00:13:58,000
The customization is straight from the R&D lab with all of the advantages.

98
00:13:58,000 --> 00:14:08,000
For example, we can test it much more rigorously that it can be tested on, it can be tested on premises, etc.

99
00:14:08,000 --> 00:14:22,000
So to me this is not a twist on doing professional services projects for the customer, but this is really a total change in the kind of, you know, kind of,

100
00:14:22,000 --> 00:14:23,000
interaction.

101
00:14:23,000 --> 00:14:28,000
It's straight from the customer to R&D and rank.

102
00:14:28,000 --> 00:14:29,000
Yeah.

103
00:14:29,000 --> 00:14:40,000
I guess that is the main difference is there's not a, you're sort of removing a layer between the people using the software and the people writing the software and tightening the gap between the two as it were.

104
00:14:40,000 --> 00:14:42,000
And, you know, we all have our filters.

105
00:14:42,000 --> 00:14:51,000
So while the filter along the way are very, very intentioned, the fact of the matter is there is no substitute to an engineer on the team.

106
00:14:51,000 --> 00:14:54,000
An engineer on the team hearing you need their own or their own ears.

107
00:14:54,000 --> 00:14:55,000
Right.

108
00:14:55,000 --> 00:14:58,000
Deciding from the customer, I want it this way and I want it that way.

109
00:14:58,000 --> 00:15:00,000
And going ahead and implementing it.

110
00:15:00,000 --> 00:15:04,000
You could think about it in some ways as going back to craftsmanship.

111
00:15:04,000 --> 00:15:25,000
Namely, the craftsman, namely the software engineer, has the opportunity to learn precisely what the customer wants rather than having a digested list of requirements from hundreds of customers based on a lot of work that has been done by the various layers in between.

112
00:15:25,000 --> 00:15:33,000
So the ability to respond genuinely and accurately to what the customer really wants, I think is very, very powerful.