Thursday, January 06, 2011

Case Study: How McKesson Develops Software Faster and Better with Innovative Use of New HP ALM 11 Suite

Transcript of a sponsored BriefingsDirect podcast, part of a series on application lifecycle management and HP ALM 11 from the recent HP Software Universe 2010 conference in Barcelona.


Dana Gardner: Hello, and welcome to a special BriefingsDirect podcast series, coming to you in conjunction with the HP Software Universe 2010 Conference last month in Barcelona.



Our customer case study today focuses on McKesson and how their business has benefited from advanced application lifecycle management (ALM). To learn more about McKesson's innovative use of ALM and its early experience with HP's new ALM 11 release, I'm here with Todd Eaton, Director of ALM Tools and Services at McKesson. Welcome, Todd.

Todd Eaton: Thanks, Dana.

Gardner: I know you've been involved with ALM for quite some time, but what is it about ALM now in your business that makes it so important and beneficial?

Eaton: In our business at McKesson, we have various groups that develop software, not only for internal use, but also external use by our customers and software that we sell. We have various groups within McKesson that use the centralized tools, and the ALM tools are pretty much their lifeblood. As they go through the process to develop the software, they rely heavily on our centralized tools to help them make better software faster.

Gardner: Is ALM something you use within the groups -- and then also to bind those groups; that is to say, there is a tactical ... and then even strategic benefit as well?

Eaton: Yes. The ALM suite that HP came out with is definitely giving us a bigger view. We've got QA managers that are in the development groups for multiple products, and as they test their software and go through that whole process, they're able to see holistically across their product lines with this.

We've set up projects with the same templates. With that, they have some cohesion and they can see how their different applications are going in an apples-to-apples comparison, instead of like the old days, when they had to manually adjust the data to try to figure out what their world was all about.

Gardner: At this point, are there any concrete benefits, either in terms of business benefits, or in the IT application development side of the business that you can point to that these ALM innovations have supported?

Better status

Eaton: There are a couple of them. When HP came up with ALM 11, they took Quality Center and Performance Center and brought them together. That's the very first thing, because it was difficult for us and for the QA managers to see all of the testing activities. With ALM, they're able to see all of it and better gauge where they are in the process. So, they can give their management or their teams a better status of where we are in the testing process and where we are in the delivery process.

The other really cool thing that we found was the Sprinter function. We haven't used it as much within McKesson, because we have very specific testing procedures and processes. Sprinter is used more as you're doing ad hoc testing. It will record that so you can go back and repeat those.

How we see that being used is by extending that to our customers. When our customers are installing our products and are doing their exploratory testing, which is what they normally do, we can give them a mechanism to record what they are doing. Then, we can go back and repeat that. Those are a couple of pretty powerful things in the new release that we plan to leverage.

Gardner: How would you describe the problem that we need to solve here? Is this a problem of communication, of measurement, perhaps workflow management, or all the above? How would you characterize what's wrong with how application development has been done? I don't mean to point to you as falling short on this at all. This is a general issue, but what is the problem that you think ALM is really addressing?

Eaton: That's a good point. When we're meeting at various conferences and such, there's a common theme that we hear. One is workflow. That's a big piece. ALM goes a long way to be able to conquer the various workflows. Within an organization, there will be various workflows being done, but you're still able to bring up those measurements, like another point that you are bringing up, and have a fairly decent comparison.

They can find those defects earlier, verify that those are defects, and there is less of that communication disconnect between the groups.

With the various workflows in the past, there used to be a real disparate way of looking at how software is being developed. But with ALM 11, they're starting to bring that together more.

The other piece of it is the communication, and having the testers communicate directly to those development groups. There is a bit of "defect ping-pong," if you will, where QA will find a defect and development will say that it's not a defect. It will go back and forth, until they get an agreement on it.

ALM is starting to close that gap. We're able to push out the use of ALM to the development groups, and so they can see that. They use a lot of the functions within ALM 11 in their development process. So, they can find those defects earlier, verify that those are defects, and there is less of that communication disconnect between the groups.

Gardner: It sounds like it’s beginning to quicken the pace of how you go about these things, but in addition to that, are you exploiting agile development practices, and is this something that's helping you if you are?

Eaton: We have several groups within our organization that use agile development practices. What we're finding is that the way they're doing work can integrate with ALM 11. The testing groups still want to have an area where they can put their test cases, do their test labs, run through their automation, and see that holistic approach, but they need it within the other agile tools that are out there.

It's integrating well with it so far, and we're finding that it lends itself to that story of how those things are being done, even in the agile development process.

Gardner: You're a large organization, a large healthcare provider and insurer. Maybe you could tell us a little bit about McKesson, where you're based, and the size and extent of your application development organization.

Company profile

Eaton: McKesson is a Fortune 15 company. It is the largest health-care services company in the U.S. We have quite a few R&D organizations and it spans across our two major divisions, McKesson Distribution and McKesson Technology solutions.

In our quality center, we have about 200 projects with a couple of thousand registered users. We're averaging probably about 500 concurrent users every minute of the day, following-the-sun, as we develop. We have development teams, not only in the U.S, but nearshore and offshore as well.

We're a fairly large organization, very mature in our development processes. In some groups, we have new development, legacy, maintenance, and the such. So, we span the gamut on all the different types of development that you could find.

Gardner: Well, that's interesting, because I wanted to explore the size of the organization. It sounded a moment ago as if you were able to support different styles, different cultures, different maturity levels, as you have mentioned, among and between these different parts of your development cycle, all using the same increasingly centralized ALM approach. Is that fair?

Eaton: Yeah, that's fair. That's what we strive for. In my group, we provide the centralized R&D tools. ALM 11 is just one of the various tools that we use, and we always look for tools that will fit multiple development processes.

They have to adapt to all that, and we needed to have tools that do that, and ALM 11 fits that bill.

We also make sure that it covers the various technology stacks. You could have Microsoft, Java, Flex, Google Web Toolkit, that type of thing, and they have to fit that. You also talked about maturity and the various maturity models, be it CMMI, ITIL, or when you start getting into our world, we have to take into consideration FDA.

When we look at tools, we look at those three and at deployment. Is this going to be internally used, is this going to be hosted and used through an external customer, or are we going to package this up and send it out for sale?

We need tools that span across those four different types, four different levels, that they can adapt into each one of them. If I'm a Microsoft shop that’s doing Agile for an internal developed software, and I am CMMI, that's one. But, I may have a group right next door that's waterfall developing on Java and is more an ITIL based, and it gets deployed to a hosted environment.


Gardner: So, it's the benefits of decentralized and the benefits of centralized in terms of the system-of-record approach, having at least a metaview of what's going on, even though there is still flexibility at the edge.

Eaton: Correct. ALM 11 had a good foundation. The test cases, the test set, the automated testing, whether functional or performance, the source of truth for that is in the ALM 11 product suite. And, it's fairly well-known and recognized throughout the company. So, that is a good point. You have to have a source of truth for certain aspects of your development cycle.

Gardner: Of course, your industry has significant level of regulation and compliance issues. Is ALM 11 something that's been a benefit in that regard?

Partner tools

Eaton: It has been a benefit. There are partner tools that go along with ALM 11 that help us meet those various regulations. Something that we're always mindful of, as we develop software, is not only watching out for the benefit of our customers and for our shareholders, but also we understand the regulations. New ones are coming out practically every day, it seems. We try to keep that in mind, and the ALM 11 tool is able to adapt to that fairly easily.

Gardner: You've been an early adopter. You've implemented certain portions of ALM 11, and you have a great deal of experience with ALM as a function. Looking back on your experience, what would you offer as advice to someone who might just be getting their feet wet in regard to either ALM or specifically ALM 11?

Eaton: When I talk to other groups about ALM 11 and what they should be watching out for, I tell them to have an idea of how your world is. Whether you're a real small shop, or a large organization like us, there are characteristics that you have to understand. How I identify those different stacks of things that they need to watch out for; they need to keep in mind their organization’s pieces that they have to adapt to. As long as they understand that, they should be able to adapt the tool to their processes and to their stacks.

Most of the time, when I see people struggling, it's because they couldn’t easily identify, "This is what we are, and this is what we are dealing with." They usually make midstream corrections that are pretty painful.

Gardner: And your title is interesting to me, Todd: Director of ALM Tools and Services. This is an organizational question, I suppose. Do you think it is a good policy, now that you have had experience in this, to actually devoting an individual or maybe a team to just overseeing the ALM tools, which in fact oversees the ALM process?

They look to us to be able to offload that and have a team to do that.

Eaton: That's an interesting point, and something that we've done at McKesson that appears to work out real well. When I deal with various R&D vice presidents and directors, and testing managers and directors as well, the thing that they always come back to is that they have a job to do. And one of the things they don't want to have to deal with is trying to manage a tool.

They've got things that they want to accomplish and that they're driven by: performance reviews, revenue, and that type of thing. So, they look to us to be able to offload that, and to have a team to do that.

McKesson, as I said, is fairly large, thousands of developers and testers throughout the company. So, it makes sense to have a fairly robust team like us managing those tools. But, even in a smaller shop, having a group that does that -- that manages the tools -- can offload that responsibility from the groups that need to concentrate on creating code and products.

Gardner: Well, great. Thank you for sharing your experiences. We've been hearing about ALM best practices and the use of HP's new ALM 11 by an early adopter and his experience, Todd Eaton, Director of ALM Tools and Services at McKesson. Thank you, Todd.

Eaton: You're welcome, Dana. It was nice talking to you.

Dana Gardner: I want to thank also our listeners for joining the special BriefingsDirect podcast, coming to you in conjunction with the HP Software Universe 2010 Conference.

Look for other podcasts from this event on the website, as well as via the BriefingsDirect network.



Transcript of a sponsored BriefingsDirect podcast, part of a series on application lifecycle management and HP ALM 11 from the HP Software Universe 2010 conference in Barcelona, Spain. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

No comments:

Post a Comment