I spent eighteen years testing before I ever worked with agile. When I suddenly found myself transitioning to an agile team after all that time, I thought, How hard can it be? I’d always had a strong work ethic and the ability to handle multiple priorities well. Agile would be no problem, right?
Wrong.
My work ethic and multitasking abilities flew out the window initially when I was thrust into my first agile environment. I thought I knew what “fast paced” meant, but I wasn’t prepared for the hamster wheel moving at the speed of light. Speaking of light, since we were on a two week sprint cycle, there was no proverbial light at the end of the tunnel except for another train coming… always. And I felt like it would hit me head on. How would I get used to this? Was I only cut out for old-school-waterfall? The short answers are: painfully, and no.
The client I worked for at the time changed from waterfall to what I now know is more Scrumerfall than true agile, but at the time, I didn’t realize some of the pain I experienced came from the pitfalls of hybrid methodologies. Two years later, with more agile experience and some great training, I can understand what was and what wasn’t agile about the organization. I know my situation wasn’t unique as many IT professionals find themselves mired in Scrumerfall environments. If I could turn back time, knowing what I know now, here is some advice I would have given myself.
It’s good to have support from the right people and I am not going to lie… I made the ScrumMaster my best friend. Any question I had not specific to testing, I asked her. She was a mentor, and now a best buddy. In those early days, she was the supportive voice of agile for me, since I was not co-located with the majority of the team. In addition, I had resources within my consulting company that I could go to for advice. I also tried to read about agile as often as I could.
Make sure you are communicating constantly and effectively with your team. With the global workforce these days, chances are your team will be distributed across multiple locations. Assumptions about what people know and don’t know can bite you in the butt and then haunt you for a long time, sprint after sprint. Be clear every step of the way, so there is little room for misunderstandings. At first, it seems as though you are constantly in meetings, but the goal of these meetings is to ensure that everyone is on the same page which translates into more unified team vision and higher quality products.
Anyone on an agile team knows that each day, on your stand up, you let your team know what impediments you have, if any. If you realize at 2 pm today that you aren’t going to get data you need to finish testing a story, DO NOT wait until tomorrow morning’s stand up to call this out as an impediment. Let your ScrumMaster know right then you found out the data will not be ready. He or she can escalate to the product owner for help. One thing I learned the hard way is time is critical in your sprint. A few hours of downtime can be insurmountable later to complete testing.
The product owner on your team needs to be your new best friend. Wait, didn’t I say the ScrumMaster was my best friend? Can you have two best friends? Maybe not, but I won’t tell if you won’t. Bottom line is the product owner needs to be a good friend of yours as well because you are going to need to work closely with him or her. This person is key to many questions that will come your way with respect to story acceptance criteria. Also, the product owner is the person who can tell you in a nanosecond what priority a defect is.
Waterfall worked for you, for many years. We get it. However, you need to approach this journey with an open mind. Learn as much as you can, as fast as you can. Understand that your job hasn’t changed, and 90% of what you do is still the same. Only the approach has changed. You will still be writing and executing tests, and writing defects. The difference is, that in most cases, you will be working on pieces of functionality rather than a whole system.
Just like the ScrumMaster and product owner, you must keep the developers close to you. (Are we seeing a pattern here?) Chances are, you will need to reach out to them with questions often while testing. Plus, any comaradie built between dev and test is a great thing, especially in agile. You are a nimble, powerful team, after all.
Let’s face it, QA usually has to multi-task. In this new agile world, you are probably going to have many tasks going on at the same time now. You may still be writing tests at the same time that code is being delivered, and then will test while you are planning for the next sprint. The key is to focus on the highest priority features, and get those completed first. Frantic multi-tasking shouldn’t be the status quo.
At first, the retrospective is one more meeting that you have to attend. You may not see the value in it. Use this as an opportunity to have a meaningful conversation about what worked and what absolutely did not. You need to have thick skin. Don’t take comments from the retrospective personally, at the same time, be courageous enough yourself to ensure any “elephants in the room” are brought and discussed. One of the best ways to build trust amongst the team is to engage in open and honest conversations. Everyone needs continuous improvement.
Don’t get so caught up in the fast pace you can’t fully appreciate what you accomplished. Each of the pieces that make up the sprint are accomplishments in themselves. Before you have even written the test cases, you had to ask questions about the stories, story point them, and estimate them. Every so often, take a moment to reflect back to the first or second sprint you ever engaged in and realize how far you’ve come…yeah, that’s right… you rock!
With no hesitation, I can say I now prefer agile. I drank the Kool-Aid, and went back for more. For this Old School test lead, it is the new normal. The biggest reason I prefer agile to waterfall is, in my experience, it felt much more team-based than what I worked in before. We planned together, worked together, and were brutally honest with one another at the end of the sprint about what worked and what didn’t. With Waterfall, I couldn’t help but feeling the team as a whole was fragmented, working in their own silos.
If you are new to agile, working a few or all of these tips into your work flow will help it be your new normal in no time.
Up Next:
Watch this short video series on 5 Success Tips for Testers Moving from Waterfall to Agile.