Skip to main content

Be honest with yourself – is your agile implementation really just waterfall in disguise? If you aren’t testing as you go, the answer is probably yes. Too many companies often approach agile as “waterfall without documentation”, leaving QA until the very end while reaping the short-term wins of staying on schedule. That would be great, except for one thing…

You switched to agile so you could avoid last-minute pain

Agile was created in part to prevent the big, painful errors that can occur with waterfall implementations, where bugs written early but discovered late were really expensive to fix, both in time and money.

Agile only works if you close each circle

With agile, development occurs in tighter, more rapid circles, but those circles need to be complete. Testing performed by the end of each sprint ensures that bugs that could affect other parts of the product are caught and taken care of throughout the development cycle. Timely QA is critical to the success of any agile project. And if you do it right, testing won’t impede your process, it will accelerate it.

So, where does your company stand on testing?

Where does your company stand on testing? If you can say yes to all of the following, you’ve got a true agile QA mindset:

1. Your team is cross-functional (yes or no)
Teams using a sequential development process like waterfall are slowed down by handoffs; programmers finish programming a feature before handing it off to testers. Cross-functional teams make handoffs very small and very often – agile’s tight, rapid circles. Your teams integrate QA into the process early and often in order to deliver the working software expected of an agile implementation at the end of each iteration.

2. You know “done” means more than “developed” (yes or no)
Ideally, each two- to four-week sprint should produce software that’s deployable, meaning testing has been completed just as it would have been with a waterfall deployment. You don’t view development as the finish line; sprints are scheduled so testing is complete when the sprint is. That way you minimize people touching something that doesn’t work in the next sprint.

3. You trust the process (yes or no)
Agile isn’t a silver bullet, but it is fundamentally different from what we thought were best practices 10 years ago. Acceptance of change versus rigid specifications. Self-managing teams instead of top-down managers. Collaboration versus silos. And it provides a definite framework that shouldn’t be cherry-picked by companies who aren’t comfortable with switching from traditional development processes. You implement the full agile framework, not your own brand of “agile lite.”

Don’t find yourself in a situation where developers are pumping out code without integrating QA every step of the way. It may look like agile, but it won’t succeed like it.

Download our ebook: Breaking QA Agile Bottlenecks.

Randall McCroskey

About the author

Randall McCroskey

Vice President, Enterprise Solutions

Since 2006, Randall has been helping technology executives digitally transform their business as Vice President of Pyramid Consulting. Relationships are his daily driving force and his desire to trust and serve those in his professional and personal life constantly motivate him. Atlanta is a great city for Randall, as he hates the cold and prefers warm weather near the water. His greatest pride is the partnerships with colleagues, friends, and fellow professionals he has made along the way.

Cookie Notice

This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our privacy policy & the use of cookies. Please read our privacy policy for more information on the cookies we use and how to delete or block them. More info

Back to top