Matt: Greetings. Welcome to The Modern Mainframe, I’m Matt DeLaere. Thanks for joining us for chapter four in our series, Building a Better Software Delivery Program where we discuss how you can build a world class delivery system by leveraging DevOps and Agile methodologies. We have a new podcast every Monday, followed by Office Hour with Rick Slade, a live online Q&A session each Friday.
Speaking of… Here’s the man himself, Compare Executive DevOps Solution Architect Rick Slade. Hey, Rick, how are you?
Rick: I’m good, Matt, glad to be with you. Good day.
Matt: Good. Good to have you here. So, through the first three episodes, and the Q&A sessions, one thing that keeps popping into my head is getting started, where to start, how to start. Rebuilding a system like this can probably seem a bit overwhelming when you’re looking at it as a whole. And as it so happens, today’s topic is getting started with your software delivery system modernization project. So, I’m trying to find a way to get started with talking about getting started. So, let’s go back to the start, the reasoning. Why is evolving your software delivery system so important?
Rick: It’s critical, Matt. I think the industry, the business world, as we know it, especially today with COVID-19, it’s changing the way we work. I think this change has been ongoing for a long time, now, but how individuals interact with one another, how individuals interact with commerce, I think, is changing. And I think this terrible virus is contributing to the expediency of this transition and from a business standpoint, or from an organizational standpoint, a desire to modernize the means by which you can produce software and deliver software is becoming more and more critical.
Chris O’Malley, our CEO, says it a lot and he’s absolutely right: fast does beat slow. And so, as new organizations are continuing to sprout up and provide business services, and deliver new products, most of them, in today’s world, are able to do that at speed that the traditional business, brick-and-mortars, are struggling to achieve. And so, if we’re going to compete effectively with those organizations that are moving fast, then we’ve got to adjust the means by which we produce software to meet those velocity requirements.
The good news is that— I mean, I’m an old football player and one thing that I do remember is fast definitely beats slow from a football standpoint, but big and fast really beats slow. And so, I think there’s the opportunity for large organizations, traditional organizations, with the resources that they have available to them, if those organizations can evolve their traditional software delivery methods into more modern means of delivering software, then the advantage, I think, will shift back to those organizations with these resources. But they’ve got to be able to become Agile, they’ve got to be able to respond quickly to changing conditions in the marketplace and evolving, modernizing.
Their software delivery is just going to become very, very critical, and there’s some advantages to evolving the business environment, anyway. You look at the incorporation of automation into that software delivery process. I tell people, customers, all the time that the beauty of automation is not just the improvements in speed of the tasks required to produce software, but you’re actually, through automation, able to codify the best of what you do.
And so, if you’ve got resources who are really good at managing work and executing work within that software delivery life cycle (SDLC), your ability to codify or to automate their methods, their tooling resources, their ways of testing, their ways of deploying—if I can codify that, then I capture the best of what I do. Right now, when you’re delivering software, essentially you’re dependent upon the resources that are doing the work, and in most organizations you’ve got a traditional bell curve, you’re going to have people who do it really, really well and you’re going to have people that they don’t do it so well. And a lot of times that slowest resource or slowest capability is going to slow you down.
With automation, we can take the best of what we do from a process standpoint, from a tooling standpoint, and apply that to all the work that is required within that SDLC. So, I think automation is an incredible opportunity not only to get faster, but to get better and to produce higher-quality software through the codification of those best practices.
Another reason, and I think this is important in today’s time, is talent acquisition and retention of that talent. Resources coming out of universities are typically not exposed to the development platform that I was exposed to, coming out of school. And so, taking those very talented resources, and being able to attain or acquire those resources, you want to provide an environment, by which they can flourish for one thing, from a business standpoint, but maybe just as importantly, something that they want to do, it’s going to be—and not in all cases, I hate to stereotype anybody—but in most cases, providing a modern environment that aligns very closely with the way that they were educated or the way that they have been developing software and providing that same type of ecosystem for the mainframe, I think is, I think it’s very important.
And again, the reasons to do that are more business-oriented than anything else. Your ability to reduce the learning curve, your ability to bring new resources in who may not have experience on the mainframe and to get them productive quickly is again, another driver for modernizing your environment. So, acquiring that talent and then it’s retaining that talent, I think, is another driver for the “Why?” question with regard to modernization or delivery modernization.
And then the one last thing I’ll say with regard to the reason why, is it gives you a modern development system with modern tooling, will give you better opportunities to leverage new capabilities like automation, like continuous integration, like continuous delivery. A modern ecosystem will give you the ability to integrate and to leverage existing investments that may have been made on the non-mainframe side. Your ability to leverage those with a modern mainframe software development environment is greatly enhanced, and so, the ability to connect or to support techniques like parallel programming under a modern infrastructure is going to obviously be easier to do under modern tooling. So, that ability to leverage new capabilities, and to leverage new methods for continuous integration, continuous delivery, are done under a modern supporting toolset.
Matt: So, once the company or organization decides that they’re going to follow through with the project, what’s first in terms of what they’re going to implement, like processes, or are they going to implement the tooling, or do a little bit of both, the same time?
Rick: That’s the $64,000 question, Matt, for a lot of organizations. I’ve seen it successful both ways, so I don’t want to say that it can’t be successful one way or the other. Here’s what I believe:
I believe that it’s more important to implement modern tooling, even under traditional methods than to begin with rolling out Agile processes before you roll out tooling. I think in a perfect world, those two are going to be very closely aligned. But the reason I say that is, I look at our own experience at Compuware—our labs and our marketing people put together a wonderful eBook called “The 10 Steps to DevOps.” And in that book—and Dave Rizzo, who we talked with last week, will tell you the same thing—one of the first things that we did was to implement modern tooling and getting developers and testers used to navigating those technologies and still gaining some productivity gains, even with traditional methods, served us better than trying to leverage existing technologies under a new way of developing software.
So, think about it, if you’re going to go and educate on Agile without providing tools that can support an Agile delivery process, it’s very difficult. I’m actually working with some clients right now that followed that traditional mindset, if you think about it. They began, they wanted to go Agile, they believed in Agile and moved very quickly to train resources on how to deliver software from an Agile perspective. The tooling came later… Alright, in fact, in one case they’re still working on it, and it’s actually slowed them down because they’re dependent upon technologies that were built or, designed to support the traditional waterfall methods.
I’ll give you one practical example. The SCM is a significant reason why, at least on the mainframe side, why you see a lot of stop and goes and even failures trying to leverage Agile as a method. No support for parallel development, the inability to provide capability to the developer to continuously integrate, lack of merge capabilities as you move from a feature branch to a release branch, and so on and so on. And so, I believe that putting together the tooling very closely followed up with Agile training is the fastest, quickest way to get people comfortable in a culture change like this. Because if you start with new tooling but at least maintain the way that they’re doing work today, at least they’re comfortable with the process. To change the process and to change the tooling, at the same time, becomes very difficult, especially for those of us who have been on the mainframe for a long, long time.
So, I think that’s the answer to what goes first, but again, I’ve seen it work in both ways.
Matt: Yeah, I’m sure it would be difficult to do both at the same time.
Rick: Yeah. The next thing with regard to first steps is education. We’ve got to make the stakeholders within that software development life cycle, they need to understand the value of this change. Because it’s not insignificant, it’s going to require investment by the organization, it’s going to require organizational change, it will require new skills from a tooling standpoint and a process standpoint. So, education is absolutely critical. And it’s not just the users of this system that need to be educated, it’s maybe even more important that the business executives and business owners of these different applications, understand its value as well because they’re going to be asked to operate a little differently with regard to how they interact with IT. So, educating the business owners, the executives is very important in making this work—they need to buy in.
One of the things that we know has made a difference in organizations that have taken on this shift, it definitely requires buy-in at the top. It’s not so much to have your thumb on someone and pushing them, “You will do this or else,” although I’ve seen that work, too—it’s more to provide the leadership and to provide the support required to make this happen, because again, you’re asking them, you’re asking… not only for the developers and testers to make a change, but you’re also asking the business to make a change in how work is and output is provided to them.
So, getting those executives educated, getting their buy-in, having them truly understand the value of Agile and DevOps—it will be critical to your success and it needs to be one of the first things that you do prior to trying to build out our evolve your software delivery systems. One of the things when I work with clients to build out a transition plan, at the top of the list is identifying, and I’ll use the word commissioning, an executive sponsor and a product owner—I think that is just absolutely critical. And that executive needs to understand the changes that are going to take place, and the value of those changes.
That product owner is essential. Let me spend just a few minutes talking about that because when you hear the word product owner… I was talking to someone within our organization the other day and you don’t hear the term or the title product owner in the IT organization other than as someone who is responsible for a traditional business application. What I’m talking about from a product owner standpoint here are things that we’ve discussed earlier—the product owner of that software delivery system, there needs to be someone identified and made accountable for its effectiveness.
And so, I think that’s one of the first things that has to be done. And then once that product owner for that software delivery system within the organization is identified, then he or she can go to work in defining what that transition plan will look like in conjunction with those impacted and affected by it.
I guess I’ll wrap up this first step section by saying that once that product owner and executive sponsor are identified, one of their first jobs is to identify and to build a software delivery system team. Now, that team is going to be responsible, and I’ll talk a few minutes more about that later, about their responsibilities, but building that team that’s going to be responsible for the software delivery system, not the retail banking system, or not the shop floor control system, or not the HR system, but the software delivery system—that’s what they’re going to own is what they’re going to be responsible for. And this team will be required and will support the implementation and delivery of the software delivery system to their users; their users being application, Agile teams, teams of developers and teams of testers. And so, picking that team is critical.
And the other thing I’d say, some people get a little scared when I say “team,” because it implies a large number of people, it doesn’t have to be… In fact, I like moving incrementally. If you’re a follower of Agile and you appreciate incremental evolution of these systems because, I think, I’ll talk about this, the speed advantages that incremental delivery can provide, so that resource may not be a team of five, it may be a team of two, initially—two developers, or a developer and a tester.
When I was doing this back in the ’80s, we didn’t call it that, we weren’t using or it wasn’t defined as Agile, we were still doing waterfall. But we were, a company I worked for, was very driven to ensure that our software delivery efforts were as efficient as possible and one of the things that also I was asked to do was to lead that team. And I was a team of one. So, I was the, essentially the product owner, the developer and the tester, initially. Now, over time, as we started to scale and as we started to roll that system out across the organization, and it was a large organization then, the number of resources… there were some resources that were added to that team, but it was a traditional project team, not like what you would see today, and identifying that team is critical.
The skills, you’ve got to have someone, people on those teams that are open to new ideas, new ways of thinking about things. They’ve got to be… I think you’ve got to have a strong understanding of Agile, an understanding of DevOps and a reasonable understanding of the existing SDLC within the organization for different teams. And so, it’s not an easy resource to find. It should be a senior resource initially, in the beginning of this, because they’re going to do some of the design work as well as some of the implementation work. But getting that team started is, is absolutely critical. And just like with any IT resource, getting the right people is of 80% the game. If you can find the right people and they’re incentive and they’re motivated, then this becomes something that’s definitely manageable, and definitely doable.
Matt: Now, this is kind of a rookie question, but in terms of job responsibilities, overall, are people or how many people would be dedicated solely to building this or would this be something that they are add on to their regular job responsibilities?
Rick: I will give you a good consulting answer to that. The response is, “it depends,” and the reason is it depends on the scale in which you’re going to implement with regards to the number of people. Again, I am a big believer in, let’s start reasonably small from a practical standpoint, and let’s figure out what the requirements for that software delivery system are, and let’s implement that and let’s test it.
One of the things that has served me well in my years of doing this is, I’ve seen so many organizations that will look at new technologies and think that, “All I’ve got to do is to purchase this technology, put the box on the developer’s desk and then walk away. And they’re going to become immediately more productive.” And it fails, almost all the time.
So, I’m a big believer in that, and it’s the role of that SDS team to not only install, configure, and implement, but to test the heck out of that software before it’s rolled out to the actual users, which are the developers and testers who are going to be using this system to develop and test and deliver software. And so, it depends on the size of the team, but it also depends on the initial target application that you’re focused on.
One of the key decisions, starting a transformation project, is to identify that initial target application project team. Again, I believe that it’s failure to take this and to try to roll all these new capabilities and all these processes or process changes out to everyone at one time.
I think it’s impossible to implement, I think it’s difficult for the users, and there’s no way that the typical organization can support this at a reasonable cost from a business standpoint. So, identifying that initial application project team that you’re going to leverage is critical, it’s also important because you need the input or the feedback from that initial project team with regards to the application architecture that they’re supporting. You go in most organizations, and even from team to team, certainly from application to application the architecture is going to be different. Well, that architecture has an impact on the requirements and the capabilities of the software delivery system. Now, as we stated last week, or a couple weeks ago, there are a certainly core components, the IDE, the SCM and there will be others that are just core to software development regardless of team, primarily—I’ve seen even exceptions to that. But primarily, those things are common but there will also from team to team be what I like to refer to as architectural idiosyncrasies that will require different capabilities and different features in that software delivery system for that particular application of that team.
And so, selecting that team is important, and there’s some initial target team characteristics that I think are very important and should be check marks in the selection of that team or teams. They should be very representative—I’m talking about the application team, the team that are going to be users of your delivery system—representative of other teams—most teams within the organization—as to how they’re structured, how they operate.
I think that that selecting a project within that application team, one that is certainly important, but maybe one that’s not critical to the business. Because again, what you’re trying to do is that you’re trying to build a software delivery system, and you’re going to have stops and starts, you’re going to have some issues initially in getting that system out, you’re going to find things that you didn’t know were going to be problems, you’re going to see successes that you didn’t expect. So, finding something that is important, that will test the bounds of yourself where delivery system, but not critically to the success of the business, I think is an important decision as well.
And then, finally, for that initial target team, the architecture of that particular application that that team is supporting needs to be fairly representative of many of the systems or applications within the company or within the government entity. So, the team itself and make up, organizational structure, ways of doing things needs to be represented, the application architecture that they’re supporting and will be making changes to using the new SDS or the evolved SDS having representative architecture is also critical and key in the initial selection of that first team.
Matt: Okay, I was at actually going to ask about that, so you answered it. But as you put together this team, and you start with one product or one project and then you move on to other projects that other developers are working on, would you add or subtract from the team at that point, maybe. Would you have the same number of specialists on the team at the beginning, the same people as you did as you progressed?
Rick: That’s a great question. And so, there’s going to be a core software delivery system team. Now these are people dedicated not to a business application, but they’re dedicated to the software delivery system, again, which is kind of a negative there, because I consider it a business application as well, but you know what I mean. There are going to be some dedicated people to the software delivery system team, and then each time they roll that particular software delivery system to another team there will be need to bring experts from the targeted application team to work with the SDs team to tweak or to add capabilities to the SDS that are required for that target team. And so, the number of resources may depend upon the scale and complexity of the application that you’re targeting the SDS to support.
And so, yeah, it could go up, it could go down. Now, my experience is that it typically stays about the same. Typically, if you’re working with Agile teams, and we’re talking the two-pizza-size team—seven to 12, 7-15 developers, then typically, it takes one or two resources in a sprint to make the necessary tweaks to the software delivery system in order to support their specific needs for their target. So, it will scale a little bit. But again, I use the word sprint there for a reason. Typically the tweaking of that SDS to target another team, once it’s been stabilized and you know what’s working, no more than two, three sprints to prepare and to get that SDS ready to accommodate the needs of your target application project team.
And so, it doesn’t take long, but it will require some skill and some expertise from that target team to make sure the SDS is going to be able to support the needs of that team. And again, that work, it needs to be done, I think it needs to be tested prior to rolling it out to the project team. But yeah, we’re not talking about a lot of time here, if the system is architected properly.
Matt: Okay, will the SDS team stay intact once the new system was implemented? Will they still be there, the product owner probably would be, would anybody else be involved?
Rick: I think it will, and I think it’s going to run the same course that any other business Agile team runs. If you think about teams that are set up to support an inventory control system—and it may be five to 12 people assigned to that team—there are a core group of people in that team that will live with that because they have expertise about that business application, that shop floor control system.
I think the same thing will be absolutely true for that software delivery system. There will be a core developer, maybe a core tester or plural, that will stay with that software delivery system team because their expertise is in the processes and the supporting technology to support software delivery. And not only are they going to play a role in the incremental maintenance and enhancements of that software delivery system because it’s going to evolve, it will continuously involve… I’ve seen people talk about the need to take that software delivery system and work itself out of a job over time. And I understand why people would say that, but I also believe that that’s not necessarily case because what I believe, what I’ve seen, my experience is that technology is constantly changing. The technology that we are using today to deliver software to our customers, even at Compuware, is different from the technology that we used even two years ago. Tools evolved, new capabilities are brought about.
And so, you’re constantly evaluating your SDS, you’re constantly making changes to make it better. And that typically is because of inclusion of new features and new capabilities that you want to make available to your users. And it’s the same paradigm that the business application Agile team faces, there will be core people supporting it, they will be constantly making changes to upgrade and update and to make it better, and I think the same thing will occur with the software delivery system team.
Matt: So, the SDS team, what are they doing that will be transferred to other teams? What kind of plan are they building?
Rick: Yeah, that initial work that that software delivery… once that team is defined and once you’ve selected your target team—and the reason I think it’s important to get that target team selected is, as I said, they’re going to be valuable input providers to that initial backlog—but one of the first jobs of that SDS team, and certainly the product owner has responsibility and accountability for it, is the build out of the initial build of that product backlog, and so, just like a product backlog for a business system, the product backlog for the SDS conceptually is going to be the same thing. It’s just a backlog and inventory of work to be done in order to build test and deliver a software delivery system to its users.
And so, being able to look at the current state of software delivery for that target team and understanding how they’re doing it today, is critical in building an SDS that’s going to be able to support that. Now, there will be changes to how work is done and certainly from a process standpoint, there will be tweaks and evolutions, but there will some changes in the tooling, but without an understanding of the intent and how work is done today, it’s hard to build that initial system or that initial minimal viable product from an SDS standpoint. And so, there’s some things that I think that can be done to get you the information that’s very critical in building that initial product backlog: understanding the roles and responsibilities of that target team and what they do, all the way from ideation, through design, through code development, through testing, through delivery, through operational deployment and support—understanding that entire process is very critical. And who was responsible for that work is critical.
One technique that I’ve used to help me understand that process and also to identify problems, or potential problems, within that existing process is the use of a value stream map. Now, people think about value stream mapping and they typically think of it at a larger organizational level. The McKinseys and some of the larger consultancies will come in and value stream map your organization to define your key value streams and where you got potential problems, issues within the delivery of that value.
I think the same thing is applicable within certain aspects of the world of the IT organization and specifically in this case, the SDLC, I think it is a value strength. The value is the production software used by customers, by employees, by partners to interact and to do commerce or to provide services. And so, mapping out that process, understanding where there are slowdowns, understanding where there is waste within that SDLC. Having an understanding of that process, and of the time required to deliver output through that process, that understanding is going to provide you incredible information.
I’m working on one right now for an organization. And it was an interesting one because it’s relatively easy to see where there is waste in your process from a time standpoint, and to see where quality or where defects are being introduced and where they’re being resolved—that information is critical. The one I was just with was an interesting one. They were very Agile shop, they were leveraging Agile processes, and so from an efficiency standpoint, there wasn’t a lot of waste. The problem that this organization had was that they were tied to—and this is for mainframe development—they were tied to very antiquated technologies, trying to leverage those technologies in support of their project work, which was Agile-based. And the issue was they just weren’t able to complete enough stories in a given sprint. You look—and these numbers vary, I understand that, I get that—but in a typical sprint you’re talking about 20 to 40 stories. I think most standards organizations will tell you that’s a good target where you should be. Now this organization was much, much, much, much lower in that. And so, what it told me, and told them was the problem wasn’t so much inefficiency in their process, the problem was in the set-up time and the process time to actually complete the work, and so that minimized limited the amount of work that they could complete in a two-week sprint, in their case.
But one of the things that will make that crystal clear is walking through that process and capturing those metrics to understand where the slow down is occurring. So, I think that’s important. Now, the beauty of that information, is it will clearly identify for you where your problem areas are, and those problem areas become prioritized stories within your backlog for the SDS. If there are technologies or there are processes that are slowing you down within that SDLC, being able to identify them early and making them a priority in your SDS backlog will provide tremendous benefit because you can focus on the things that are hurting you the most. Now, there’s some base-type delivery capabilities that have to be implemented, but focusing on those problem areas quickly will have an impact on your SDLC in a shorter time frame, from a business standpoint.
Matt: And I’m assuming adopting Agile is a huge part of it. How to do those methods work in?
Rick: I’m a big believer—and the group that’s listening this knows my beliefs with regard to Agile—I think it’s the best way to deliver software and it provides so many benefits. I think what it does for me, what I think the biggest benefit is, is it minimizes re-work time. And I’ve seen this throughout my career. In traditional waterfall projects, the biggest problem is the amount of re-work that has to be done to accommodate some mis-communicated or unidentified requirements. By executing work in smaller increments and smaller batches, you can minimize the amount of effort required to make changes that were the result of maybe a false start, or a misunderstood requirement. I think that absolutely the same thing is true in building out a software delivery system. Using Agile to manage that product backlog and to massage that backlog to constantly evaluate work that’s being added to that, to prioritize that, leveraging that information for work execution is so important.
The planning sessions that are typically part of the scrum and that sprint, being able to identify what work is going to be done in those two weeks and the ability to formulate, you know, good stories, good epics is going to be very helpful in managing work. And building that sprint backlog, executing that sprint, the daily scrums that occur with the SDs members to see where they are and where their problems are, what’s preventing them from accomplishing that work—that communication is so important. Just like it would be in any other Agile team, it’s no different. And being able to learn from your mistakes through retrospectives at the end of each sprint to ensure those things don’t happen again.
Typically, if you look at scrum from a purists standpoint, it really doesn’t mention MVP, but I think that’s a big part of that software delivery system, especially in that roll-out, initial roll-out to that target team. Because you’ve got to have the capabilities required to allow them to execute their work as quickly as possible. And it doesn’t mean having everything, but if you can define the proper MVP and there are ways of making sure that that’s done, then you can start to add additional features and capabilities, then you can roll those out incrementally on top of an SDS base that you know is working properly.
I’m just… I’m a huge believer in incremental, managing work at an incremental level, and I think Agile gives us the best ability to do that. I have seen too many cases where I have seen reductions in overall cycle time through the use of Agile but I also believe it produces higher quality systems, higher quality software, again because of the incremental nature of how work is managed.
Matt: Once you’ve planned everything out, you’ve got a good framework, you’ve got the plan down, what comes next?
Rick: You know, it’s execution. It’s the execution of that plan by that software delivery system team. And so, in that you’re going to have work to be done. At Compuware—I’ve been, for the last 20 years I’ve accumulated knowledge on what’s required to transition an organization with regard to development activity—and so we’ve got a significant backlog of work to be done.
The difficulty is that it’s going to be the starting points for just about every shop are going to be different, depending on where they are in their transformational journey and where they decide to implement technology and tooling—from our standpoint is typically where I get involved. But it’s going to be different from shop to shop, so it simply becomes a matter of executing that work, and that work for some shops, there’s going to be some what I call “sprint zero” activities and just building out the organization and structuring it, and then there’s decisions to be made around technology. All of those are work that can be managed through an Agile process and then it just becomes a process of executing. And again, within this branch again, as I’ve already said, you’re not going to be just talking about installation, configuration, but also testing of that system prior to the roll-out. Once that’s done, just like any other application system, you begin the roll-out process to that target team and again, that roll out, again I treat it just like I would any other business system—
I try to leverage technology to automate the delivery of that have that system to my users where I can and when I can.
And then, once that’s done, then there’s the education of the users, specifically, to that SDS. And again, that’s something that you don’t have to necessarily wait until your roll-out; there are things you can do prior to that to get people ready for the new technology and new tools, but they’re going to have to be educated and then you’re going to have to provide some support. One of the things that has worked for me over the years is what I call over-the-shoulder support. Walking around by SDS members who are responsible for making sure that developers are getting the maximum out of the SDS and they’re leveraging the capabilities and features to its fullest in order to meet the stated objectives of faster, higher-quality software. So, support becomes a critical issue.
And to me that’s when the real work begins. But getting started is… it can be somewhat difficult for folks. You walk through it, and it sounds kind of pretty common sense, but I’ve seen a lot of organizations labor with how to get started, where to get started. I think these are just some common-sense recommendations, suggestions that have worked for a lot of different customers for a significantly long time and I think it’s… we can get going if you start to leverage these techniques and start to leverage Agile as a way to manage the software delivery system. It becomes a continuous improvement process very quickly, and so work will continue new features, capabilities will be added. Initially, you may be using new technologies, in a manual method, I would expect very quickly. In an incremental sprint that you start to automate some of that work—and that’s where the SDS team is so vital, because they’re going to work on those new features, new capabilities and test them prior to rolling them out to the users, so that when the users get them you’ve worked through a lot of the issues associated with installation, configuration, and you can become productive as quickly as possible.
Matt: I’m sure this information will be very helpful for people who are looking at it, maybe struggling a little bit, or just to trying to find a place to get off the ground with the whole project.
Rick: I’m just going to say I’m sure there will be questions but I think as you were getting ready to say, we’ve got our live Q&A that we’ll follow this topic up with on Friday, and there, hopefully I’ll be able to address any questions or concerns that you might have.
Matt: So, again, you read my mind. If you’d like to join Rick for Office Hour with Rick Slade, this Friday at 11 AM Eastern you can visit compuware.com/goodcoding. You can download a calendar reminder for this week’s Q&A, watch previous Q&As, or listen to the other episodes in this series. So, as always, thanks Rick, for sharing your expertise and I’ll let you take us out.
Rick: Thank you, Matt, I appreciate it. We definitely are starting to spend too much time together—we’re starting to finish each other sentences, so… But I enjoy it, I appreciate it. I appreciate you guys listening. So, again, if you’ve got questions, please join us on Friday and with that we’ll close out today’s podcast. Again, thank you and good coding, everybody.