3 Common Themes about Quality Strategy with HP Agile Manager
by: Matt Angerer
Last week, I had the opportunity to host a Webinar with HP entitled, “Agile Quality Strategy with HP Agile Manager.” Aired by Vivit and led by Matthew Brayer-Berger of HP, the Webinar was an eye opening experience for the nearly 150 participants on the call – especially during the Q&A session at the end that I facilitated with the audience. Having worked across 7 enterprise sectors in my professional career, I’ve seen many differences in how organizations operate and view software quality. There is no doubt that software delivery continues to evolve at an unprecedented rate. My belief is that Agile delivery is the future, if it’s not already for some organizations.
Personally, I couldn’t be more excited about Agile software delivery. As a founding member of an award-winning software platform called VerticalRent, I have witnessed the power of decentralized Agile teams working in lockstep with one another. Co-location isn’t going to make or break your project. It’s how your people come together. You must hire and retain top-notch people who believe in the “team concept” of software delivery. There is no room for individualists or people beating to the tune of their own drum- each teammate must be on the same wavelength as the other.
HP Agile Manager is the technology that serves the people and the process of Scrum. I encourage you to watch the Webinar yourself here and provide your thoughts. The ResultsPositive team has worked with thousands of organizations since 2004 in our quest to make enterprises more efficient with business technology. If you’re interested in seeing how Agile Manager integrates with other best-in-class HP enterprise tools like Quality Center, Application Lifecycle Management (ALM), or PPM — get in touch with us today. We’d be happy to set up a demo call with your team and talk about the out-of-the-box connectors available.
During this informative webinar, we covered the following basic themes:
1) The Road to Agile is Paved with Good Intentions
We’ve all seen it before — an organization hires a new CIO that unveils a grandiose vision for the IT organization. The vision of “Agile Utopia” is paved with good intentions, clearly documented outcomes, and a detailed roadmap. Perhaps this newly appointed CIO was a former Start Up Executive out of the Valley with vast experience in agile development methodologies. They may have led successful software implementations as both a Product Owner and Scrum Master of industry disrupting software products used by millions of end users. He’s young, his presentation skills are rock solid and his delivery at the latest executive staff meeting resonates with the entire executive board. He’s on fire and full of energy. They believe in his vision, they believe in his experience, and they are certain that his vision for Agile will be a success. The “new promise” is exciting and nothing, in my opinion, of great significance is accomplished with negativity. You must be excited. But before jumping up and down with enthusiasm, we encourage you to take a step back and evaluate a few things.
In last week’s Webinar, Mr. Brayer-Berger did an excellent job of identifying where the market is heading and how HP Agile Manager can help organizations of all shapes and sizes realize their “Agile Utopia.” However, we encourage you to be mindful of your existing limitations as an organization and document them thoroughly. Business technology like Agile Manager certainly helps organizations make sense of the chaos, but you should get your ducks in a row internally before unveiling it to the company (or scaling it for that matter).
For instance, does your release management process need fine-tuning before even thinking about shifting gears and heading towards a truly DevOps environment? Or, have you given thought to the individuals in your organization with the “right personality” to step into the Scrum Master “servant leader” position of a Scrum/Agile team? Let’s face it, this role takes a high-energy and disciplined individual. It could make or break the team mentality and ultimately the quality of your next software release. Choose wisely.
2) Co-Location Isn’t Mandatory for Agile Quality Strategy
I once consulted at a financial organization where the employees felt that if the team wasn’t co-located for the duration of the project, it was doomed for failure. Well, of course if you go into a project thinking that you’re going to fail! But, let me tell you – co-location isn’t absolutely necessary when it comes to Agile Quality Strategy. People are just sometimes downright wrong. Remember when “they” were saying that “Test is Dead” a few years back? They were wrong.
Quality Assurance and Testing is evolving — just like coding practices and languages evolve over time. If you look at the style of software from a UI perspective, it evolves over time based on human inputs and factors. For instance, look at SAP ECC in terms of UI compared to a new cloud-based CRM called Nutshell.com. Both business technology products solve specific problems for an organization, but the look and feel are completely different from the end user’s perspective. But, notice how SAP’s UI is slowly evolving and embracing more modern design practices. Liken this phenomena to the evolution of Agile Quality Strategy. About 10 years ago, QA & Testing was the first part of the project to get cut if budget issues were on the horizon. Not anymore!
QA is back and it’s back stronger than ever. Even more is that your QA engineers don’t necessarily need to be co-located with the Agile Team. I’ve managed offshore teams in India that handled 100% of our regression testing execution. Fortunately, Agile Manager and ALM integrate seamlessly. What this means is that an offshore team in Channai, India (as an example) can be notified of what user stories are ready for regression testing. HP built this synchronizer they call “NexGen” to easily connect both tools together and feed the “Direct Cover Status” of the requirement back over to the “User Story” in Agile Manager. Effectively, this enables the Scrum Master and the Agile Team visibility into the regression testing efforts during any given sprint/cycle.
Hey, the proof is in the pudding and Agile Quality Strategy with HP Agile Manager provides empirical data from the World Quality Report proving that organizations are concerned more than ever about the quality of their software- on-premise, cloud, and mobile! These proof points, well-documented in the World Quality Report, should give you confidence as a QA Leader or Practitioner that you’re respected, needed, and required in this day and age. There is nothing more satisfying that helping a team deliver working software!
3) Traceability is Critical for Change Impact and Regression Analysis
Ahhhh, my favorite topic of all time — traceability and change impact analysis! They seem to go hand-in-hand. Picture this scenario. Your Product Owner comes to your Scrum Team with this User Story that involves structural code change that could have a ripple effect on your application. You know what I’m talking about, right? The type of technical debt that you’re afraid to touch, but the business wants to see the change and now you’re on the spot to make it happen. You talk it over amongst your team and decide to commit to this User Story for an upcoming Sprint. It’s one of those user stories though that may require a significant amount of regression testing.
Your QA team is sitting in a different time zone and never had the chance to automate the regression test cases. The sprint is in only 2 weeks and the development effort was finished in about 6 business days. You change the status of the user story to “In Testing” and your QA team is notified that it’s time to get busy with the regression testing.
Now, here’s where the ‘magic’ happens when it comes to change impact analysis and regression testing. An effective QA team understands the power of traceability and change impact analysis when it comes to risk-based testing. Any smart Scrum Master would have already pinged his QA Lead with a forewarning about the complexity of the changes occurring for this user story. So, the QA Lead should already be on high alert before the regression testing even starts.
Meanwhile, that QA Lead should have the User Story within the Requirements Management module of ALM traced to and from different requirements. They should understand the ripple effect through traceability. This is precisely where the QA team decides “what to test” with limited time and resources. If (and this is always a big if) the correct test cases are traced back up to the user stories (within ALM), then the QA Lead should have a pretty good idea of what needs to be regressed over. In other words, the QA Lead should be able to quickly discern what “ripple effect” the structural changes introduced in this latest user story may have within the application as a whole.
From there, the scope of the regression testing cycle can be set and executed. The “Direct Cover Status” on the associated User Story will update based on the results of the testing and pass back over to the associated User Story in Agile Manager!
Subscribe for the latest RP Blog Updates:
