Borland's Own ‘Journey' to Agile Development Forms Real-World Foundation for New Software Delivery Management Solutions

Transcript of BriefingsDirect podcast on Agile Development principles and practices with Borland Software.

Listen to the podcast. Sponsor: Borland Software.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today we present a sponsored podcast discussion about Agile software development.

We're going to be talking to a software executive from Borland Software about Borland's own Agile “journey.” They deployed Agile practices and enjoyed benefits from that, as well as gained many lessons learned, as they built out their latest application lifecycle management (ALM) products. [See product and solution rundowns.]

We're going to talk with Pete Morowski, the senior vice president of research and development (R&D) at Borland Software. Welcome to the show, Pete.

Peter Morowski: Thank you, Dana. It's good to be here.

Gardner: Before you get into Borland Software's journey, I want to get a level-set about Agile Development practices in general. Why is Agile development a good idea now? What is it about the atmosphere in the evolution of development that makes this timely?

Morowski: From the standpoint of software development, it's a realization that development is an empirical process, a process of discovery. Look at the late delivery cycles that traditional waterfall methodologies have brought upon us. Products have been delivered and end up on the shelf. The principles behind Agile right now allow teams to deliver on a much more frequent cycle and also to deliver more focused releases.

Gardner: There are also, I suppose, technical and business drivers: better quality, faster turnaround, more complexity, and, of course, distributed teams. What is it about the combination? Why is this important now in terms of some of these other technical business and even economic imperatives?

Morowski: With the advent of Web applications, businesses really expect a quicker turnaround time. In addition, when you look at cost structures, the time spent on features not used and other things are critical business inhibitors at this point.

Gardner: Let's help out some folks out who might not be that familiar with Agile and its associated process called Scrum. Tell us a little bit from an elevator-pitch perspective. What is Agile and what is Scrum?

Morowski: Agile really is a set of principles, and these principles are based on things like self-directed teams, using working code as a measure of progress, and also looking at software development in terms of iteration. What we mean by that is that when you look at traditional software development, we talked about things like design, code, and testing as actual phases in a development lifecycle. Within Agile, in an iteration, these are just activities that occur in each iteration.

Now, when you talk about Scrum, that is more of a process and a methodology. This is actually taking those Agile principles and then being more prescriptive on how to apply them to a software-development cycle.

In the case of Scrum, it's based upon a concept called a sprint, which is a two-to-four week iteration that the team plans for and then executes. In that two-to-four weeks, whatever they get done is considered completed during that sprint, and what work hadn't been completed goes into what they call "product backlog" for prioritization on what is done in the next sprint. You chain these several iterations together for a release.

The beauty of this is that now you have a way to induce change on the borders of those iterations. So, one of the things that's really advantageous to Agile is its ability to adapt the changing requirements.

Gardner: When I try to explain Agile to people, some of them come away thinking that it's an oxymoron or is conflicted because they say, "Okay, your goal is to do things better and faster, but you are telling people use fewer rules, use less structure, and have your teams be self-selecting." People see a conflict here. Why isn't that a conflict?

Morowski: I think it's a misnomer that self-directed teams and that type of thing mean that we can do whatever we want. What it's really about is that teams begin to take ownership for delivering the product. What happens is that, by allowing these teams to become self-directed, they own the schedule for delivery.

What happens is that you see some things like traditional breakdowns of roles, where they are looking at what work needs to be finished in a sprint, versus "Well, I am a developer. I don't do testing," or "I am a doc writer, and I can't contribute on requirements," and those types of things. It really builds a team, which makes it a much more efficient use of resources and processes, and you end up with better results than you do in a traditional methodology.

Gardner: It almost sounds like we're using market forces, whereby entrepreneurs or small startups tend to be more energized and focused than teams within a larger, centralized organization. Is that a fair characterization?

Morowski: Yeah, I think it is very fair.

Gardner: And, given that we're looking for this empirical learn-as-you-go, do what's right for you, I suppose that also means that one size does not fit all. So, Agile would probably look very different from organization to organization.

Morowski: It could. One thing we chose to do, though, was to really to set a benchmark process. So, when Borland first started developing in Agile, we had multiple locations, and each site was, in essence, developing its own culture around Agile. What I found was that we were getting into discussions about whose Agile was more pure and things like that, and so I decided to develop a Borland Agile culture. [See case study on Borland and Agile.]

We broke that up on geographic bases, where we started with one site, had one "ScrumMaster" and we built what we call the reference process. As we've grown, and our projects are getting more complex, the fact that we evolve from site-to-site based on the same process and the same terminology has allowed us to now choose more complex agile techniques like Scrum of Scrums or work across organizations, and have a common vocabulary, and that kind of common way of working.

Gardner: It also sounds like you are taking the best of what a centralized approach offers and the best of what a decentralized approach offers, in terms of incentive; take charge, and local ownership, and then making them co-exist.

Morowski: That's correct.

Gardner: All right, let's get specifically into Borland's situation. What is it about the way that Borland has been developing software, which is of course a core competency for a large independent software vendor (ISV) like yourselves, and it has been for 15-plus years … How difficult was it for you to come into this established organization and shake things up?

Morowski: Initially, it wasn't an issue because, like most organizations, when we went through and looked at it, there were a couple of grassroots efforts underway. From an Agile perspective, one of the things we did was to begin to leverage that activity and the successes that it had to use as a benchmark with other teams. As we grew and moved into other organizations that were not necessarily grassroots efforts, there were some challenges.

Gardner: So, it might be quite possible that lot of organizations that do development have people who are Agile-minded and perhaps even followers of Agile doing this already. Perhaps they should look for those and start there.

Morowski: I would recommend that you start with your grassroots efforts, establish your benchmark process, and then begin to move out from there.

One thing we clearly did was, once that we saw the benefits of doing this, we had a lot of executive sponsorship around this. I made it one of the goals for the year to expand our use of Agile within the organization, so that teams knew it was safe to go ahead and begin to look at it. In addition, because we had a reference implementation of it, it also gave teams a starting point to begin their experimentation. We also paid for our teams to undergo training and those types of things. We created an environment that encouraged transformation.

Gardner: Let's learn a little bit more about you, Pete. Tell us a little bit about your background and how you came into development and then into Agile?

Morowski: I've been in this business a little over 25 years now. I started in the defense and aerospace industries and then moved into commercial ISVs later in my career. I've been an executive at Novell. I've also been a CTO at IBM Tivoli, and prior to Borland, was the vice president of software at Dell.

Gardner: You've taken on this Agile project at Borland, and you've written a paper on the “Borland Agile Journey.” I've had the pleasure of reading it. I think it's a really nice read and I commend for you it.

Morowski: Oh, thank you.

Gardner: Tell us about this particular product set [Borland Software Delivery Management information] that Borland is coming out with. It's a product set about helping people develop software. Is there a commonality between some of the lessons you learned and then what you may have actually visited in terms of requirements for your products? [See demo and see launch video.]

Morowski: Oh, absolutely. One of the interesting things about the products that we are delivering is that one of them is a product for managing Agile development, especially in distributed teams and managing the requirements. So, we had the advantage of actually using the tools as we were developing them.

Now, we were also very cautious because you can get myopic about that type of thing, where we also using Agile principles, and we involved our customers in the process, as well. So we were getting kind of the best of both worlds.

Gardner: What makes software development different? In reading your paper, I was thinking about how these principles about self-empowerment and working quickly and then setting these boundaries -- "Okay, we're going to just work and do this for three weeks and then will revisit any changes," -- that might be something it would apply to almost any creative activity where a team is involved.

Is Agile something you think applies to any creative activity, a complex team-based activity, or is there something about it that really is specific and germane to software development?

Morowski: If you look at Agile principles, conceptually, they do apply to a lot of things. Anything in which you are going into a period of discovery, one of the key things is knowing what your goal or mission is. In the case of software, that's a requirement, and what you want the product to be.

But in any kind of empirically based endeavor, this would be something that you could apply. Now, when you get down to the actual Scrum process itself, it's the terminology, the measures, the metrics, and all those types of things are really tailored for software development.

Gardner: When I read your paper, I also came away with some interesting observations. You say, there is a difference between how development is supposed to work and how it actually works. It's sounds like many companies are living in denial or a certain level of dysfunction that they are not necessarily facing.

Morowski: It's one of the issues with laying a manufacturing process over something that's inherently an empirical process. In the end, all software R&D organizations or IT shops responsible for applications are responsible to the business for delivering results. And, in doing so, we all try to measure those things.

What I have observed over my career was the fact that there really existed two worlds. There is what I call the "management plane," and this is a plane of milestones, of phase transitions and a very orderly process and progress through the software development lifecycle.

Underneath it though, in reality, is a world of chaos. It's a world of rework, a world of discovery, in which the engineers, testers and frontline managers live. We traditionally use Gantt as a measure that is task-based. It requires a translation from the implementation world to the management world to show indications of progress. Any time you do a translation, there can be a loss of information, and that's why today software is such an experienced-based endeavor.

Gardner: And it's often been perceived as sort of a dark art. People don't appreciate or understand how it's done, and that those who do it should say, "Hey, leave me alone, get away from me. I'll come back with the results in three months."

Morowski: Exactly.

Gardner: But that doesn't necessarily or hasn't historically been the best approach.

Morowski: Absolutely not.

Gardner: Also, at times, you see them downplay process and say that doing good hiring probably is the biggest issue here. What's the relationship between hiring and what people, not always affectionately, refer to as human resources? What's the relationship between HR and Agile?

Morowski: Well, first of all, just getting back to a little bit on hiring thing. Hiring is important, regardless of what methodology you use, and I tend to stress that. I do contend there are different kinds of personalities and skill sets you are going to be looking for when you are building Agile teams, and it's important to highlight those.

It's very important that whoever comes onboard in Agile team is collaborative in nature. In traditional software environments, there are two roles that traditionally you may struggle with, and you have to look at them closely. One is the manager. If a manager is a micromanager-type, that's not going to work in an Agile environment.

And, the other thing, interestingly enough, is the chief architect role. What's interesting about that is that you would think you would fit in Agile very easily, but in a lot of traditional software organizations, all decisions of a technical nature on a project go through the chief architect. In an Agile world, it's much more collaborative and everybody contributes. So for some personalities, this would be a difficult change for them.

Gardner: So there is that grassroots element, and you have to be open to it.

Morowski: Right.

Gardner: What is it about the structures here? Again, for folks who might not be that familiar with Agile, tell us a little bit about some of the hierarchy.

Morowski: There are really two key roles. There is the ScrumMaster and the ScrumMaster runs what they call the daily stand-up. This is basically a meeting, where everybody on the team gets together on a daily basis and they answer three questions. "What did I get accomplished yesterday?" "What am I going to do today?" And "What's blocking me?"

Everybody goes around the room. It's a 15- minute meeting. You solve any particular problems, but you log things. The role of ScrumMaster is to run that meeting and to remove blocks to the team, and it's a very key role.

The second major role within Scrum is really the product owner, and this is the individual that's responsible for prioritizing the requirements or what we call the product backlog -- what is what is going to be done during the sprint, which features are going to be completed. Those are the two primary roles, and then from there everybody is pretty much a team member.

Gardner: When you decided to bring this into play at Borland, a very large, distributed organization, you didn't try to bite off too much. You didn't say, "We are going to transform the entire company and organization." You did this on more of an iterative basis. It seems that most people, when they do Agile, will probably follow similar path. They'll take a project basis and then say, "Now we need to expand this and make it holistic."

Many organizations, however, across all kinds of different management activities, can stumble at that transition from the project, or the tactical, into the holistic, or general, across an organization. What did you learn in making this transition from small to large scale at Borland?

Morowski: A couple things. One is that, as we rolled it out, let's say starting by site-by-site, we grew from teams-to-teams. The ScrumMasters worked very collaboratively to help each other out, because, in the end, they were responsible for delivering at the end of those sprints. That was a very positive effect.

As we moved out to distributed teams, there were a number of challenges, things like the daily stand-up, or if I have people in Singapore that are supporting a particular sprint, say, from the system testing point, that made things difficult. But, what I found is the team was pretty creative in involving those individuals, whether they recorded sprints, whether they shifted time zones, and they did this all on their own.

That was the absolute positive, one of the things that surprised me. It was an interesting discovery.

As we started to be more broad with the interaction with the non-Agile parts of the organization, this was a little bit more of a challenge, and I learned a couple of things. In doing any kind outsourcing, if you try to match a traditional, contractual base -- the statement of work (SOW)-type outsourcer -- with an agile team, that's going to present problems. The outsourcer is expecting very detailed specifications as a statement of work and that's just not produced during an agile or sprint/Scrum type of development activity.

The other thing is internally, and what I would say at the end of the pipe and at the beginning of the pipe, working with marketing and our new product introduction processes and support and getting sales out. One of the things that we found is that we started to have a capacity to release more often, but the organization, as a whole, had to adjust now to: A) provide market requirements to us in a different manner, and B) we had to adjust our process at the end to be able to accept more rapid releases.

Gardner: So in order to get the most out of Agile, it sounds like, for those organizations where software development is core competencies, important to their successes as a company, or as a government organization, or a public not-for-profit, that the edges of Agile start to blend into other departments. The whole competency around their organization can perhaps borrow some of these principles from development and extend them into the entire lifecycle.

Morowski: Yes, we no longer look at it as strictly an R&D thing anymore, just because of that. And, it's interesting. You know you are making progress from a development team perspective, when you are starting to output more than the organization can accept.

Gardner: Interesting. So, adjustments along the way, and that's again a principle of the approach.

All right. In this age of Agile and your Agile journey, you came away with three basic observations about the benefits. One was around self-directing teams; second around being able to manage change well; and, third, about how to do the relationship with the customer, in this case the customer being the folks who are interested in getting the software. Tell us about these three benefits and what you have learned?

Morowski: Well, we touched on the self-directing teams, and the key to that is one of the most important things as an executive is that you really have to take the lead and let your teams go and develop -- let them truly own their projects. There will be mistakes along the way, but once they do, it's an extremely powerful concept.

One of the great things about agile is that it's a very open and very visible methodology. During daily stand-ups, I can attend any daily stand-up and sit there and listen to what's going on. I can't contribute in those meetings, because that's run by the ScrumMaster. But, one of the times I was attending the daily stand-up, I knew the teams had progressed a great deal.

When they were looking at their remaining work backlog that they had for that particular sprint, and there were a couple of tests that need to be run that there was nobody assigned to. One of the developers had time, looked at that, and picked it up.

Now, normally, that would never happen, because we behave in a silo fashion. "I am an engineer." "I am a tester." It's an "I am a …" type of thing. But, when you really have a self-directing team, the team owns that schedule and it's very interested in making sure that they meet their commitments.

Gardner: I suppose that also fosters willingness of people to move in and out of role, without just saying, "Well, that's not my job …", but taking more group responsibility, and even as an individual.

Morowski: Absolutely correct, and that to me has been one of the more powerful things that I have personally observed.

Gardner: Change management has often been something that drives developers crazy. They hate when people come in and start changing requirements when they are in the middle of doing code or test. On the other hand, things don't stay the same, and change is part of everything in life and business, perhaps more so today than ever. How do you reconcile those two?

Morowski: Well, I think the reality is that there is going to be change during these development cycles, and so the question is what's the best way to handle it? If you look in a traditional waterfall methodology, you march along phase transitions. Even if you have iteration in place, if you discover a design or coding defect late in the game, you have to go backwards to a different phase and start going into the design or fixing the code. Then, you repeat the process again, and you continue to move along your space transition line.

The thing that's interesting is that with Agile you have an orderly way of injecting change. In other words, as a sprint completes and you've demonstrated the code -- and you demonstrate it after that three-week iteration -- if something has changed and you need to change the prioritization, you have a way to inject that change along that boundary, and then let the team go forward. That's what I always like to say, "We're always going forward in Agile."

Gardner: And how do the teams adjust to that?

Morowski: It's part of the process. The changes go into the backlog. The product owner looks at them and then prioritizes it based upon the complexity of the work and the timing and so on and so forth, and just how important that is. If it's important enough, it will go into the next iteration. The teams are used to doing that, because you are not, in essence, disrupting at a random point. They have already finished what work they were working on, and now there is a cleaner opportunity to inject that change.

Gardner: So, boundaries allow for those who want change to get it done without having to wait for a particularly long period of time or until the project is done. But, for those involved in the project, they have these sections where it's not going to become chaotic and they are not going to lose track of their overall process, because of this injection of change.

Morowski: No, as a matter of fact, the process encourages it.

Gardner: How about this, what you call customer relationships? It sound to me as thought it's just being transparent.

Morowski: It is. It's a different approach, in the sense that you are actually bringing in the customer as what I would call a partner in the development. They participate in sprint reviews, and sprint reviews at the end of a sprint, where you show the working code, what you have completed and so. Those are done on an every-three-week basis, and we involve our customers.

They also take early drops of the code and provide input into the product backlog on requests that they want, and things like that. It's proven to be very beneficial for us. The one thing is that, when you choose these customers to participate, it's important for them to be Agile, as well, and understand that, and they need to approach this as a partnership not just an opportunity to get their particular features or requirements in.

Gardner: And, that must also help keep expectations in line, right?

Morowski: Absolutely. What I have found is that the customers we have involved want to get used to our cycles and our delivery rhythm. They are less adamant about getting every feature on a list in a particular release, because they know it's a relatively short time before the next one comes around.

Gardner: When we describe these customers, would that, in many organizations, include bringing the marketing people in, and the salespeople. Can they get involved so that this becomes something that will enter the market as an agile activity, rather than having Agile happening on the development side, and then falling back into a waterfall mentality when it comes to the go-to-market activities?

Morowski: Yes, we do, and the transparency that's there actually helps build confidence in the rest of the organization on what we are delivering, because they see it as we progress along. It's not something that mysteriously shows up on their doorstep.

Gardner: It certainly sounds great in theory, and it sounds like you've been able to accomplish quite a bit in practice, but what about metrics of success? How have you been able to say, "it works?" Has Borland cut their cost, their time to development? Do they have better products? All of the above? How do we know we are succeeding?

Morowski: I'd say it's combination of all the above. The first thing is that by putting these teams together, they are much smaller teams than in traditional organizations. So, if you look at it, my teams are almost 30 percent smaller on the Agile side than they are on the traditional side.

Gardner: And what's accounting for that change?

Morowski: I think one, is the ownerships of the teams, and two, the breakdown of very specific roles.

Gardner: Would I be going out on a limb in saying you have eliminated the middle management factor?

Morowski: There is absolutely that as well. The other thing is the fact that we're delivering working code and involving with customers. We are developing fewer superfluous features. When a product goes out the door, it generally has the most important features that were entailed for this release. So, it really helps the prioritization process.

Gardner: Not too many cooks in the kitchen?

Morowski: Exactly.

Gardner: Cool! Tell us a little bit about what surprised you the most about this Agile journey of Borland.

Morowski: I think the power of the daily stand-up. I mean, yes, we got a lot of benefits, and yes, we had a number of successes, we were able to transition code from locations and things like that, but I owe that a lot to the daily stand-up. The thing that surprised me is how powerful it is each morning when everybody gets around the table and actually goes through what they've done, basically saying, "Have I lived up to my commitments? What I am committing to the team today? And then is there anything blocking?"

Generally speaking, a lot of developers tend to be quiet and not the most social. What this did is that it just didn't allow the few people who were social to have input on what was going on. This daily stand-up had people, everybody on the team, contributing, and it really changed the relationships in the team. It was just a very, very powerful thing.

Gardner: It sounds like balance among personality types, but that balance directed toward the real activity that is developing code.

Morowski: Absolutely.

Gardner: Interesting! Well, congratulations. I enjoyed reading your paper, and this certainly sounds like the future of development, I know that's what many people in the business think. We've been talking about Agile development practices and principles and how Borland Software has been undertaking an Agile journey itself, in a development project around development process tools and application lifecycle management products.

Back to those products. Is there anything about the synergy between doing it this way and then presenting products into the field that you think will help other people engage with Agile benefits?

Morowski: Are you talking about the products themselves?

Gardner: Yes.

Morowski: The products themselves, absolutely. We have a product coming out called Team Analytics. The key to this is that, while we talked about self-directed teams, we still have responsibilities to reporting to the business and how we are progressing.

Team Analytics gives us a view into the process, gives us the ability to go ahead and look at how the team is progressing, and those types of things, what features have been included or dropped, without having to go into the team and request that information. So that's a very powerful thing.

Gardner: Right. So, it's one thing to agree that visibility and transparency are good, but it's another to actually accomplish it in terms of complexity in large teams and hierarchy.

Morowski: Absolutely. This allows us to move to what I call a "monitored" from a "reported" kind of methodology of metrics. What I mean by that is, typically, at the senior vice president or vice president level, you really get to look at the state of your products once a month, in the sense that you have operations reviews or some kind of review cycle where all your teams come in and then they report the progress of what's going on.

With Team Analytics, you are able to actually look at that on a daily basis and see if anything’s changed over time. That way, you know where you need to spend your time and that's why we call it monitored, at this point.

Gardner: Super! Well, thank you for sharing your insights. I think there is a lot to be taken away here and learned.

We have been talking with Pete Morowski, the senior vice president of research and development for Borland Software. We were looking at Agile principles in the context of Borland's Agile journey.

Thanks, Pete.

Morowski: Thank you, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions, and you’ve been listening to a sponsored BriefingsDirect podcast.

Thanks for joining us and come back next time.

Listen to the podcast. Sponsor: Borland Software.

Transcript of BriefingsDirect podcast on Agile development principles with Borland Software. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.

Transcript of BriefingsDirect Podcast on ALM 2.0 and Borland's Open ALM Approach to Development as a Business Process

Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded April 3, 2007. Podcast sponsor: Borland Software.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a sponsored podcast discussion about the development of software as a managed business process, about seeking to gain more insight, more data and metrics, and more overall visibility into application development -- regardless of the parts, the components, the platforms, or the legacy. It’s really about gaining an operational integrity view of development, from requirements through production, and bringing it all into a managed process.

To help us through this discussion of Application Lifecycle Management (ALM) and the future of ALM, we have with us Carey Schwaber, a senior analyst at Forrester Research. Welcome to the show, Carey.

Carey Schwaber: Thank you.

Gardner: We're also going to be talking with Brian Kilcourse. He is the CEO of the Retail Systems Alert Group, and a former senior vice-president and CIO of Longs Drug Stores. Thanks for joining, Brian.

Brian Kilcourse: Thanks, Dana.

Gardner: Also joining us, an executive from Borland Software, Marc Brown. He is the vice president of product marketing. Welcome, Marc.

Marc Brown: How are you?

Gardner: Doing well, thanks. We want to talk about the "professionalism" of development. Some people have defined software development as an art or a science -- sometimes even a dark art. And to me that means a lack of visibility and understanding. Many times the business side of the house in an organization that’s doing software is a little perplexed by the process. They see what goes in as requirements, and then they see what comes out. But they often don’t understand what takes place in between.

I want to start off with you, Marc. Tell us a little bit about ALM as a concept and what Borland Software, in particular, has been doing in terms of evolving this from mystery into clarity?

Brown: Dana, that’s a great question. What Borland has been doing over the last several years is really focusing on how to help organizations transform software delivery or software development into a more managed business process. We think this is critical. If you look at most businesses today, IT organizations are expected to have very managed processes for their supply-chain systems and for their human resources systems, but when it comes to software delivery or software development, as you mentioned, there is this sense that software is some sort of an art.

We would really like to demystify this and put some rigor to the process that individuals and organizations leverage and use around software delivery. This will allow organizations to get the same predictability when they are doing software as when they are doing the other aspects of the IT organization. So our focus is really about helping organizations improve the way they do software, leveraging some core solution areas and processes -- but also providing more holistic insight of what’s going on inside of the application lifecycle.

Gardner: In January of 2007, you came out with a new take on ALM. You call it "Open ALM." I am assuming that that is opposed to "closed." What is it that’s different about Open ALM from what folks may have been used to?

Brown: Well, getting back to helping organizations with software development, it's Borland’s assertion that we need to do it in the context of how organizations themselves have developed or invested their own technology stack over time. So for us the way that we can help organizations apply more management and process-rigor to the application lifecycle is to give them insight into what’s going on. We do that through providing metrics and measurements, but in the context of their technologies, their processes, and their platforms. That is versus proposing a new solution that causes them to do a rip-and-replace across each of the vertical slices of the software development lifecycle.

Gardner: It sounds like an attempt to give the developers what they want, which is more choice over tools, new technologies -- perhaps even open-source technologies. And at the same time you give the business more visibility into the ongoing production and refinement of software. Is that a fair characterization?

Brown: It sure is. What we are all about with Open ALM is providing a platform that provides the practitioners of ALM the tools, processes, and choices they need or are skilled in, and then provide the transparency across that lifecycle to be able to collect the metrics necessary for the management team to actually manage those resources more predictably.

Gardner: Okay. My sense is that there are more options for companies when it comes to the tools and the utilities that they bring into the software development process. Let’s take a look at the state of the art of ALM. Carey Schwaber, can you give us a bit of an overview about ALM? And am I correct in assuming that there are more parts and therefore the potential for more complexity?

Schwaber: You're right. There certainly are. ALM isn't just about developers. It’s really about all the roles that come together to ensure that software meets business requirements -- from business analyst, to the architect, to the developer, to the project manager, the tester.

It just goes on and on. And it feels like every year we end up with more specialized development teams than we had the year before. Specialization is great, because it means that we have more skilled people doing jobs, but it also means that we have more functional silos. ALM is really about making sure that every one of those silos is united, that people really are marching toward the same goal -- to the same drumbeat. ALM is about helping them do that by coordinating all of their efforts.

Gardner: Are there some mega trends going on? It seems to me that offshoring, globalization, outsourcing, and business process management (BPM) add yet another layer of complexity.

Schwaber: There aren't many trends that you can’t tie back to a greater need for ALM, where we have so many things going on that are increasing the degree to which our software is componentized. SOA is just one way in which our software is more componentized. Dynamic applications are also leading toward more componentized software, and that really means that we have more pieces to manage.

So in addition to functional silos, we've also got technology silos where we have a front-end in .NET, a back-end in Java, and maybe we're using a BPM tool to create the entire composite application. There are just so many ways that this gets more and more complex. Then, in addition to managing roles, you also have to manage all of these different components and their interdependencies.

Gardner: A major component of ALM is managing complexity. You came out with a report in August of 2006 that coined the term "ALM 2.O." What did you mean by that?

Schwaber: That’s actually about something that we see as a shift in the ALM marketplace. In the past, vendors have collected ALM solutions over time by acquiring support for each role. They’d acquire a tool that supported business analysts in the work that they do. Then, they’d acquire a tool that supported testers or test leads and the work that they do. They’d integrate the two, but that integration never ended up being very good. That integration is where ALM comes in. ALM lives in coordinating the work that the tester, the business analyst, and all the other roles involved really accomplish, to make sure that software meets business needs.

What we have seen is a trend where vendors are stopping the accumulation of piece-parts of ALM solutions, and starting to design platforms for ALM that really integrate any tool that the company happens to be using with something over the platform that provides ALM almost as a service to the tools. People have the option of choosing a tool for their business analysts from one vendor, a development environment from another vendor, and a testing tool from a third vendor. They are plugging into the same ALM platform, knowing that they'll all work together to ensure that those roles are in harmony -- even if the vendors that produced the tools that support them are not in harmony.

Gardner: So even if we take a platform approach to ALM, it sounds like what you are saying is that heterogeneity -- when it comes to the moving parts of application and software development -- is no longer necessarily a liability, but if managed properly, can become an asset.

Schwaber: That is definitely one of the goals of ALM 2.0, to assume that integrating lots of different functional silos shouldn’t require that we go to a single vendor, because that’s not always possible. There may be a best-of-breed tool in a certain area that happens to be from a vendor that doesn’t have great support for the rest of the lifecycle. So the vision with ALM 2.0 is that you shouldn’t have to make that trade-off. You should be able to choose best-of-breed and integration.

Gardner: I assume then that this also affects people, IT, and process. How would an enterprise that buys into this vision get started? Do you have to attack this from all angles, or is there a more pragmatic starting point?

Schwaber: Hopefully the vendors will make it easy on you and you won’t have to buy everything in one fell swoop. The whole idea is that if you purchase one tool from a vendor that has an ALM 2.0 platform, the platform essentially comes with that. Any tools that happen to plug in to that are ones that also enable better and more flexible ALM, where the platform provides services like workflow, collaboration, reporting, and analytics. Maybe even some more infrastructure things like identity management or licensing could be in the platform, and those would be available to any tools that wanted to consume them and were designed to consume them.

Gardner: Let’s go to Brian Kilcourse. Brian, you have been in the field as a CIO. Is ALM 2.0 vision-creep or is this real-world, in terms of how you want to approach software development?

Kilcourse: It sounds very real-world to me. As most CIOs have done, I spent untold amounts of money trying to turn the software development process from an artistic activity to an engineering activity. There were a bunch of good reasons for that. One of them is that commercial computing is now over 60 years old. And one would think, at this point, that we would have figured out a way to commoditize it and make it more reliable.

But it still remains, even after this long period of time, that software development is easily the most unreliable part of the whole value delivery equation that the IT department brings to the organization. So in broad-brush strokes, it makes great sense. The other thing that is important to underline, as Carey already mentioned, is that people like me have already spent a lot of money on tools. And just because there’s a new and better definition of how to approach those tools doesn’t mean that I am going to throw everything away.

Organizations that had quite a bit of time to get these tools embedded into their practices may have silos of expertise that aren’t going to be easily displaced. All of these things argue against stopping your business while you figure out a better way to develop software. What is important is that we desperately need a way to be able to track a development from the initial conception of the requirements, all the way through to delivery, production, and beyond.

There has to be a way to do that, and it has to be an overarching process that we can observe, measure, and report on. To that end it requires that all of these tools, whatever they are, be kept in sync, so that we can understand it and we can make it evident to the business -- so that the business can know that they are getting the right value for the right dollars. That’s always one of the biggest challenges that any CIO has -- how to show value.

Gardner: I suppose there’s been a kind of tension between sufficient openness and sufficient integration, and that they play off of one another. Is there anything about the state of the art now, where reaching this balance between sufficient openness and the ability to integrate and manage, comes into some sort of a harmonic convergence? Is there anything different about ALM today?

Kilcourse: The fact that we are talking about ALM 2.0 is a big step in the right direction. In our business applications we need to be able to integrate at the information level and the data level, even if they are different code sets or physically different databases. From the business perspective we need to come up with one coherent answer to any kind of a business question. No matter what the toolsets are, we have one way to see them from a business perspective. I think that’s very encouraging.

We know from our business application stack that this is possible. So if it’s possible for the business, why isn’t it possible for the IT organization? You can call this a "cobbler’s children" problem. Why don’t we have for ourselves what we promise to deliver to our business associates?

Gardner: Let’s take that back to Marc Brown at Borland. I assume that your goals with Open ALM are similar to the goals envisioned in ALM 2.0, and that you want to help CIOs get that visibility to demonstrate value. Do you see something new and different in the marketplace now about reaching this balance between openness and integration?

Brown: You know, I do. To extend what we were just talking about, one of the core differences that organizations are talking about today versus 10 years ago is that in the past we talked a lot about making sure we had optimized role-based solutions. We talked a lot about supporting specific activities and specific roles in a lifecycle. What we are finding today when we talk about application lifecycle, and I think Carey brought this up, the real critical piece is understanding the core processes that drive the overall lifecycle activities and assets between the individuals that make up a software delivery team.

So for Borland one of the unique aspects in the way we are approaching this is that we are really focused on the process-driven integration from a technology perspective. We're really looking at the individual processes, such as portfolio and project management, where requirements definition management, understanding those processes, bringing the technologies to bear to support those processes, and providing the integrations between those individuals supports the horizontal software processes.

The other aspect is understanding that we need to do this, not just in a constrained set of tools that Borland brings to market, but also in the context of the tools that customers want to use and leverage. That means Borland technologies, other third-party technologies, and open-source technologies.

Gardner: I suppose one of the hurdles to getting this visibility in the past was that a lot of these components, tools, and testing environments have very different technologies and formats for how they apply and transfer data. What is it that Borland has done with Open ALM to allow the majority of these parts to work together? Is this about building modules and components? What does it take to get these things to actually be herded, if you can use the analogy of trying to herd cats?

Brown: The starting point is understanding that we need to deliver a platform based on an ALM meta-model, something that we can utilize and leverage to define all the various activities and assets that flow through the application lifecycle. Then we need to provide a set of core services that will use that meta-model and will support add-ons that are lacking today. One of the critical things is providing more comprehensive ALM-centric metrics and measurements that span the lifecycle -- versus being very vertically focused for a particular role and job. A lot of this is based on having an ALM data description that represents all the activities and data that are going to be passed through a lifecycle.

Gardner: So there’s an immediate tactical benefit of getting the data from the various parts, and there’s a larger strategic value of then analyzing that data, because you've got it in the holistic process-driven environment, a common environment. What sort of data and metrics do you expect companies to be able to derive from this, and how can they instantiate that back into the process?

Brown: The critical thing that businesses will be able to do is be able to demystify what software development really is. It's about removing the "black box," and having data consolidation or aggregation so they can in fact measure what’s going on. Then they can determine what areas of the processes are working, what areas potentially are bottlenecks or are deficiencies. They can utilize the data that’s being collected across the ALM, and filter that out to the broader business intelligence activities that the IT business is doing to see what’s actually working, and what’s not working, within the IT organization.

Gardner: We're going to be able to give non-IT people some real visibility into timetables, quality assurance curves, dates for completion, and that sort of thing, which to me seems essential. If you are putting a new product or a new service in the market, you are going to be ramping up your marketing, ramping up inventory and supply chain, and are going to be looking into manufacturing, if that's the basis of the product. You really need to coordinate all these things with development, and that has been haphazard.

Am I reading more into this, or do you really plan to be able to give non-IT people these dials, and this kind of a dashboard by which to run their entire business -- but with greater visibility?

Brown: That is exactly what we are proposing. Borland is very committed right now on Open ALM to deliver a platform that allows organizations to leverage their own configured processes and technologies to gain the insights necessary to really start having confidence in what they are doing. That confidence is going to be increased by providing them the tools and technologies so they can track, measure, and improve their processes.

Gardner: Let's take it back to Carey Schwaber. Carey, in your analysis of the market is there a potential for a significant productivity boost by bringing visibility into software development and activities into the larger context of business development and go-to-market campaigns?

Schwaber: I think there is. And there is a great degree of redundancy that happens to a lot of development efforts that have already been accomplished, or just redundancy of documentation. Even when it’s not redundancy, the problem is that people are pursuing different goals -- when you have testers who are testing against out-of-date requirements, and the business analyst wants them testing against the newer requirements. We've got the problem of an overlap of efforts. Then we've got the problem of misaligned efforts. Together those really eat away your productivity and waste precious development dollars.

There are a couple of ways you can use better ALM practices to improve productivity. The first is to get numbers about what you are really doing today to measure how often these things are happening. That is the first step that you need to take before you can take remedial action. The second one is just making sure that you have people working off of common data, that there is one way to represent the truth -- not just about one part of the lifecycle, but the entire lifecycle. You have to have the appropriate correlation between those disparate parts.

Gardner: Brian Kilcourse, to your point about CIOs trying to demonstrate value in real terms -- to be viewed as a productivity center and not a cost center -- do you think that this visibility into application development can give you, as a CIO, the tools you need to go to the CEO and say, “Here is what we are going to do, and when we are going to do it.”

Kilcourse: Certainly, if you as a CIO can map specific IT activities back to the business requirements that drive them, you have a much stronger set of metrics to indicate your alignment to the business than you have otherwise.

There is a huge disconnect between the front of a development process, which is always driven by business requirements, and the back-end of the process, which is always post-production maintenance. Between those two spaces there are a lot of things that go on. Somewhere along the line, in what I characterize as the business technology handoff, there is a big disconnect. Even with the best intentions, because of the complexity of the technology solutions available, the business really does lose track of what those guys down in IT are doing. The ability to overcome that chasm would go a long way toward solving the historical distrust between the two organizations.

Gardner: Do you sense that there are any particular vertical industries or even types of development projects that would benefit from an approach like Open ALM better or first? Where is the low-hanging fruit for this?

Kilcourse: That’s a great question. No business that I am aware of starts from scratch, either with a technology group or with the business that it supports. So any business that is trying to infuse the business process with the information asset in new ways is a candidate for this. I focus a lot on retail. And I can tell you from my experience in retail that those organizations are ripe for this kind of capability. There is a tremendous amount of distrust between the executive side of the house and the IT side of the house in that particular industry. I see it in other industries as well. But even in such obviously highly correlated industries like financial services there is still a tremendous room for improvement.

Gardner: Do you think Open ALM makes more sense for those organizations that are in fast-moving markets? Retail, of course, is like that because they have to anticipate, sometimes months in advance, the desires of a culture or a human fashion-driven impetus to buy. And then they have to act on that. Do you think that for those companies that are involved with fast time-to-market that this would be particularly important?

Kilcourse: Certainly fast time-to-market causes fast marketplace changes. The problem in IT across so many factors is that the IT organization cannot respond quickly enough to changes in the business environment. That's not particular to retail. It happens everywhere. To the extent that you can eliminate the friction that exists in the delivery process within the IT organization -- so that the company actually is getting the maximum amount of traction for their investment dollars -- it's going to help.

Carey pointed out, and I thought it was a really good point, that there is a lot of wasted activity that goes on because of rework and focusing on the wrong requirements that might not have the biggest benefit -- but might be the thorniest problem that somebody faces. We don’t always have visibility into that. We find out only at the end when we tally up the score and find out where the dollars really went and why we had to go to Phase 2, Phase 3 and Phase 9 of a project, because we couldn’t get it all done in the first shot.

The ability to focus IT energy where it really matters most to the business is a big goal of most CIOs that I know.

Gardner: Carey, back to you. Do you concur that the fast time-to-market is a major impetus? If so, what other ones do you see in terms of where common views of practices and processes for application development are super-important?

Schwaber: I agree that fast time-to-market or any time-to-market pressure is definitely a reason you would need to have your ducks better aligned up front. But I don’t know any companies that don’t want to do a better job of satisfying their business customer’s demands for the same software in less time. That's a pretty universal desire, no matter whether you have a lot of time-to-market pressure in your industry or not.

So, I would say that we all want more for less. On top of that, I would add compliance requirements, where you need to confirm that the software you are developing does what the business wants it to, so that you know that you are producing accurate financial reports, or even that you have some kind of internal compliance requirement.

You know you are looking to get toward Capability Maturity Model® Integration (CMMI) Level 2 or Level 3, and you want some proof that you are actually going to do that. ALM capabilities can really help you in that area. So those kind of pressures really matter. But any time we get away from the old halcyon ideal of the business customer telling the developer what to write, and then the developer immediately implementing it, we have opportunities for miscommunication. The more people, geographies, and technologies we involve, the more complex it all gets, and the more we really need help keeping track of all the dependencies between the things that we are doing. That is really describing any project these days.

Gardner: Of course, software seems to be playing a larger role in how companies operate. The technology, in a sense, becomes the company.

Schwaber: How many business processes are there that aren’t automated by IT, either today, or plan to be automated by IT within the next five years? Business processes that we can’t even imagine will be embodied in software eventually.

Gardner: Let’s get back to Marc Brown. Marc, at Borland you have come out with this Open ALM approach and you have had a lot of experience in development over the years. Do you have any metrics? Do you have any sense of what the pay-off here is through some of your existing customers -- maybe some beta examples? Do you have any typically "blank" percentage of savings? What are the initial payoffs from embracing Open ALM?

Brown: We certainly have seen the benefits with many organizations, which see the value in a number of ways. First, many organizations, because they are trying to improve their overall process, are attacking their deficiencies incrementally. We've got some organizations that have found their key issue today is poor requirements definition and management. They simply can't get requirements written accurately and in a way that they are testable up-front. This creates a huge amount of rework downstream.

We've got some really good examples where we have gone in and helped organizations improve their requirements definition and management process, and we found really dramatic improvements. On one occasion, an organization was able to achieve a 66 percent improvement just on the analysis side -- when they were going through, looking at a legacy system, trying to define the "as-is" business processes, and then taking that work and collaborating with the business stake-holders to construct the "to-be" business process. That was typically taking the organization anywhere from 12 to 20 weeks. They saw a 66 percent decrease in that time by leveraging not only the process guidance we were giving them, but also other technologies that we could apply to that area of the process.

Gardner: So that’s a substantial opportunity, and that was only, I suppose, a partial embrace of Open ALM.

Brown: Yeah, and that’s the way a lot of people are looking at this. We are going out and helping organizations first of all pinpoint their largest areas of deficit or gap. That could fall into any of the four critical solution areas that we're helping organizations around project and portfolio management, or, as I mentioned, requirements definition and management, or lifecycle quality management. We are helping them understand where they have gaps or deficiencies today, and then incrementally improving that over time to embrace Open ALM as an incremental philosophy and approach.

Gardner: How has this so far impacted distributed types of development, where the organization has a number of development centers around the world, where perhaps you are outsourcing, and your outsourcing organizations are spread around the world? What’s the potential payback for those sorts of highly distributed development activities?

Brown: The real benefit we are seeing, and we will see more of this over time, is through the increased visibility. Again one of the biggest problems with organizations that are outsourcing today is the inability to aggregate or consolidate data from the outsourcer, the supplier, and the vendor, and to bring that together into a view, to have confidence that what’s happening from the outsourcer aligns with the overall business goals and original project plans. With our ability to help overlay our platform to bring together both the outsourcer’s technologies and data -- and then bring that together with the internal data -- we are able to bridge the gaps that they are having today, so that they have more confidence in the data they are seeing.

Gardner: How about Services Oriented Architecture (SOA)? It seems to me that as you break things down into services -- if we eradicate more of the silos around runtime environments -- we are at the same time knocking down silos in design-time. We might be able to get into some sort of a virtuous cycle, whereby we can adjust development to suit what’s going on in the field, which then is able to adapt to business requirements. That seems to be a big pay-off from SOA.

Let me throw that out to the crowd. What do you think is going to be the impact of SOA on development?

Brown: I'll take the first crack at this, Dana. I do think that SOA will certainly provide a lot of benefits, because it is one of the first practical approaches to help organizations realize the benefits of reuse. It's something that a lot of organizations had talked about time and time again. But there has been a lack of a common infrastructure or communications to bridge how that really happens over time. Many organizations simply said, “Look, my project’s not budgeted to create reusable code. We've got tight deadlines, and we have got a lot of work to do, and I am not going to have the time to do it in a reusable fashion.”

SOA gives people a good framework for how to actually structure applications to provide interoperability over time. I think this is a good approach for organizations to finally see the benefits of reuse, but it requires a lot of management and due-diligence when they are developing and deploying particular components. Because as they develop new versions or new components to supplement existing ones, they have to have more visibility in the usage levels, on who is using what, and so on.

Gardner: How about you, Brian? How do you see the evolution and maturation of ALM and the burgeoning ramp-up to SOA working either together, or perhaps at odds?

Kilcourse: Actually I don’t see them at odds at all. Because, first of all, SOA is an architectural concept, whereas Open ALM is a process concept or process model. In my company we just finished a piece of research on SOA and retail. What we found out is, if I could characterize something as a curiosity-understanding ratio, there is a lot of curiosity and very little understanding of what SOA really means in terms of how you get from "here" to "there."

As it relates to ALM -- going back to the original discussion that ALM covers everything from requirements all the way through post-production -- the notion of SOA breaking things down into reusable components or objects, business rules or metadata that can be redeployed almost at will as the business needs change, is a very powerful notion, especially in an environment such as the one that I service, where the business environment changes quite dramatically.

The challenge, of course, is taking something as broad as a business requirements and breaking them down into tiny service-level objects that then can be understood and implemented by the IT organization. If you don’t have some way to map that to the business requirements, you could have a worse bowl of spaghetti than you have now. In that context, these things are very tightly interwoven.

Gardner: How about you Carey? A last word on SOA and ALM?

Schwaber: Well, a lot of the great words have already been taken. But what I would add is that SOA introduces more dependencies among development projects then we are used to. It really requires us to have some way of coordinating our efforts across projects. In the past, projects often used completely different technologies for managing their lifecycles.

So this is yet another impetus for us to have a better way of connecting disparate tools from different vendors that use different technologies. Otherwise we end up not communicating the right data at the right time about services, about service levels, about service quality -- and we end up chasing our tails, trying to figure out what it is we have to do to build services that other people can reuse in effective ways that map to the business processes we are looking to automate.

Gardner: I suppose that quality and quality assurance are important when we go into these more componentized services. It seems to me that history has borne out that quality comes from getting it right the first time, and that really means business requirements.

Schwaber: SOA really does make quality that much more of an issue. We aren’t that good at it for basic, monolithic applications. Imagine how bad we’ll be at it with SOA?

I really see SOA giving us an opportunity to do better, because in every service a defect is propagated to every single application that consumes that service. But if the service is high-quality, that quality level is propagated, too. Essentially we have a mandate to do a much better job on quality in our services because the stakes are so much higher. We really need to bulletproof services that are built for reuse.

Gardner: Marc, to you now. As the stakes are getting higher, Borland has identified an important initiative. What is it that puts Borland into position to lead in this segment? Is it because of your heritage, acquisitions, the position you’ve taken on openness, or is it because of a "secret sauce?" What is it about Borland that makes you able to rise to this challenge?

Brown: It’s a couple of things. First, Borland in its overall business strategy is completely focused on helping organizations transform the way they do software, and we are not promoting any particular type of platform or development environment. We are all about helping people understand how to manage the actual processes that govern ALM. I think we have got a little bit of a secret sauce, because we are somewhat neutral from the platform or development-environment perspective. There are other vendors in this space who certainly have specific ties with a particular platform or development environment.

One thing that really distinguishes us from the others in the game is the fact that we are really focused on helping customers solve their true pains, which is giving them the metrics and measurements they need to be more successful at software. And at the same time, we support their current investments and future investments. So for us we’ve got full focus on ALM, and we are committed to supporting the platforms, the development environments, and the processes that organizations use today -- and those that they are going to use in the future.

Gardner: Great. Well, thanks very much. This has been a BriefingsDirect podcast discussion, a sponsored podcast about Application Lifecycle Management and the evolution of software development into a managed business process.

We’ve been joined by Carey Schwaber, a senior analyst at Forrester Research. Thanks, Carey.

Schwaber: My pleasure.

Gardner: Brian Kilcourse is the CEO of Retail Systems Alert Group, and a former senior vice president and CIO at Longs Drug Stores. Thanks, Brian.

Kilcourse: Thanks for having me.

Gardner: And Marc Brown is the vice president of product marketing at Borland. Thanks, Marc.

Brown: Thank you.

Gardner: This is Dana Gardner, your host and moderator, and the principal analyst at Interarbor Solutions. Thanks for listening.

Podcast Sponsor: Borland Software.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect podcast on Open ALM and ALM 2.0. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

Transcript of BriefingsDirect Podcast on Borland Gauntlet and Enabling Development Process Management

Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Dec. 19, 2006.

Podcast sponsor: Borland Software.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, and you’re listening to BriefingsDirect. Today, a sponsored podcast on developer productivity, on looking at an holistic approach to development that takes into consideration policy-based approaches -- managing process and people -- and not just the technology. We'll also talk about seeking a feedback approach, where testing is continuous -- and visibility into performance becomes an imperative.

To help us sift through some of these issues today we’re joined by Rob Cheng. He’s a Director of Developer Solutions at Borland Software. Thanks for joining us, Rob.

Rob Cheng: Thanks for having me, Dana.

Gardner: Rob, we want to get into a little bit of a historical context here on developer productivity. Why don’t we start out with understanding some of the basic principles around Agile development? I think that’s a good place to start, as we get into some of the approaches that Borland’s taking, and some of the newer benefits that are available in the field now. Give us a little primer and a little history, if you will, on Agile?

Cheng: Certainly. Agile essentially arose as a reaction against what was perceived as more heavyweight methods like Rational Unified Process (RUP). They were considered to be somewhat inflexible and inefficient, and imposed too high of an overhead on the development organization. The term "Agile" actually covers quite a few different specific methodologies, including extreme programming and Scrum, but they all share some basic principles, things like customer focus and rapid iterations on working software.

Gardner: I suppose if you do have rapidity, and you’re remaining lightweight, you also might lose visibility. So, managing this becomes a bit more important.

Cheng: Absolutely. I don’t know if it’s true that you lose visibility, but you have to be more cognizant of what you need to do to maintain visibility. A rapidly iterating process gives you more opportunities to measure things. You could conceivably end up with better higher fidelity measurements of visibility. That’s really where we’re going from the Borland Gauntlet perspective.

Gardner: And obviously it gives us an opportunity to gather more data at more points in the process.

Cheng: That’s right. In terms of data or metrics, rapid iterations really give you more opportunity to sanity check what you’re building, either from a code perspective or, ideally, with the customer/end user of the product.

Gardner: When one gains more data and input, then one can also make comparisons, and have, in a sense, a feedback opportunity.

Cheng: That’s exactly right. One thing that isn’t talked about enough in this area is the context. You get around to looking at projects in relationship to each other in context and also in relationship to time, looking at how things have changed from previous versions or over the last few months of the development process.

Gardner: I suppose the emphasis, until fairly recently, has been on managing the code, managing the development itself, in bits and bytes, checking in and checking out, and so forth, but with less attention paid to the overall process of how to take a project from beginning to end with a lifecycle approach.

Cheng: I think that’s actually an important point around Agile methodologies. If you look at the Agile Manifesto, or any other documentation around it, it really does try to emphasize that there’s a customer focus in all of this. And that customer focus helps drive some of this end-to-end thinking that we’re talking about.

You can’t have customer focus when you’re ignoring requirements, or when you’re ignoring use cases. Your iteration is not going to be completely successful, unless, at the end of it, there is a validation.

Gardner: And that leads of course to the real Nirvana here, which is to align business goals and interest with the development process, and development in general.

Cheng: That’s right. When you talked about aligning to customer needs, ultimately what you’re doing when you’re aligning the customer needs is aligning with the business needs.

Gardner: Now, what's at stake in getting this right or wrong? How big a deal is this, when we look at different vertical industries? And when we look at competencies within organizations, as they compete with one another, and the impact of globalization, and the need for getting to market quickly. What are the stakes here?

Cheng: The stakes are ultimately the success or failure of your software initiative. When you look at reports like the [Standish Group’s] CHAOS Report, which specified some ridiculously high number -- over 60 percent of software projects failing -- that entails a huge cost to the business. There’s a huge cost to software failure, software project failure, and there’s also a significant cost within projects of having to deal a lot of late stage rework.

Getting this right during the process means that it will eliminate a lot of those costs upfront. We can find out early whether there are issues, and the scope and size of those issues. The second part isn’t addressed quite as often. It’s the high business risk involved in simply not knowing. This goes back to the visibility issue. If you’re heading up a business unit, and you ask your accountants for some financial analysis, and they tell you, “Come back in a few months and then maybe we’ll give educated guesses,” what would you do?

Gardner: I’d be concerned.

Cheng: You bet, and you’d be right to be concerned. That’s not how businesses are run, but this is how software development has been running for decades. The businesses that have been trying to manage these, development organizations, have taken it for granted that this is how development works. This is black art. And, it goes to the heart of problem that we at Borland are trying to help the customers solve.

We’re trying to help them make software delivery more of a managed business process that’s based on metrics and objective measurements, not just guess work and anecdotal evidence. When we’re talking about more agile or rapidly iterative process, this is where it really gets to the heart of it. You can contribute to more frequent and improved measurement, not just from code, but, as we were talking about earlier, from an end-to-end user acceptance perspective.

Gardner: So, I shouldn’t need to wait until the project’s done to know, how well it’s doing.

Cheng: That’s a recipe for failure -- waiting until the product’s done to know whether it’s successful. You could take any other example in the business industry and you would be laughed out of any conference room, if you suggested, “We’ll wait until we’ve delivered our product or come off the manufacturing line to decide whether it’s okay.”

Gardner: This makes good sense. It’s logical and it’s rational. We can compare this to other initiatives in the industry in business over the past 150 years, whether it was manufacturing or the Industrial Revolution. So, there seems to be a natural evolution. But, how do we actually put it into practice? How do we go from theory to execution? You’ve gone out and decided that this is an important and a good business to be in. And, you have done some acquisitions to bolster your approach to this. Tell us a little bit about how you got from theory to execution?

Cheng: The technology that we’re talking about today around Gauntlet arose from an acquisition of some technology from a start-up that was run by several of BEA’s WebLogic Workshop veterans. They saw the problems and the challenges within their previous roles in very high definition and contrast.

They felt this was a serious problem that really impacts every development organization on earth. Borland, at that time, was also looking at how we could help extend some of the best practices and process improvements across the lifecycle -- and earlier into development. You might have noticed that we’d also made recent acquisitions around the testing in Quality Assurance (QA) space.

Gardner: Right.

Cheng: One was with Segue Software. One of the challenges that vendors like Segue or Mercury have had is that, although they’ve been quite effective at doing some automation and improvement around the QA process, they had no visibility into what’s happening in development. So, we still had this problem that you’re testing more effectively, but you’re still doing it very late in the game. After it comes off the assembly line, you have very little impact, and you can make very few changes effectively and cost effectively at that time.

Gardner: When I was doing some research into Gauntlet, I learned that the word Gauntlet comes from the idea that you’re going to put their code, the process, the people, through this gauntlet, making sure that it passes all the tests along the way, which is a good visual idea. It reinforces what’s going on here. Can you give us a bit more detail? What do you mean by test-before-the-test-phase and continuous test?

Cheng: That definitely is the metaphor of Gauntlet. What we mean by testing continuously is essentially that we are marrying quality control with existing version-control processes. Specifically, what’s happening is, as developers are committing their changes into their SCM or version control system, Gauntlet works behind the scenes to test, analyze, and measure those changes.

We can also intercept problems. For example, a very common problem is that you make some change, and because you weren’t careful, you break the build. It causes everybody else not be able to work, because you did something, perhaps some trivial change to a configuration file, that stopped it from working for every one else. Well, Gauntlet can actually interpose itself into this process, do the automated build analysis, and find that either it doesn’t build or fails some important test. Gauntlet won’t allow it to progress. It actually won’t promote the code and integrate it into main lines.

Other developers won’t see that and won’t be impacted by that change. When we talk about continuous test, we’re really talking about an approach to software delivery that emphasizes that quality really should be approached, and should be considered in every role and every stage in the life cycle. It’s not just the responsibility of QA. Unless you’ve made that mental acceptance that this is QA’s job, and you’re already in that place where it’s after the fact. You’re doing all this work but it’s already too late to make effective changes.

Gardner: Of course, the earlier you intercept the problem, the less costly and time-consuming it is to fix it, and the sooner you can bring the rest of the team in and on it.

Cheng: Actually, that’s true for number of reasons. Testing frequently does give you this notion of early detection. If you’re testing constantly and continuously, that means the time between when you create a problem or defect and the time when you find out about it is relatively short. That has a couple of consequences. One is that, it doesn’t have time to grow. It’s a bit much to talk about these defects as viral, but they can impact other projects and other development efforts.

Software is classically complex and interdependent. The longer you take between introducing a problem and discovering it, the longer you have that problem, and the longer you have other components and technologies -- or other software modules -- that depend on that particular flawed implementation. Unrolling that becomes much more expensive when you find out about it much later.

Gardner: I’ve heard some folks say, “Gee! You want us to have quality, and you want us to test continually, but you also want it done fast. Now which is it going to be?” I think there’s been some mentality that testing slows things down, and you’re bringing this in however as an overlay. This isn’t something that people need to do terribly differently. It’s not a rip-and-replace approach. You’re letting people use their same software configuration management (SCM), the same tests, and you’re just providing an organizational matrix on that. Is that correct?

Cheng: Yes that’s right. In fact, we do lower the overhead to some extent. When we talk about testing often, those are manual tests. Those are tests that the developer or QA engineer has to remember to do. They have to do them manually, have to take time out of their implementation to go and run these. Build it locally, test it locally. Presumably you’re doing something with that output as well, and all of that is overhead.

Gauntlet is trying to help streamline this process by automating all this stuff. The building and the testing actually all happens on the server. So, once the developer checks it in, it’s fire and forget. They can go on to the next task and check with the dashboard to see what the result of that was later.

Gardner: So, a rundown Rob, if you will, about what Gauntlet is? How it’s priced? What’s its architecture? Give us just a quick elevator description of what it is we’re actually talking about here.

Cheng: Sure. Gauntlet, as we talked about earlier, is a continuous build-and-test automation solution. Essentially, it’s a server-based product, server software.

It’s charged by the seat. It does interact with the version control systems that work with StarTeam, and we are constantly looking at also increasing the range of version control systems or SCM systems that we support.

Gardner: What have the results been so far? Are you going to come out with a new version or major release in early Q1 of 2007?

Cheng: That’s right.

Gardner: What have been some of the results so far? How has the field reacted to this?

Cheng: Right. The release in early Q1 of 2007 is actually the first official production release. We acquired Gauntlet in February, and since then we have doing a number of internal customer field trials as well as make a public early access release available. The feedback has been quite good.

I’ve been surprised by how quickly people have been able to get up to speed in using it and seeing benefit. The thing that’s really interesting about is that there are organizations, customers, and evaluators that are at all different phases and all different parts of the spectrum, when it comes to their occurrence, build, and development processes.

We have some that barely have unit tests. It was a feat to get them to actually have a build script that they can kick off in an automated fashion. Gauntlet gives them a framework, the central dashboard if you will, to monitor their progress, because it is one of their initiatives to improve. Part of what you need to do to build improve is to measure. You only get what you measure.

Gauntlet not only does the measurement, but it also does the visualization of it. So you can see from day to day, week to week, and project to project how things are progressing. You can see how often you’re able to build successfully, how much testing coverage you have from different projects, and how that is changing overtime. Are you increasing the coverage of testing that you have for your the different classes or different projects?

Then, we have other customers who are way on the other end of the spectrum, where they’re already very rapidly iterative. They are very agile and they see Gauntlet as a way to push that even further. They take their best practices and multiply the impact of them by offloading a lot of manual effort, doing it more on an automated way, and to giving the entire organization much more real-time feedback and better visibility about what’s going on?

Gardner: So, from their perspective of using this as a tool, they can find utility in it across the spectrum of maturation, in terms of where they are in their development and where they hope to go? That’s always a good descriptor of a long-term value. You mentioned something about visualizing a dashboard. Are these things that are designed for the architects or the project manager level, or is it some thing you can talk to the business people and say, “Here’s where we are. No guess work. We’re on track?” Is it designed for business people to engage with this as well?

Cheng: The Gauntlet dashboard currently is designed for development managers, project managers, and individual practitioners: the developers, the QA engineers, QA management, of course. The consequence of Gauntlet is that those managers, those project leads, the project managers, have the objective information to tell the business people what the actual information is.

They can tell what the status of the project is, what the risk is involved, how close they are to being able to actually ship, and if they know what the real stability is. They know what the confidence level is. A really good way of characterizing is that you’re giving developmental IT management much more confidence in how and what they say to business management?

Gardner: They can report to these business side folks with authority, because they do actually know where things are?

Cheng: Exactly. It’s fact based. It’s not just based on educated guesses.

Gardner: That notion of hope as a business strategy doesn’t have to kick in here.

Cheng: Actually, it’s not business strategy; it’s a recipe for failure and disaster. There often is too much -- what was one of the term that [former Federal Reserve Chairman Alan] Greenspan used -- an over abundance of optimism?

Gardner: Exuberance, perhaps?

Cheng: Perhaps that was it, but the overabundance of exuberance is really something that characterizes a lot of development in organizations sometimes. Gauntlet is a nice way to run a sanity check on that.

Gardner: One of the things you mentioned a moment ago about this spectrum of different organizations being able to apply this well gets to the heart of an area that’s always fascinating to me. That’s how to manage behavior, cultural shifts, individuals and in larger groups, getting them to change the way they think and move beyond a certain pattern of accomplishment, even though they feel it has probably been the only way up to a certain point.

Can you tell us little bit about how Gauntlet might be brought to bear on this issue of managed business processes, and how to get people to change the behavior? Can we really think about this as a way of orchestrating teams and behaviors? Or is that biting off a bit too much to chew?

Cheng: Yes and no. There is definitely something required as a forcing function, and it allows the adoption of more and more agile development. There’s usually a big failure or big problem.

One of our beta customers, for example, who is very aggressively adopting this technology, had what they called a brand-damaging, embarrassing failure event on their external customer-facing Website. They felt as if this was a symptom of the process failure that they had, and that was what really initiated their need to drive a change in process and in culture.

So, often there’ll be issues that people know they need to change, but they’re kind of set in their ways. They need something to spur them to action. Gauntlet does help in a sense that once somebody -- it doesn’t even have to be the entire company, the entire organization -- gets it in their head that they need to try this or they want to experiment with the more iterative, more agile approach, Gauntlet really helps them climb that learning curve. They climb that ladder of progressing incrementally towards getting more effective in their processes.

It can be just simple things like tracking builds, making sure that you can automate your builds, and that you’re building successfully. Then, tracking your unit tests. Do you have enough unit tests? Are they succeeding? How much of the code base are your tests actually covering? A lot of those things you could figure out, but it would be a lot of extra overhead to manage that process manually.

Gardner: So, for those organizations that have decided that they need to move from a tactical ad-hoc approach to a more strategic processes-driven approach, this gives them a ramp and a tool to start moving swiftly in that direction.

Cheng: That’s right. When you talk about strategic, we talked earlier about the notion of software delivery as a managed business process. One of the things that characterize other business processes in organizations is that you can do real sophisticated analytics. You can do business intelligence. That’s one of things that Gauntlet is trying to bring to the table, because of being able to continuously test, measure, and collect all the data.

Gauntlet actually gives you this great wealth of information that you can then data mine. When you talk about strategy and process, you also have to think about how to optimize the process. How do organizations continuously improve processes, not just code or technology? How are they are doing the work itself? A lot of that comes down to being able to mine to do ad-hoc analytical queries against the data that’s been collected about how the organization is actually operating. That’s one of the things that Gauntlet really provides -- that data warehouse of activity and metrics around actual development actions.

Gardner: So, I’ll get more data, I‘ll be able to start analyzing it. And then I can start setting policies, and then be able to revisit those policies and, on an iterative basis, improve upon them. What can we tell people about this policy-based approach or policy enforcement up and down the process and up and down the development lifecycle?

Cheng: That’s a very good question. The issue of process is important. A lot of times, process decisions are made for very good reasons at a higher level, in the process office, in the CTO, or the CIO’s office. They’re made in conjunction and collaboration with the management of software development. It often doesn’t get down to the individual practitioners, or it’s hard to enforce, because it’s just something that you’re telling people you’re managing that they have to do. How do you discipline it, and how do you enforce it?

One thing that Gauntlet allows you to do is make policy decisions at the point of insertion, at the point of code entering the system. Earlier, I talked about how we can essentially gate the promotion of code, the integration of code changes into different controls, based on whether they’ll be all that successful or whether test passed? Well, this is also something like you use much more generically as a framework, so that you can embed policy into that point as well. We can make decisions about requirements around maintainability, the complexity of the code, and the readability of the code.

If we have tools, they’ll help us analyze security, vulnerabilities or even such things as license compliance. Are you introducing unapproved third party’s libraries as open source libraries and packages? All these types of issues have the same characteristic cost curve, which is the later you find out about problems, the much more expensive it is to remediate.

Gardner: It also sounds like you can capture knowledge and competencies and then extend them, reuse them in a sense. This leads us into my next set of questions. What’s coming down in the future around these sorts of benefits, as we think about things like managed services and services-oriented architecture, and continuous ecology development of services, where there really isn’t just a cut-off date? As people consume these services, you’re going to adjust them, and they’re going to be working under service-level agreements. Is the Gauntlet approach something that’s going to become necessary as we move into that new arena of constantly dynamic development?

Cheng: Absolutely. In fact, a couple of words that you said were really resonating with me. One of them is “competencies.” From the competency perspective, one of the things that really breaks the back of development organizations sometimes -- and I’ve heard this a number of times from development directors – is that there may be dependencies in your system that you’re not really aware of. You don’t really think about them until they’re broken.

One of those is the human element, where there may be one person in the entire organization who knows how to put the software together. You only have one person who knows how to build the software, and that person leaves the company. You’re kind of hosed. You may have weeks or months worth of catch-up to get that knowledge back, but it ought to be institutional knowledge.

Gardner: Right.

Cheng: That shouldn’t be somebody’s personal expertise. The company or the development organization is running on that knowledge. Gauntlet helps to capture that in a centralized way and in an automated way, and share it with everyone.

This is also true of the situations when you have maybe niche platforms that you are trying to support or niche environments. There’s only one guy doing it, but you feel like it’s okay. Then, later there’s a customer escalation, because they’re that one big customer that happens to use that platform. And, by the way, the institutional knowledge is now gone. Again, the idea that we could capture that in a system, which actually is doubling as a means of collaboration, is an important one.

The second part about being able to have more services-oriented approaches, more dynamic development processes, also speaks to the issue of globally distributed and outsourced teams. One of the things that Gauntlet can bring to the table there is measurement. A big problem with outsourcing is how do we know what the cost benefit is? I know what the cost is, but we don’t know what the benefit is.

Gardner: Right.

Cheng: We don’t know how effective it is? We have no way to measure productivity or quality of the deliverables. Gauntlet, with frequent objective fact-based measurement, can start giving you answers to those kinds of questions. On the other hand, we also have the ability to do that process enforcement we’re talking about or the policy enforcement. Once I made a determination about the relative effectiveness of different teams, I can put different policies on the different teams.

Gardner: That strikes me as essential, if you want to go from the perception of IT as a cost center to a value center, moving the yardstick up in terms of getting more discretionary spending and more innovative types of projects that are going to be brought to the table and funded.

Cheng: That’s absolutely true. When you talk about that perspective and also the SOA arguments, all of it is predicated on the ability of someone in the IT organization convincing those with the purse strings that they can deliver predictably and they can deliver to target in a managed way.

Gardner: Give us a little bit of a road map if you could, as to what the, purview of Gauntlet is. I think that it’s mostly focused on Enterprise Java development at this time. Where do you see its boundaries or how do you expect it to evolve?

Cheng: The great thing about Gauntlet is that from a framework perspective, it’s as agnostic -- particularly of your language and your development --as version control itself. You can store anything. It doesn’t even have to be source code. And, you can do documentation and other types of content management essentially through version control.

Gauntlet does provide that same framework to be able to invoke and then analyze the results of tests and other measurements that you do. But, you’re quite right that in the first release we are very focused on Enterprise Java. That’s where the ecosystem of the test and analytic capabilities is really focused, but we will be aggressively moving over the next year to support additional languages, environments and systems with .NET development, with C, C++ development.

These are all areas in which customers really want to be able to leverage Gauntlet as well. So, we’ll definitely be moving to that direction and we’ll also be expanding, as I mentioned earlier, the version control on SCM support that we’ll have.

Gardner: And this is already something that’s usually used in conjunction with open source and the Eclipse-based development.

Cheng: Absolutely. This acquisition was from a start up that was almost a 100 percent open-source stack, and it does have extremely effective networking with the sub version that was the original SCM version control system. It leverages NAnt and JUnit as tools for building and unit testing. We can configure it to work with a number of other open-source tools and analytical packages.

At a higher level, it’s also a way bringing some of the best practices of open-source development to commercial customers. One of the things about open source development is that it’s very transparent. I can go to the Website or the public repository and see what’s happening. I can see who did what, when, who broke what, who fixed what?

Earlier we talked about how we start nudging cultural change. One great way to do it is having the kind of transparency that promotes peer-to-peer accountability, as opposed to top-down management. You don’t want to be the one who’s embarrassed by breaking everything. And, on the flip side, you want to be the one who’s recognized as making the most contributions. That’s true in open source, and we think that it could be just as true in improving commercial proprietary software development.

Gardner: Great. Well, thanks. I think that wraps it up for our time allotment today. We’ve been discussing productivity in development and bringing more visibility and accountability in data, fact-based development, if you will.

To work through this discussion, we’ve been joined by Rob Cheng. He’s the Director of Developer Solutions at Borland Software. We’ve been discussing a product called Gauntlet that will be coming to market in full maturity in Q1 of 2007. Thank you for joining, Rob.

Cheng: Thank you very much, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast. Thanks for listening.

Listen to the podcast here.

Podcast sponsor: Borland Software, Inc.

Transcript of Dana Gardner’s BriefingsDirect podcast on development process management. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.