Application Lifecycle Management for the Whole Team

7 July 2016, 08:05 AM

By Test Guild

One thing I’ve found in large organizations that have moved towards Agile is confusion around how to manage the application lifecycle pieces of their development efforts — like requirements and defects. That’s why I was glad to speak with Matt Angerer from ResultsPositive on TestTalks recently about his RPALM process.

Lack of Requirement Traceability

I work in a regulated environment, and although we follow an “Agile”-like methodology, it’s been an adjustment because we no longer have a clear requirement traceability process like we had when we developed following waterfall processes.

After speaking with Matt I found that this was actually pretty common. He’s seen a number of firms who lacked requirement traceability within HP application lifecycle management. The fact that they lacked end-to-end software traceability really put them in a handicapped position when it came to understanding the changes that occur as a result of enhancement or change requests that are rolling through their pipeline.

Having that lack of traceability in effect handicapped them because they weren't really sure exactly where to hone their regression testing efforts.

Even more than that, they weren't really sure what regression test cases to update as a result of this lack of traceability. So how do you fix this?

Leaders

Training is Key

With DevOps and Agile, we’re all trying to create and release quality software quicker and more often, but I think simple things like training are sometimes overlooked. We can become so focused on velocity that we can lose sight of things that in the short term may slow us down but in the long run will make things better.

For scaling test management Matt recommends that your team have a requirements-tracing workshop with all the key stakeholders and help them fit the pieces of the puzzle together in terms of their requirements.

Reviewing all the different requirements types — ranging from business to functional to performance requirements and tying those to specific regression test cases, ensuring that they have a process in place as they use the tool — will ensure that the team can effectively perform change impact analysis.

One suggestion that Matt has for clients as they start using HP ALM (or any other test management platform), is instead of going directly to designing test cases within ALM or logging defects right away, begin at the requirements level and understand the best practices around using ALM to manage those requirements before doing anything else.

If you can start there and master the definition of your requirement's intake process using a tool like ALM, then you can move on to the next step. This is essentially the crawl, walk, run scenario we just discussed earlier.

Once you work your way down through to where you're using all the different features and functionality of the tool, you should start thinking about your metrics and reporting strategy; how best to tie everything together within the tool and effectively provide your leadership team with intelligent information in order to make key decisions.

Lead with Education

Another key thing that Matt recommends — and I know everyone will probably think it sounds very cliché — is leading with education. Focus on helping organization stakeholders – your release managers, project managers, etc. – to understand the key features of ALM such as project planning and tracking (PPT).

Then try to determine how you can best modify your PPT to create a scorecard that can be used at your stage gate processes, as well as how to define KPIs through project customization within ALM.

Those are some key things that you should educate your stakeholders on.

Smart-Idea-150x150

Be an Internal Champion

Another practice that will help make your whole team part of your ALM process is to have an internal QA champion; not someone who is just an order taker who is managing the testing process, but someone that's truly going to be an inspiration throughout the organization and build buzz and excitement around using a new product.

If you look at large scale ERP implementations like SAP or Oracle, you’ll see that they have a devoted change management team.

Now, I'm not saying that you need a devoted change management team when you decide to move in the direction of HP ALM, but you do need to identify some charismatic and driven people internally to help champion it as well as explain the business value.

Let’s face it: we're constantly being bombarded with different marketing messages, so you need someone that understands the value of having everything under one common platform as well as having the pieces tied together within a tool like ALM.

Follow Matt’s advice, and I’m sure you can improve your ALM process (and get your whole team to buy in on it).

Discover More ALM Awesomeness

Here is the full transcript of my Talk with Matt Angerer:

Joe:	Hey Matt. Welcome to TestTalks.
Matt:	Hey Joe. Thanks for inviting me today. I appreciate it.
Joe:	Awesome. It's great to have you on the show. Before we get into it, can you just tell us a little bit more about yourself?
Matt:	Sure. My name is Matt Angerer and I'm a Senior Solution Architect for ResultsPositive. I've been with the firm for about a year and a half now. Prior to joining ResultsPositive, I was in the space of independent SAP consulting. I've been involved in a number of different commercial and public sector implementations of SAP, predominately in quality assurance and project management roles.
	With ResultsPositive, my focus is on the application delivery management suite of products. As you know, including Quality Center, ALM, UFT, Performance Center, Load Runner and the additional SAS products that have been introduced in the market place recently.
Joe:	Awesome. Today, I want to focus on … One of the main things I want to focus on is your RP ALM assessment methodology. I guess at a high level, what is RP ALM?
Matt:	Sure. RP ALM was introduced primarily due to customer demand. Several years ago, ResultsPositive actually pioneered in the assessment methodology for their PPM practice. From there, RP ALM was born.
	Essentially, we took a lot of the same tenants of their assessment methodology and more or less tailored it strategically to helping clients in the sens of an independent assessment to provide them with tactical and strategic key improvement recommendations to go from their current state to a desired end state.
	What we've done is actually created 21 different topical areas across three main categories that we analyze to help clients understand how to best position their people, their processes and their technology to support improved velocity or improved quality. It's whatever the objective of an end client is, is how we tailor this assessment methodology for them.
Joe:	Awesome. Can you just give us an example? Say, a company contacts you and they're having issues. What companies or what issues do you think would most benefit from this RP ALM assessment?
Matt:	Sure. We've had companies that have gotten in touch with us. Several companies, one that comes to mind recently is an organization who lacked requirements traceability within HP application lifecycle management. The fact that they lacked end to end traceability really put them in a handicapped position when it came to understanding specifically change that is occurring as a result of enhancement requests or change requests that are rolling through their pipeline.
	With that, the lack of traceability actually, in effect, handicap them because they weren't really sure where specifically to hone their regression testing efforts. Even more than that, they weren't really sure what regression test cases to update as a result of this lack of traceability.
	One of the things that we would do is the recommendation would be have us do a quick RP ALM assessment. Which also includes a requirements tracing workshop or one of our senior engineers, or solution architects would facilitate the workshop with all the key stakeholders and help them fit the pieces of the puzzle together, in terms of the requirements. All the different requirements types ranging from business, to functional, to performance requirements and tying those to the specific regression test cases and ensuring that they had a process in place as they use the tool. A process in place as they are using the tool to ensure that they could effectively perform change impact analysis.
Joe:	Awesome. I know some companies I've worked for struggle with ALM specifically with HPs quality center ALM. One of the things they struggle with is sometimes they have a process around it that's really heavy and no one really understands it. Do you have any suggestions on how someone can help create a process for their ALM quality center solutions, but that it's easy to follow. Does that make sense?
Matt:	Yes, it does. At ResultsPositive, what we try to advice clients on is to crawl, walk, run. That's really the premise. I know that's oversimplifying it here in terms of how we do it. The first and foremost is within the ALM, you have to understand that there needs to be an effective awareness program in place across a quality assurance organization that spans beyond the QA team, really. There needs to be an internal champion that helps clients and the stakeholders understand how the product works.
	As you know, ALM is split across or broken up in the different modules. One of the modules that I'm speaking more heavily about today is the requirements management module. A lot of business analysts and project managers, program managers might peek into the requirements management module to take a look at what's being managed for a given release or a given cycle for that matter.
	One suggestion that we have for clients is this; as you start using ALM, it's we always suggest that instead of going directly to designing test cases within ALM or, directly, they're just logging defects right away. Start at your requirements level and understand best practices around using ALM to manage your requirements.
	If you can start there and you can master the definition of your requirement's intake process with using a tool like ALM, then move on to the next step and then move on to the next step.
	Essentially, what this is the crawl, walk, run scenario that I just discussed before. Once you work your way down through where you're using all the different features and functionality of the tool, then let's think about you metrics and reporting strategy of how all of that can … You can tie everything together within the tool and effectively provide your leadership team with intelligent information and make key decisions.
Joe:	Awesome. I guess one of the key areas that you focus on with your RP ALM is people. This sounds like this is actually one of the biggest things I struggle with. Any suggestions how to get everyone on board that this is not just a tool for requirements, but it's a tool that helps everyone. It's not just a tool for your testers. This should be a resource that everyone can go to, I would think, and get something out of it at all different levels of where they are within the software development life cycle.
Matt:	That's a very good question. I worked for a multinational manufacturing company in the past and one of the things was getting everybody on board. The people aspect, the soft skills required to convince stakeholders that ALM is not just “a bug tracking tool” or it's not just a tool to execute manual test cases from. It's a lot more than that.
	I think one of the key things, and I know everyone, this sounds very cliché, but it's leading with education. What I mean by that is helping organization stakeholders as an example. Your release managers, or your project managers, understanding key features of ALM such as the performance, the PPT functionality, project, planning and tracking.
	Understanding how that they can modify PPT to create a scorecard that could be used at their stage gate processes and how they can define KPIs through project customization within ALM. Those are key things that you want to educate your stakeholders on
	Above and beyond that, it's really important … This is my opinion. You have to have an internal champion, an internal QA champion. Not somebody who is just going … Not somebody that's an order taker that is managing the testing process, but somebody that's truly going to inspire throughout the organization and build buzz and excitement around using a new product.
	You look at large scale ERP implementations, like such as SAP or Oracle, they have a devoted change management team. Now, I'm not saying that you need a devoted change management team when you decide to move in a direction of HP ALM, but you do need to identify some charismatic and driven people internally to help champion it and explain the business value and more … And less of a way that's just … We're always getting bombarded with different marketing messages [inaudible 00:09:02]. You need someone that understands the value of having everything under one common platform and the value of having the pieces tied together within a tool like ALM.
Joe:	Absolutely. Once again, I definitely agree. A lot of times, people are like, “Yeah. This is overkill for me. Why do I need to do this?” If you have someone that's like a champion, someone that actually can coach the teams and say, “Hey, this is why … Here's some output. Here's how you benefit from it. Here's what's in it for you.” I think that that is a big win. I think that's a great point.
Matt:	It is too. To your point before, it's … Like you said. It's putting yourself in their shoes and practicing empathy. What is in it for them to begin using this tool?
	Really, a lot of that boils down to understanding the features and functionality of the tool and having a strong solution architect on your team, or perhaps partnering with somebody like a firm like ResultsPositive who has team members who understand the tool inside and out. Also, having somebody that understands the voice of the stakeholders within an organization.
	That's why I think it's so important if you're a QA manager or a test director listening to this podcast. It's so important to think of somebody in your organization who really has the pulse, or the voice of your stakeholders. Who understands what drives everybody, because everybody's fires lit someway different across the boardroom table.
	It's somebody within the organization who's been there a little bit longer than others who understands what motivates different departments is somebody that you need in that champion position.
Joe:	Absolutely. Great point. I guess another thing I see a lot of is someone uses quality center or ELM and they just use one piece of it, just the defect section, but they might have all the other modules. How would you encourage people to use other aspects of it? Do you think that's more of an education point, where maybe they just were told, “Here's the tool you're going to use.” But weren't educated, and that's why it's so important to have some evangelist out there really promoting the product and the tools and process?
Matt:	I think it's a combination of things. It's not just a … It's a combination of, maybe, lack of training. It also is reflective of the maturity level across the different … If you clump them as categories across a systems development lifecycle. Of course, this would be a whole another conversation if we talk about waterfall versus agile and other tools that HPE has, but we're speaking about ALM here.
	If we think about the tool aspect of it. To your question, why are certain people or certain organizations so focused on maybe just using the defect management module?
	Let's address it really quick. From an evolutionary perspective, HP ALM was spawned from a Mercury test director. As we know, the primary flagship functionality was really the defects module, and the workflow, and the script that are there that was built into it.
	It got it start, really, around that feature and functionality with some other things built in there too of course. I'm not just saying that that was the only thing. The product evolves significantly over the course of time.
	What we're seeing with certain clients is even if we do provide a rapid start and give their team thorough education of the nuts and bolts of every module within ALM, if their processes are not mature enough to keep up with the technology, it doesn't matter anyhow. They're just going to use what they need to use, and that's the extent of it.
	That's why it's important to look at your organization from an independent perspective, and it's hard to do that when you're in the weeds. It's hard to do that when you're part of the delivery team and you're stuck in a day to day battle, so to speak. You're in the trenches.
	That's why organizations come to firms like ResultsPositive and say, “Hey, tell me about your RP ALM approach. Let's bring in an independent fresh set of eyes to help us understand how we can get from point A to B across those different continuum.”
	If you're from a people perspective or process perspective and technology, how do we improve our process to keep up with the technology. How do we improve our technology to keep up with our processes? Sometimes it's like that. Also, their training components too of making sure you have those power users identified, the people. Your folks that are actually building the requirements as an example, designing the requirements for a system under test understand that they don't have to store their functional designs that are in Word documents and Microsoft SharePoint.
	They can use the rich text editor or rich text feature of a requirement type within ALM and then effectively trace that upstream to a business requirement, and then you can speak to them about the positive implications of doing that. They're not going to see those positive implications right away, but by showing them and painting the picture of, “Hey, this is how it's going to help you down the road when you're approaching a regression testing cycle for a major service pack.” Now, you have the ability to perform change impact analysis where you need to perform it. It's going to save you a lot of time, effort and headaches essentially.
Joe:	Great point. I think a lot of times people forget about the big picture because they're so caught in the weeds right up front. They just need to delivery something, say, within a two week sprint. Really having that big picture, “What are we trying to accomplish first before actually implementing it a low level?” probably would be a big tip or a big help.
Matt:	Absolutely. It's human nature, really. We can't fault anybody for doing that. If you're in the middle of a firefight, as an example, you're thinking of how to survive. You're not really thinking about, strategically, what kind of political fallout is this firefight going to have on the overall objective of the mission. You're thinking about how to survive.
	We understand that, but the fact to the matter is with RP ALM, we have a slide deck out there on SlideShare, as well about it. It's really an umbrella mentality. Other organizations are attempting to do what we're doing, but, of course I'm bias, because we created this proprietary methodology. It's really an umbrella methodology that helps organizations see the forest through trees. That's … Really, it's hard to do unless you get an independent outside objective opinion.
Joe:	People are probably, maybe [inaudible 00:15:34], “Oh, those guys are consulting.” Of course, you're going to see that. I swear to God, I work for a large company and I will say something over and over again, no one will pay attention to me. They will pay a consultant outside the company to come and say the same exact thing. [Awesome 00:15:49]. It's brilliant. That's what we're going to do. I don't know. Maybe it's like you said, it's human nature, but it drives me crazy.
Matt:	You're speaking to the choir. I've seen that so many different times and I've even heard the frustrations internally from folks where I'll deliver the same message as somebody that internally delivered it, and they'll pull me aside and say, “You know what? I've been telling them this for five years and you came in here and said the same thing as me and all of a sudden you have the golden nugget, or you came with a grail of information that we can take forward.” I just laugh. It's psychology and it's human nature that they're thinking, “If we're paying for this advice from somebody, it must be a really valuable advice.”
	Sometimes … I say to other people and anybody listening to this podcast. Listen to your internal stakeholders. Listen to the people that work for you. If you can figure out a way to objectively do it, even if you take somebody from a different department and maybe you want to include them in the assessment as supposed to bringing in an outside firm. That might be an alternative to do something like that. Really listen to your internal folks because they are the most important and the bloodline of your organization. If you ignore them long enough, they're no longer going to be with your organization.
Joe:	All right, Matt. I guess I like to go a little bit more over the RP ALM assessment methodology just at a high level. I believe it's broken up into four … You have four categories, I believe, prepare, discover, assess and deliver. Can we just go over each one really quick to just say what this process is like? What the methodology is like?
	What does prepare mean? What do you do at the prepare stage when someone's trying to implement your RPLM assessment methodology?
Matt:	Sure. There's a number of different factors that we look at. The preparation phase. Typically, our RP ALM assessments last between two to three weeks. What we do first and foremost is we sit down with key stakeholders and confirm the goals and objectives of the assessment, and we define critical success factors. What it means to come out of this assessment as successful.
	Then during the preparation phase, we collect and review [ases 00:18:11] documentation, and we can confirm the participant's role and responsibilities, what everybody on the team does. How sometimes you have a release manager and a test manager doing the same thing, or you have one guy over here, one gal over there who's serving as both a release and test manager. We want to understand how the organization is set up.
	We do some discussions and we clarify expectations. What we do is we review our 21 factors, our 21 key factors that tie in to this RP ALM assessment. We show the clients specifically what we're going to be looking at across the board.
	We want to confirm buy-in as well during this preparation phase. Buy-in that we're going to have the necessary stakeholders ready and willing to participate, because that's extremely important. You could send somebody to counseling or send them to speak somebody or coach about something as an example, but if they're not ready and willing to receive the message, it's not going to matter.
	We want to confirm buy-in and we want to get people excited and engaged in this process, because it's truly transformational and that's how we look at our RP ALM assessment methodology. It's a transformation mission to get your from point A to B.
	After we finish up the preparation phase, we actually go ahead and schedule the workshops an the interviews, and then we dovetail into our discover phase. Discover is about conducting those one on one interviews or groups interviews with your key stakeholders. Doing a deep dive review of your project artifacts.
	We have a team of solution architects that are HP ExpertOne certified with an average of 15 years of industry experience deep dive into all your documentation and take a good hard look at things. Then we conduct the workshops. We do a visionary end state workshop with your stakeholders. We do the requirements tracing workshop that I mentioned before.
	We conduct best practice sessions with your team across the tools, people and process. Then after that we review your current processes, your governance model and reporting. When that's done, we move into the assess phase.
	The assess phase is really about bringing it all together and saying, “Okay. We've looked at everything. We have all these information collection. We've taken away key points from it. Now, let's take this and really put it together into an assessment that identifies your most critical opportunities and solution recommendations to improve upon either velocity of delivering software, or improve upon quality.”
	How do we trap defects further upstream? Are there tools that we can use further upstream that trap defects? Like LeanFT as an example from a development perspective. Are we doing an effective job further upstream of preventing defects from slipping through the testing layers and not getting caught in our regression testing cycle and our business is identifying them? How much money are we losing as a result? Things like that.
	Finally, we deliver. What we mean by deliver is we have a presentation with key executive stakeholders. We bow tie the assessment into a clear picture of where a company is at so that your CIO can take a look at that assessment and understand, “This is from an objective party. This is from ResultsPositive and it clearly shows us a roadmap of how to get from point A to point B.”
Joe:	Awesome. I'll have a link to the slide within the show notes. What I really like about one of the slides within your slide deck here about RP ALM, the engagement approach, is that somebody can reverse engineer it and use it for something else, because you do lay it out really nicely at a high level what each stage is. I think it's really helpful at that point also.
	On top of that, it doesn't seem like it's specific to HP products. Can this be applied? Do you work with other things other than HP products?
Matt:	We do. We do. Predominantly, we've gotten our start working as a platinum partner to HP. We've had a lot of success in that area and we're true to our roots. We have a lot of customers that reach out to us because of HP products. That's one.
	However, we do use this assessment of methodology for other organizations that may not be using ALM. Perhaps are using Zephyr, or perhaps are using QA Symphony, or other products out there in the market place and they're looking for true experts to come in who have been there, done that and provide that objective viewpoint as you mentioned before.
	Sometimes people are so frustrated because they're speaking the message internally and they know they're spot on, but you bring someone else in and they provide that objective opinion about things and they can clearly see the forest through the trees from the outside looking in. All of a sudden, that is the message that the decision makers decide to move ahead with.
	To your point, it's not all about HPE products for this assessment methodology. It's vendor-agnostic, and we're starting to provide clients with coaching. Also, this assessment serve as methodology outside of the HPE realm of Quality Center and ALM.
Joe:	Awesome. Also, what I think [inaudible 00:23:38] good is having an outside company or a consultant come in is validation. You have a plan and you think your plan is right, but you're so caught up in the politics of the company. Just having that third person, third part come in and look at and say, “Yeah, this is right.” or “You know what? This is wrong, because you didn't think of this other thing. I've talked to these other parties involved that you didn't, and here's is why this isn't going to work.” It saves you a lot of time.
	In other ways, even if you have a plan that you think is going to work, just getting that third part input I think helps also.
Matt:	Absolutely. Absolutely. I couldn't agree more. It's the same thing internally. I'm a huge a proponent of feedback loops. I'm also a certified scrum master, and we help a lot of clients with the use of agile manager and also next gen ALM octane.
	As a key component of going agile is to get feedback quickly and often from your end users. The same thing applies with this type of approach.
Joe:	Awesome. For companies that have … Or are starting to make the transformation from waterfall to agile, I think a lot of them have the notion that, “No. We can't use a vendor product because we're agile. Right? We're going to use some open source solution that's available.”
	When would someone use ALM or Quality Center as supposed to, say, agile manager of the newest version? I believe you called it ALM Octane, or another tool. At what point or when … When do you think these tools make sense and what process do you think they make most sense, and especially if someone's going to agile from waterfall?
Matt:	That's a great question Joe. In fact, last week I was actually at HP Discover in Las Vegas and there were several breakout sessions that I attended with regards to both agile transformation from a people perspective and also the tools itself, you speak about Octane or next gen ALM.
	Let's address one thing here, and that's around agile transformation. What we see with clients and how they're moving ahead. You made a point that a lot of pure agilists, they're more interested in opensource software. They don't think going with a particular vendor. Maybe that's not … That's not sexy or they think, “It's not the way to go? Why would I do that when all these products are free and I'm a pure agilist and I believe in collaboration and people over documentation and process?” We understand that.
	However, what I do want to say is this. We have helped many, many, many clients realize the transition over into more of an agile or even a hybrid agile. If you think about it, a lot of organizations, they're setting their ways and they've been doing waterfall for many, many of years. They have what … I'm not sure if you've heard of this, you probably have. It's from Gartner. It's the Bimodal IT. You have your core IT and you have your Fluid IT. There's two different modes.
	Your core IT is really centered upon your steady eddy ERP systems. SAP, Oracle, your HR system, maybe your demand planning systems. Things that are like structured. There's a lot of rigor around it. There's a lot of process. It's usually PMO-heavy.
	Then you have Fluid IT, and Fluid IT is really those new and innovative products that your team is working diligently on pushing out. They're typically web-based applications or mobile applications. That's where you're learning more towards an agile delivery methodology where as the core IT is predominantly waterfall.
	To answer your question now that I've got all that stuff out of the way, it's twofold, really, if you think about it. Because there's a product in the market and I'm sure others have heard about it, known as Octane. It's next gen ALM. It's a product from Hewlett Packard Enterprise. Basically, it's an evolutionary step from ALM which is centric in my mind. This is my opinion. It's around core IT if you think of Bimodal IT.
	Next gen ALM focuses a little bit more on Fluid IT, but it can still be used to carry out your waterfall projects as well. Here's the thing. We know a lot of organizations are opensource products. You think about Jenkins as an example for continuous integration.
	What's great about Octane is they've built it to integrate nicely with Jenkins, so you can leverage the current tools that your developers are using today and that your development lead has embraced. Then you can take advantage of the experience and the know-how of HPE and leverage another tool, Octane, which by the way you can sign up for your free trial [inaudible 00:28:33] at hpe.com. You can integrate that with ALM.
	If you have an existing investment in Quality Center or ALM today and your team is heavily entrenched in that and you're saying, “Well, I don't want to mess with this. I have an agile team, but I have waterfall processes over here.” I've seen it before. I saw it a firm called Nationwide Financial. I did some consulting there.
	A lot of their teams are based around waterfall, but then they had other teams around the [peripheral 00:29:01] that were leaning towards agile or practicing agile and they weren't using tools for it. Literally, they were co-located with sticky notes on the board. That's how they moved things along.
	Whereas with tools like Octane and agile manager, you get the virtual planning board. You get all that information set up, because we as practitioners realize that it's not pragmatic to co-locate everybody from around the world into one room. You have to learn how to deliver agile outside of a room. That's where tools like Octane and a next gen ALM come into play.
Joe:	I love that quote, but it's [inaudible 00:29:41] if I repeat it. I'll probably cut this at, “Oh my gosh! That's so true about … You have to scale outside of a room agile. Some companies, they think agile is, “We'll get everyone in one room like sheep and there we go, we're agile. That's it.”
	This sounds awesome, Octane. Besides that at HP Discover, if someone is trying to plan the next year or so, where do you think they should focus their efforts after seeing the roadmap that HP laid out?
Matt:	Sure. There's two different I think. Number one is you've heard that song by Beyonce Knowles about To The Left, To The Left. I think it's important that organizations focus on shifting left. At the same time, I think there's also … I'll speak about this in a second. There's also some value in terms of shifting right.
	Let me first talk about shifting left. What do we mean by shifting left? If you think of your delivery life cycle and what you're doing today, all the way from the requirements intake process to the release of a build in your production environment. A lot of the times you see companies putting in enormous amount of pressure on their test automation team or their testing center of excellence to trap defects.
	Developers washing their hands of any responsibility as it comes to the quality of their code. This mindset really needs to change. This is a key takeaway from HPE Discover, and it's a message that many of the thought leaders are communicating at the highest levels. Is within any organization, quality is everybody's responsibility.
	I think I certainly did not dub that slogan. I think that came from Deming, if you want to think of quality management from years ago. Quality is truly everybody's responsibility, starting from the development side.
	Not to plug another tool from HP, but we're talking primarily about HP tools, but LeanFT being used by your development team further upstream to the left will help prevent future ramifications down the line to the right. If you think about, if you're moving from left to right. To the right is production, and you're moving all the way to production. When you produce a build and that goes into production and your business users or your customers or you're using it and there's a critical defect that has slipped through, that has passed through these different layers, there's going to be, of course, a very large financial impact to your company. Depending on the type of defect that was slipped through.
	When you embrace concept of quality is everybody's responsibility, let's put more onus on the development team to produce higher quality code, and let's have them use tools like LeanFT which integrate with their IDEs to do some automated testing over what they're producing before they “throw it over the fence” to the quality assurance team and say, “Hey, how about it?”
	I think we can get cleaner and cleaner code as you move through the different environments and you move forward. Which ultimately as we know, reduces the total cost of ownership for a piece of software. It really does keep everybody happy, because morale is a lot higher, and you don't have as many last minute issues when you're going through these large software projects. You're not running [inaudible 00:33:08] there's so many problems and so many headaches along the way, because people are more diligent further to the left.
	If you think about further to the right, there were some discussions around that. At HPE discover, what it means to shift to the right as well. It's a new term and a few of the product managers brought it up at HP as well that not only is there emphasis on shifting to the left, but there's also emphasis on tools that protect the right as well.
	What I mean by that is this, if you think of DevOps, okay? You think of DevOps in terms of how do we move faster. It's all about speed, fast, fast, fast, fast, but how do we maintain a consistent level of quality or improved quality while moving faster.
	As you know, that's a really difficult feat to pull off. One of the things about thinking about the right is, “Okay. What about our incident management tools? What about using service anywhere or service now for that matter for business and end users to log incidents? How do we calculate KPIs based on how many incidents were released, say, within 30 days after a build hit production versus all the testing that we did during that regression testing cycle?”
	If you think of the DevOps picture, being able to tie these pieces together and accurately run metrics on this, gives you the true picture from an end to end perspective of tying your development team to your operations.
	One other key component I just want to mention quickly that I pulled out of Discover is a new product called ChatOps. If you think of collaboration at its core, that in my mind sits right next to ChatOps. ChatOps allows your team to actually communicate across functional barriers in like a Twitter style communication and basically use reference bots that are built out to actually carry out functions within your HP suite of products.
	It's pretty cool, and I think honestly it's going to take off. It's going to take a little while to educate folks on the use of this new product, but I think it's going to be a prevalent force.
Joe:	Awesome. Yeah, that sounds awesome. Do you know if it works for other things other than HP products?
Matt:	It does.
Joe:	Really?
Matt:	It does.
Joe:	Nice. I definitely agree with you. Shift right is … First time I heard, it was early last year by Jeff Sussna who wrote the book Designing Delivery: Rethinking IT in the Digital Service Economy. I totally agree with you. A lot of people have heard of shift left, but I'm seeing more and more companies shift right. That once you deliver the software, it's not over. You're still testing, being proactive once it's in production, and which is pretty mind-blowing.
	It seems like HP … Once again, a lot of people sneaker at vendors and consultants and logic companies, but these companies speak with a lot of other companies, a lot of other clients, and they really have a pulse on what's going on in the industry better than someone that maybe working on a small company. I think it's a great point about shift right. I guess my main point there.
Matt:	Agreed. The statement has been made before. If you look back 10 or 15 years ago and you see an IT professional or a consultant who went from project to project to project like I have, the idea would be, “Why don't you stay in one place at one company for a long period of time?” The response today, and there's articles I've read about it, is you gain so much more perspective by seeing how different companies operate. The product managers at HP speak to so many of their solution architects in the field to truly understand how these different organizations are working.
	What we can do is … There isn't a one size fits all. Even if something works for an organization over here that might happen to be in the same industry as another one, it doesn't mean that they are going to use that exact methodology or they're going to use that exact way of delivering upon things.
	However, thinking about things from more of a bird's eye perspective like we're speaking about right now, and talking about doing an RP ALM assessment and shifting left versus shifting right. Bringing these topics to the forefront of stakeholder's minds can help them really analyze functions.
	Ultimately, if you think about the end goal of what we're trying to do here, we're trying to improve the quality of the software and deliver it faster, but provide value, true value with clear return on investment to our end users and our business.
	At the end of the day, we're servants to our business. We want the business to succeed. To do that, we need to do our jobs and do it very well and continue to evolve with the times. The tools are very important part of that function. To our discussion earlier, the people and process are equally important and they need to harmoniously work together in order to achieve the best results.
	One other thing I did want to mention though is around the best practices and maturity models that are part of the RP ALM assessment methodology. There are a lot of whitepapers and a lot of best practices whitepapers that have been published by HP and ResultsPositive alike. For the folks that like to read, you can go out there and read them.
	For the folks that like to listen. Obviously, your Test Talks is paramount. It's a perfect forum to hear what other organizations are doing and what truly best practices are.
Joe:	Okay, Matt. Before we go, is there one piece of actionable advice you can give someone to improve their ALM efforts? Let us know the best way to find or contact you.
Matt:	Sure. The best piece of actionable advice that I can provide to anybody listening to this podcast is to, first and foremost, look at your master test strategy for your QA organization. Before you even start looking at tools, before you start looking at, “Do you have the right people?” Before you really start looking at the process. Because when you speak about process, there's … I think a lot of Visio diagrams and I think a lot of other things are involved in the process.
	My suggestion really is to ensure that your master test strategy is sound. If you need help developing a master test strategy, ResultsPositive has test managers who have done it. We have worked in various industries that can help you develop a sound foundation on that MTS, on that master test strategy so to speak, to clearly outline the different testing layers that you might want to run your application through and to help your team understand how to build a process from that master test strategy, or how to adopt the tool from that master test strategy. It might not necessarily need to be ALM, or Octane, or you might want to crawl before you walk or before you run, as I mentioned before.
	As far as reaching ResultsPositive, we have a pretty significant web presence out there on our YouTube channel. You can search YouTube fore ResultsPositive. You will see a lot of our videos out there. You can also point your browser to our website at www.resultspositive.com and click on the contact section across the top and somebody would be happy to get in touch with you.
	We do also offer … Joe, just to mention. We also offer two hour free workshops that we have dubbed Innovation Workshops for any organization that is interested.
	Just another shameless plug. We actually have a solution architect paired up with an account manager, and we cover off on all the latest and greatest enhancements across the DevOps space in terms of newer tools on the market and how your organization can adopt these tools to improve upon existing processes.
	Let us know, if you're interested about that, we'd be happy to schedule. We're scheduling out six months ahead right now. There's a pretty high interested in this innovation workshop that we have. We look forward to hearing from you.