If a piece of software is going to rise above the rest and perform well, two groups have to work well together: dev and QA. Implementing an Agile process can make that happen.
For years, I worked in a Waterfall environment. The dev group worked for weeks, sometimes months and then handed us their code and a requirements doc and we started our QA process. If you’ve been in Waterfall, you know how this works and you probably know why so often, it fails.
The concept behind Waterfall, separates the dev group from the QA group at every level; processes, communication, control. On the darker side, it pits us against each other. On the projects I was on, the dev cycle would inevitably need extending, due to bad predictions involving the project time-line, which meant one thing….the QA cycle would get shorter. The shorter the QA cycle, the larger the stress and the more resentment, frustration and blame passed around.
If QA doesn’t have enough time before release, bugs go into live. It’s that simple.
A couple of years ago, a wonderful thing happened. My CTO at the time, chose myself and one other from the QA group to lead the next-gen project for the company, using an Agile process: SCRUM.
Migrating to SCRUM
First, we were involved from the beginning. I think that QA has the best ‘big picture’ perspective of the whole project, because we test all of it, all the time. For us, to now be involved in the project planning stage (Product Backlog Meeting) was priceless. We brought the ‘down the road’ problems with an implementation, to everyone’s attention and therefore prevented a lot of wasted time on all sides.
Second, every day, we got to talk to the full group and find out what everyone was doing (Daily Standup). We were now privy to all the break room dev comments that we never heard before and added SO MUCH VALUE to our process. We would hear things from dev like “this is hard”, “I can’t figure out how to make this work”, “we can’t do what client-facing is asking because of this or that programmatic limitation…”, etc. We would take that information and let it mold our testing process and it was very successful.
Last, but definitely not least, due to SCRUM’s incremental dev approach, we were testing new code the day after our release to live, preventing the Waterfall bottleneck which causes so much undue stress and adds so much risk. For the first time, we had time. We had time to test the new code, test around the new code, get the bugs to dev and back, all before the release. WINNING!
In summary, a synergy between the dev group and the QA group is imperative to the delivery of a successful piece of software. Using an Agile process brings that synergy into focus. It turns around the rampant ‘us against them’ feeling that so many companies endure in their SDLC.
Want more Agile?
Our very own ModUX conference in Amsterdam will host a few phenomenal sessions on agile development:
– 5 New Rules of Software Product Development by Patrick Sheridan
– Agile UX Development for Global Audiences by Michael Aldana
– Practices and Obstacles in Agile Development by Thorsten Suckow-Homberg
If you can be there on September 18-20th, 2013, let’s discuss about agile in your projects!
Have you had this experience? Struggled with Waterfall and its’ segregation of dev and QA? Leave us your comments, we’d love to hear about your experiences…