Nate Oster explains how acceptance test-driven development (ATDD), even if met with initial hesitation, alleviates stress and workloads for testers and developers alike. With hands-on gaming exercises, Oster helps teams, and attendees to his sessions, see the benefits of true agile testing.
Noel: As an agile coach, what types of strategies do you use to help people "unlearn many of the patterns that traditional development taught us."
Nate: I'm passionate about what we call “player-coaching,” where a coach joins an agile team as a participant, and they then model new behaviors and practices over a few iterations. That way, team members are learning new skills just in time, using their own work, and without disrupting their flow. I've found that player-coaching dramatically increases the team's odds of making long-term improvements.
By contrast, traditional classroom training might be good for creating buzz or planting new ideas, but unless people immediately apply the lessons to their own work, it’s not very likely that the new technique will take root. After a few months, retention of new concepts is usually very low. I first noticed this “half life” of information in college when I'd cram for tests, and then promptly forget everything a few weeks later!
It turns out that the secret of retaining new information is forming an emotional connection with it. Lectures aren't very emotional. One strategy we use at CodeSquads is immersive simulations instead of classroom style lecture and exercises. Our simulations strip down agile development practices to a few essential concepts, and create hands-on “synthetic experiences” that give participants an emotional connection with those ideas, mostly through the stress of friendly competition. We're only going to remember a few key concepts in six months anyway, so we should laser-focus on the concepts we want to retain at a gut level.
A good example is the new “Kanban Racing Challenge” we're hosting for private clients, where players learn the basic practices of a kanban team by building a racetrack for RC cars. It's a physical case study that gets us out of software development, and just focuses on how we work together to maximize the flow of new features with high quality. It's interesting to watch: Team members instinctively begin testing and developing in parallel because the tracks are error-prone and the best design is unclear.
They adopt the agile testing principle of "building quality in" with continuous testing, because they can see at a glance that if they test later, they won't maintain a high-quality product, they'll fall behind the other teams. What always surprises me is how fast participants transfer these lessons from a physical game and apply them to software development—focusing on a few essential concepts with competition really does allow people to "get it" and then retain those lessons for the long term.
So our pattern for installing durable improvements is hands-on simulations followed by hands-on player-coaching.
Noel: As an advocate for acceptance test-driven development, do you think that ATDD benefits testers or developers more, or are the benefits truly equal for both parties?
Nate: I think that when we master agile testing with ATDD, there's no sharp line between specifications and tests. They're just a specification of what a feature should do before we'll consider it “done.” That means everyone on the team needs to be specifying collaboratively, to the point that there doesn't have to be a dividing line between the tester and developer roles. It's really just about who has the right skills to complete the work.