A Firsthand Agile Transition Success Story: An Interview with Penny Wyatt


In this interview, Penny Wyatt discusses her Agile Development Conference West session, "Transform Your Agile Test Process to Ship Fast with High Quality," to share some of the ways she and her team achieved success, and how they—and you—can continue to develop and grow together.

Noel: The transition to agile is not easy. What kinds of advice do you give to teams who aren't attempting agile for the first time, but to those who've attempted it, and were unsuccessful? Where should a team start, or restart, to give the next attempt at it a better chance at success?

Penny: I think teams have a better chance of success of implementing agile if they start with a goal, and then look at which agile processes can help them achieve it. This is as opposed to starting with the idea of being agile and rote-applying the processes associated with that, in the hope of some kind of beneficial outcome.

In our case, we thought that we were agile all along—we had iterations, we had no specifications, and work was broken up into individual user stories. The clue that we weren't really agile was that we weren't reaping the benefits—we were shipping on a nine- to twelve-month major release cycle, where the last few months were nothing but bug-fixing and extra testing. This was self-perpetuating—when you're not going to ship for a year, does it matter if this iteration's stories aren't really complete at the end of the iteration? When processes appear to exist only for the sake of process, it is almost inevitable that people will start looking for ways to subvert them when they have other pressures applied.

What eventually triggered change for us was being given the ambitious goal of shipping every two weeks. This was impossible with the way we'd been working, forcing us to completely redesign our processes from scratch. Every piece of the process had to be absolutely essential, or it was cut. Now, we all know exactly why we do everything we do, and there are immediate impacts when we cut corners. This keeps us on the right track.

Noel: Your upcoming session at the Agile Development Conference West mentions that you'll describe "how to move responsibility for quality back to developers." What led to that responsibility initially being taken away from developers, and have you ever witnessed any resistance to this being back in developers' hands?

Penny: Originally, the JIRA team had no QA engineers at all—they were a small, fast-moving group of developers, that could ship to production after the automated tests were green. They didn't want a QA team and they didn't think they needed one. When the first QA engineer was hired, she quickly proved to them that she was needed—that the many bugs they were shipping could, and should, have been caught before release.

The developers had only ever written automated tests, and had never performed exploratory testing. They dismissed it as "manual testing" and viewed it as a waste of time—something only done by unskilled people, that added no value, that was made obsolete by automation. However, by the time I joined the team, the devs had become completely reliant on QA finding all the bugs that couldn't be caught by automation.

They were aware that their code was still very buggy after it had passed all their automated tests, and they relied on QA's testing to find all the bugs they had missed before we shipped. Yet, they still saw exploratory testing as an unskilled task that was beneath them.

Given this attitude, we had a lot of resistance from developers when we started asking them to take on more exploratory testing! Our toughest challenge was teaching them to do it well—they could be forced to test by their dev leads, but if they didn't want to learn, we didn't

User Comments

1 comment
T Hami's picture


Here at hospital “A” I have encountered the same testing push back from application builders.  They believe small, or easy changes require little to no testing.  Worse they often omit training notification changes as well.


  Our Health Information Technology department has introduced a strict change control policy, changes must be tested and approved by different teams from end to end prior to submitting to live environment. 


   I disagree with low risk areas skipping second review testing.  Small changes may work in an order entry pathways but if charge testing is omitted it can cause significant revenue losses.  Spending additional time testing, ensures enhancements work right the first time, and,saves time, money and lives.  


June 1, 2017 - 5:29pm

About the author

Upcoming Events

Apr 29
Jun 03
Jun 03
Jun 03