Here we are at the BMC Austin campus. Would you like to introduce yourself? Hello, I'm Israel Gart. I'm the Vice President in charge of Distributed System Management for BMC. And so what exactly is your umbrella there for Distributed Systems Management? There are three product lines, actually. The first product line is monitoring. You may know of our classic product here, Patrol Classic. We now have a more modern offering using today's technology called BMC Performance Manager or BPM for short. The second product line is about event and impact management. 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. 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. 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. And I've talked with Chip Holden, one of my colleagues at the time and an architect now about that a couple of times. 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? There was no grand plan. The plan was actually to start small and see how it goes. However, and as a matter of fact, the first two projects had nothing to do with BPM whatsoever. 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.
2:01And we decided that we are willing to take architectural changes simultaneously with methodical changes instead of taking each dimension, so to speak, separately. 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. So after a little bit of a top-down effort, most of the work was done bottom-up. 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. The results, as we know from a recent Qatar Consortium study, is that we are about faster in implementing than 97% of the projects. 7,000 or so that are kept in the metrics database of the so-called slim metrics database of the Qatar Consortium. So the rewards that we got in terms of after three short years of implementing a child, the rewards are very, very significant. 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. And I would certainly say this has been our experience and his experience has been that this was happening with other companies as well. So I'm curious as you started with those two base projects and you moved on to BPM and applied it to other projects. 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.
4:01And so I wonder, like, what you sort of figured out from experience are sort of the best, to use an old metaphor, 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. 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, is not necessarily the right prescription, so to speak, to a team in Pune, India, who is trying to do it. 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. Namely, I would make certain that the teams would have whatever they need, for example, software, for example, consulting services, and that we should be doing the important methodical things like retrospectives in, you know, in a rigorous manner. At the same time, the bigger part of, you know, as of the time that we got traction, the bigger part of my activity was around writing papers and giving presentations of the subject, publishing about, you know, publishing about the topic, encouraging people in the organization to go into more and more industry forums to present what we do and to learn from other people, making my superiors, my peers, and other people who had the interest, know our experience. So, actually I had to do very little in terms of directing. Inward facing, as it were. Yeah. It picked up after a short period, pretty much on its own.
6:03And the fact of the matter, people like Paul Beavers and Walter Botwell perfected it in ways which were unforeseen, by Rally Software Development with whom we were working at the time, and by myself. And I would say the variant of a child that we use today at BMC is quite, you know, quite a special variant, very possibly very different from other people's implementation of the child. Yeah. What do you think some of those differences are? 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. 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. We only use one backlog. As a result, we were able really to harness themes which are geographically far apart into the overall effort. Rather than creating some kind of segregation, you only do X and you don't know anything beyond. The small act of a unified backlog across all sites which work on a project turned out to pay huge dividends. 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. 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. 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.
8:08And we might have pretty soon a variant of agile where you have two dimensions to play with. One being the backlog itself and the other one being the time EU, RTM or G8. 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. Right. And so it's not in the classical theory of agile. 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. Whereas, you know, what you're used to is it being exactly the opposite where you're not getting the software out quickly enough. 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. 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. 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. Right. 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.
10:10They have a degree of freedom of taking it at the right point. Another thing that we should probably pretty soon get into is the business of segment of one or market of one. 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. 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. 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. And in a month, we should show you a mature demo. Would I have you check after we do that? Because you will be getting the whole thing in two months. This is a very strong sales technique. 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. 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? I would say we have already a list of 95 customers that we support beyond the call of duty. This is the so-called TLC program where we assign a person from engineering to accompany the customer and the account team. 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. I would say this possibly could be a very good start.
12:12Namely, if you were to say to those 95 customers, look, in addition to the extra level of support that we provide you, 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. Right. 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. Right. 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. That's right. So to me this is taking this kind of very, very powerful technique and moving it into the software arena. In your experience, how does that compare toward to sort of the more traditional way of going about enterprise software sales? What, the way we usually do it is we send a lot of professional services people to the customer side to do the customizations. Right. Here we are changing the paradigm. We will be doing it straight from the lab. So the customization, it's not only in terms of work to be conducted on the customer premises. The customization is straight from the R&D lab with all of the advantages. For example, we can test it much more rigorously that it can be tested on, it can be tested on premises, etc. 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,
14:22interaction. It's straight from the customer to R&D and rank. Yeah. 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. And, you know, we all have our filters. 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. An engineer on the team hearing you need their own or their own ears. Right. Deciding from the customer, I want it this way and I want it that way. And going ahead and implementing it. You could think about it in some ways as going back to craftsmanship. 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. So the ability to respond genuinely and accurately to what the customer really wants, I think is very, very powerful.