Jeff Johnstone of TechExcel explains why there is a need for a new approach to application lifecycle management that better reflects the business requirements and challenges facing development teams.
MIKE Vizard: Hello and welcome to another Premium Edition of the ACM Queuecast, with your host, Mike Vizard. This edition of the Premium Queuecast is brought to you by TechExcel, which is the leading provider of tools that bridge the gap between product development and service and support, and today we'll be talking to Jeff Johnstone, who's the senior director of sales. Jeff, welcome to the show.
JEFF Johnstone Welcome -- it's good to be here.
Vizard: One of the things it strikes about ALM is that the concept has been around for awhile but back in the day when developers were kind of like the high priestess of their companies and they went in there and did their own thing. ALM meant one thing, but today, it feels like developers are much more of a service tied to the rest of the business and there's always hidden stakeholders. So how does the approach to ALM need to change as the business and the technology become tightly connected?
Johnstone It's a very good point. I think that fundamentally development is thought of, has become more of a business process than simply a set of tools. In the past, like you said, developers and development organizations were kind of on their own. They were fairly autonomous and they would do things that were appropriate for each piece of the process and they would adopt technologies that were appropriate at a technology and tool level, but they didn't really think of themselves as an integral part of any higher business process. I think that that's changing, and I think that as development itself becomes more strategic, more dynamic, more tied to business goals and business processes, the tools that have historically been used to manage the development are not really adequate for applying some of the more business process methodologies and integration requirements of other areas of the company.
I think a new breed of products is required for that, and that's really where TechExcel's focus is.
Vizard: So how do I go about building something like that if I wanted to bring that into my company?
Johnstone Really the most important piece is for each organization to understand what their goals are, and what their process should be, and what their priorities are, but if we take a business process approach to development, the fundamental first step of a business process management is understanding the process itself that underlies what you're trying to implement of the tool. So organizations need to understand how does their customer support department need to communicate with development, whether it's handing out bugs for customers or feature requests. How do marketing and sales need to provide feedback to development for future releases, coming releases, prioritizing issues there. How does the development organization itself need to define upcoming releases, features, priorities, and the list of possible enhancements and features is usually endless for most systems or products, and it's critical that you get a handle on what you are generally committing to.
So the organization first needs to understand their role in terms of the organization, from customer support, sales, marketing, development itself, and then you simply begin to apply those business process requirements to a suite of tools like TechExcel's, that allows you to then manage everything from requirements, specifications, planning, implementation, QA testing, bug tracking, et cetera, but not from a tools perspective, really more from an integration of business process perspective and the capabilities that we provide to these organizations to configure their processes are very intuitive. So you're not having to create your own code that implements a process. You're simply drawing a process into our tool or you're configuring workflow options or you're choosing what kind of automation you want between customer support and development, but the fundamental structure and architecture and framework is built in for you.
So that process of mapping your requirements is quite easy. In some cases, in fact, probably in most cases, the hardest part is understanding your requirements to the point that you know exactly what you're trying to achieve.
Vizard: Does that mean then I have to change my processes as a developer to fit the framework or that the framework's extensible enough to adjust to any number of processes per se?
Johnstone Yes. The DevSuite framework is designed specifically to allow every developer organization to adopt their own methodologies and frameworks. You can be a fully agile development shop. You can have your own custom processes. It could be partly waterfall, partly agile, iterative development -- any combination of these methodologies or something completely new you come up with -- that is independent of DevSuite. DevSuite is designed to facilitate virtually any process, whether it's a controlled linear process or a dynamic iterative agile process, the tools should not and cannot drive how you run your business.
Your business has to drive how you use the tools. That's the way DevSuite is designed from the very beginning.
Vizard: Now most organizations have to really want to change to make the change happen. It's kind of like that old joke from psychology. How do you make a group of developers, or entice or incent, a group of developers to want to change the way they're doing things to adopt something that feels almost like a rightbrained structured approach to a leftbrain activity?
Johnstone Yes, that's a great question. The reality is you don't have to do that. The people who care about process and the people who care about this integration and communication and collaboration are people in management roles and managers, directors, VP's, et cetera. Those people do need to worry about this. They're being paid to worry about it, and how do they make things more efficient, how do they collaborate with other groups, et cetera? But that doesn't mean that the developers themselves need to worry about it or necessarily even be aware of it at the development level.
The developers in fact may be working entirely in the IDE, whether it's Perforce or Accurev or Team Foundation Server -- whatever their development environment is -- the developers may never leave that. We have tools and integration modules that allow changes made in those tools to automatically reflect issues in DevTrack and associate the appropriate source code, control files with the DevTrack issues.
So the reality is, if you do it right, the process is transparent to the developers. They code what they need to code. However, it's still important that the developers be clearly in communication and are aware of what the goals are. You can't just go and begin coding without knowing what you're trying to accomplish.
That's where the collaboration benefits really come in, is by having this process-driven set of tools for prioritizing requirements and specifying releases and going through an approval process to make sure that the feature set and enhancements, the bug-fix list, is at a management level approved and agreed-upon by everybody. The people who are assigned those tasks have access to that information when it's necessary. So they can say, okay, I've been asked to implement this new printing engine. I wonder what they're talking about. Right at their fingertips then is a list of all of this history, that says, oh, I see that sales wanted me to do this, and marketing wants something else, and three customers had a request, and the VP of Engineering was something else, and they can see that right at their fingertips as they begin to work on this, but their daily work fundamentally doesn't change.
They're still writing code in their IDE, but with the integration layers facilitating the communication and collaboration and process management that the managers of the department really care about.
Vizard: You just touched on one of those hot issues that has been with us forever, but it feels like to me the end-customer or the business person comes up with an ideal scenario for how they want their software to work. Then they hand that off to a business analyst that does their best job at crafting a document that a developer can read and the developer crafts their best interpretation of that, sends it back to the business analyst and then back to the end-customer, and 80 percent of the time, the end-customer is not happy and that's why we have such a high failure rate on apps.
Can this process improve the whole quality assurance process, I guess I'll call it that for the moment, where people will have a better sense of what's going on during the process and it'll be more iterative so we'll have less tissue rejection when the final application finally comes back to the enduser?
Johnstone Yes, absolutely. It reminds me of a wonderful old cartoon where there's this whole product development cycle of making this swing more and more complicated into the last frame as the customer really wanted a rocking chair or a tire swing or something totally different than what was designed and delivered.
The whole concept of DevSpec which is our newest product, is ensuring that the requirements coming from your customers are going through a process of review and approvals and communication and flowing all the way through to development, NQA, to ensure that what you release is what was planned, what was planned is what was expected. DevSpec actually has taken a fundamentally new approach to requirements management. Typically, requirements management tools in the past have been about version control, about checking in, checking out documents, and maybe having the status of these documents, and they'd be having a list of requirements that you're going to implement.
The approach that we have taken is that requirements management is a dynamic, living process that involves a much broader set of people. So the DevSpec allows you to have requirements come in as suggestions from customers from marketing, from tech support, from engineering, any source can submit this requirement, and a requirement goes through a lifecycle. A definable process with reviews and approvals and owners and status changes as appropriate for your companies. It doesn't have to be very elaborate. It can be very simple, but the requirements go through a process and ultimately those requirements are compiled into a set of specifications, and the specifications then become what we call the conceptual product, and this is a really important concept because the conceptual product is dynamic, and it's changing over time. So if you're in an agile development environment, you may be changing your specifications every two weeks as you're going through different iterations of your software, you're tweaking things.
But as those things change, everybody involved is kept in the loop. You can configure the system to notify everybody from the submitters of these requirements to the support team, the QA manager. Every requirement or every specification is going to have links, implementation, development work items, linked QA test cases, linked documentation work, and whenever these specifications change, in a very dynamic environment, this could be daily or weekly, everybody who owns all of those other related aspects of the cycle is going to be automatically notified of these changes and the record is flagged, so that this test case that tested the feature as defined last week, needs to be reviewed because that feature has now been revised.
And the developers who are working on five different pieces of codes to implement one feature, those work items for each of those development areas, are flagged because the specification underneath that has changed.
We also have a lot more collaboration, business process tools, like voting where you might get a list of 500 feature requirements submitted from everybody that's ever been involved with your company, and you only have resources to implement 100 of them. So we have voting, where you can assign maybe 500 points to the VP of Development, 100 points to the product manager, and 100 points to the sales guys, and they can all allocate their points to the different requirements, and you immediately see, ah-ha, based on everybody involved allocating their set of points. I can see the top 50 features we have to implement based on a rollup of these voting points, and then you can begin to manage the rest of them.
We also have dynamic what-if scenarios. So you can look at multiple combinations of these requirement specifications and look at resource impact, vote totals for different options, timeline implications for different options. So that the whole process of developing your conceptual product, which is that current dynamic state of all of these specifications is designed to bring in many different people and keep them informed as things change.
In previous systems, you check into requirements, nobody knows about it. The QA guys are already off testing the latest bills based on the test case designed against the previous version of the feature which isn't even what you're trying to accomplish anymore. So the whole point of DevSuite with this new approach to requirements management of DevSpec is to increase the scope of the team in terms of who is involved in this process beyond the developers themselves, ensure that everybody is in communication, that everybody has appropriate visibility and access and input to this system, but each individual worker, whether it's a developer or a QA tester or a documentation writer or a manager or architect, all these people still have a very finite view of what they're working on and their life hasn't changed that much.
They simply are writing the code, writing the test cases, doing the documentation, but what is coming to them, what is being fed into their queue of assigned tasks is clearly defined and it has a dynamic link embedded within that, where they will always be able to see that current version of that feature's conceptual definition as it's being revised constantly.
Vizard: Does that help create something of an audit trail that people can follow as to how something was developed that may help on compliance, but more importantly it helps the company capture the intellectual capital that went into the application.
Johnstone Absolutely. There are two aspects of that. One is something changes. Somebody changed the priority. Somebody shifted a schedule and it dropped off the list, and now we have our 5.0 Release out the door, what happened to that feature that somebody told me was going to be here and is gone. So there is certainly an audit trail in terms of who did what, when. Who made the change, who made the decision.
We can even prevent those changes from being made at all, without certain levels of approval, if that's part of the defined business process.
The other aspect is that for things that are intentionally and consciously agreed to move on, you don't lose them next-time. They're still waiting in that queue. So when you get to the 5.1 Release, you have this queue of everything that was intentionally postponed out of the 5.0 Release, and here's everything that's still in this requirements bucket we need to go and vote on again and make sure we don't forget about.
The lifecycle of these requirements doesn't end with the release. They're living from release to release until you move them into a completely canceled or projector status. They're going to stay in that queue with the entire history to ensure that you're not losing ideas and information just because you happen to not put it into a given release.
Vizard: How complicated is it to set something up like this? Do I need 10 guys in lab coats? It feels like it touches multiple parts of the business and has different layers in it.
Johnstone Yes. It's surprisingly easy. The hard part is at the beginning and is understanding your business process of what you're trying to achieve and how you enlighten the teams to work together. But even if you don't have that fully defined, the architecture of our administration application is such that it provides a framework for you. It essentially walks you through the various aspects that you think about, the field structure of data you want to track for requirements, for specifications, versus bugs versus test cases. The kinds of things you want to report against.
What kind of process -- each of these areas has their own process. Would you like it to be totally flexible and free-form, it's just open and closed? Would you like to have some enforced workflow? These are all simply options you choose, but the admin allows you to walk through our embedded framework and use that as a guide to thinking about your business.
Ultimately, you still need to come up with your requirements for a business perspective, but the framework of our own admin oftentimes is a good vehicle for allowing companies to do that.
Once they've had that clear in their minds, the actual configuration is quite easy because it's all done through the point-and-click admin application. There's no programming. No scripting. No database work. You simply, through choosing some options and entering some labels and drawing some connector lines between workflow states, you enable your process into the options that are provided for you within that framework.
Vizard: Since everybody is always a little sensitive on the acquisition costs, what does it cost to set this up and how is the licensing structured?
Johnstone The licensing is per user based, and the DevSuite has five different products. There's DevSpec, which is the requirements management piece. Knowledgewise is the underlying knowledgebase structure. DevTrack -- I'm sorry, DevPlan, which is the project planning piece, which will flow out of DevSpec. DevTrack, which is development management implementation, bug-tracking. And then DevTest which is QA testing. Depending on which of those modules you choose, and you can implement the ones that are appropriate, the price ranges from about $500 to $1,000 per person, depending on which modules you choose.
For some teams, small companies, we actually have a small company, under 100 employees, a discounted rate that we have to talk about with any small companies who want to pursue that with us.
Vizard: And can you give an example of somebody who's using this approach and how they maybe on the back of an envelope calculation about how they measure their ROI or what was the -- how did they justify it back to the business?
Johnstone Yes. We have quite a few customers that have well over a thousand users, and obviously the bottomline impact is going to be much greater, the larger the team. If you have two guys sitting in a living room writing code, you're not going to be having the impact of a 1,000-user team.
But what we have seen from our largest customers really is an improved sense of efficiency, communication, and collaboration, tracking and analysis, that really ties together the whole process from defining your release, implementing the QA testing and release. In terms of true ROI, we hear numbers from 10 percent to 40 percent bottomline improvement, but ROIs are a real nonscientific calculation when it comes down to things like this. It's really about how do you ensure that you are going to release what you intend to release when you intend to release it, and how do you ensure that what you intend to release is what the market needs based on your sales input, customer input? So, that is intangible.
Having the right products to market at the right time is almost infinitely valuable in terms of pure efficiencies, in terms of people not duplicating effort and things going through the right process, the right time, you're going to get 10 to 30 percent bottomline efficiency improvement right there.
Vizard: And so, I guess a final question, what would be your best advice given all your experience with the customers you have to an organization that was trying to figure out a more structured approach to innovation?
Johnstone I would first look at your organization's goals and say, are you product-focused? Is the release, the dependable release, both timing and quality and content critical to your business? And that's going to determine how important a system like this is. If you're developing systems that are low priority and not time critical and these things become less and less important. So for organizations where the release, contents, timing, and quality are mission critical, which certainly any product company where you design your products that's going to be the case, you really have to look at the organization.
Is customer support working efficiently with development to resolve bugs? Is the marketing and sales organization communicating effectively to project management, product management, to define future releases? Are we consistently developing and delivering builds that meet the definition and scope we've defined? If the answer is yes to all of that, everything is efficient and everybody is working together and everything is on time, then great, keep doing whatever you're doing.
If you ask those questions, you say, you know what, we really could improve and need to improve the communication and the collaboration and the quality and the schedules that we can guarantee and commit to, that's when you need to say, okay, the only way to achieve that is through some sort of integrated suite of products that allows me to have an end to end solution all the way from sales, marketing support, through product management's requirements, planning implementation and testing, and if you have a suite of products like that, that allows you to easily implement your own business requirements and apply your needs and your management style to this suite, you're going to be much more efficient and end up with better products to market faster.
Vizard: Moderator's prerogative here, but I'm going to ask one more question. So given the fact that ALM has been around for such a long time, and you had to wrap it up in a nutshell, what makes TechExcel different than everybody else in their space?
Johnstone I guess there are a couple of things. One, we first developed DevTrack about 10 years ago, so, in 1996, 1997, we released the first version of DevTrack, and DevTrack from the very beginning has been a workflow-focused, process-focused tool, originally it was a bug-tracking tool. But on its heels, we released ServiceWise which is our customer support application. So from almost the very beginning, we've had a perspective of integrating bug tracking with customer support from a business process point of view as well as an architecture point of view. So everything we have done in the last 10 years, has been from a perspective of integrating multiple teams with one common core set of data, through definable business processes, and as we've expanded our service suite of products from customer support and sales management to an IT service management and expanded DevTrack into the full DevSuite, the perspective we've come from has always been how do we enable multiple teams to work together in easily-definable processes?
And I think most other vendors in this space have come from a tools perspective where they had a set of tools, a set of point solutions that many of them were very, very good tools, but they didn't come from a business process point of view and certainly almost no one came from the perspective of integrating customer support development which is where we were 10 years ago. I think that original perspective has really given us a unique approach, even within just the DevSuite, of how we manage multiple teams and how we efficiently allow our customers to define their unique requirements.
Vizard: All right, this has been another Premium Edition of the ACM Queuecast. This edition is sponsored by TechExcel. You can find more about it at www.TechExcel.com. They are the leading provider of tools for bridging the gap between product development and service and support. As your host, Mike Vizard, I want to thank Jeff for sharing his knowledge, and we wish him the best of luck.
Johnstone Okay, thank you!
Originally published in Queue vol. 5, no. 4—
see this item in the ACM Digital Library