You are here:
Once upon a time, in a far-away land, there was a QA analyst who wanted to please both her manager and her agile team. Pleasing both seemed mutually exclusive at times. This QA analyst consulted at a client organization that thought it had implemented agile, but the result was more Scrummerfall than true agile. Often, the requests received from the manager seemed in direct conflict with the QA analyst’s commitments to her agile team. The QA analyst felt the requests not only slowed her down, but also didn’t provide much value. Yet, the QA analyst believed she could please both her manager and effectively support her agile team. She was a true consultant after all, and even though the challenges seemed insurmountable at times, she worked hard to overcome them.
Unfortunately, this scenario is not something limited to fairy-tale land. It happens more often than you’d think, or most agile practitioners would like. Maybe you’ve even found yourself in a similar situation, wondering what you should do. Unlike a fairy-tale, I can’t guarantee a happy ending, but here are some ways to navigate common caught-in-the-middle scenarios based on real-world experiences:
You have just enough time to write test cases and execute them. You haven’t accounted for the time needed to write a test plan using your organization’s robust template. Doesn’t your manager know the test plan template your organization still clings to isn’t agile?
Solution: QA has historically relied on heavy documentation at the beginning of a project. In a waterfall world, while development is writing their tech design, QA is used to writing its test plan. In this case our conscientious consultant approached her manager, armed with agile knowledge to educate him… privately. Maybe your old-school manager simply doesn’t understand the basics and nuances of agile. Chances may be good that your manager may want to be educated, as long as you do it in private and diplomatically. At the very least, you may be able to negotiate a slimmed down template or even a test plan at the Release level that could be used as guidance for the testing within each sprint. Either of these approaches would be more valuable to your agile team.
Today is the last day of the current sprint, and you just came out of the sprint planning meeting for next sprint. You hardly have enough time to finish the testing for the current sprint, do the estimates for the next sprint’s stories, and let’s not forget, we are only working in 2 week increments.
Solution: Again, this is going to require some diplomacy and educating of your manager. She may not understand that your team has a two-week sprint schedule, given she operates outside the team, and at the beginning of that sprint is when you determine the stories the team will work on and estimate those stories. Talk to the scrum master to learn if your manager can be invited to the next release level planning session. Once she is able to participate in the process firsthand, she is more likely to understand and embrace it.
You start out every morning enlightening your agile team on what you did the day before, what you will do today, and what gnarly impediments stand in your way. No one whom you are working with on a day-to-day basis wants to know how many tests you wrote altogether; they only want to know what is done. Pulling data from ALM and Jira, and color coding each status takes a lot of time, and doesn’t appear to add much value.
Solution: Once again, this is going to require diplomacy and educating of your manager. (Are we seeing a pattern here?) The manager may not realize your team attends a daily stand up where you discuss some of the important details he wants. But he likely wants to know more, as in, how many tests you have written, how many executed, and the pass rate, and number of defects and their severity. For this situation, I suggest asking your manager how the metrics are being used. If he wants metrics just to make sure that you are being productive, then attending the daily stand up would satisfy that request. He won’t need to come daily but perhaps he could drop in once-in-a-while to get a pulse on what is being accomplished. Your manager is used to getting detailed info in summary form from the testers/leads, but now he has to do a little legwork on his own, which he isn’t used to. Feel free to get your scrum master involved too. The request for metrics, in this case, is an impediment to getting work/commitments completed.
Based on every issue from above, you are 100% certain that your manager doesn’t understand agile. You are trying to support your team, but you also need to support your manager. What’s a QA Analyst to do?
Solution: This is an alignment issue with agile teams doing the work and a QA manager who comes from a traditional background. Believe it or not, there are many situations of new agile implementations that have this model. This disconnect is probably the same reason your manager wants a daily status report since he or she isn’t attending the daily stand up. Lack of visibility into your day-to-day activities doesn’t mean they aren’t happening. The disconnect is that the QA manager isn’t plugged into the agile teams under her purview. Many of the solutions mentioned above will address this issue. Diplomatically educating your manager, including him or her in agile ceremonies, and inviting her to daily standups are all ways to up agile understanding. You can also make sure that your manager understands what you need from her. The common thread in all of these scenarios is that your manager doesn’t know what to “do” when the team is agile. Her toolbox of artifacts, reporting and management style doesn’t fit with agile. She should work with the testers to ensure that tools for testing, test data, training in test techniques, etc are available across multiple sprints/teams. She could also establish release level testing strategies, resource and skill planning.
Although agile and traditional waterfall methodologies seem completely opposite from one another, they both have the same end goal… to get a quality product to the market as soon as possible. Through experience and collaboration there’s no reason it can’t happen. However, there is no doubt that implementing agile in the right way is more difficult when your manager doesn’t truly understand agile, and wants to continue doing things old school. Along the way, there must be continuous education for those who don’t spend their days in agile. If your manager’s main exposure to agile is an agile overview PowerPoint and he is not living agile in his day-to-day work tasks, it will definitely be difficult to have complete buy in and understanding of what you are doing and how you are doing it. But by using some of the tips from above, the QA Consultant can be armed with the tools necessary to add value to his agile team and exceed the expectations of his manager. And maybe a happy ending can be possible after all.
Up Next:
Watch this short video for tips on how to combat Scrummerfall.
