Dana Gardner's BriefingsDirect: Case study: How McKesson develops software faster and better with innovative use of new HP ALM 11 suite

Thursday, January 6, 2011

Case study: How McKesson develops software faster and better with innovative use of new HP ALM 11 suite

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: HP.

Welcome to a special BriefingsDirect podcast series in conjunction with the recent HP Software Universe 2010 Conference in Barcelona.

At the conference we explored some major enterprise software and solutions, trends and innovations making news across HP’s ecosystem of customers, partners, and developers. [See more on HP's new ALM 11 offerings.]

Now, this customer case-study from the conference 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 interviewed Todd Eaton, Director of ALM Tools and Services at McKesson. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Here are some excerpts:

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.

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.

Better status

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.

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.

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.

Company profile

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.

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.

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

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.

Partner tools

There are partner tools that go along with ALM 11 that help us meet 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.

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.

Something that we've done at McKesson that appears to work out real well [is devote a team to managing the ALM tools themselves]. 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.