Skip to main content

Dale Emery

DHE

Since 1980, Dale Emery has worked in both IT organizations and software product development companies as a developer, manager, process steward, trainer, and consultant. He helps people apply the agile values of communication, feedback, simplicity, courage, and respect to software development. Dale's combination of deep technical expertise and extensive organizational development experience makes him particularly effective in working with software teams. In 2007 Dale received the Ward Cunningham Gentle Voice of Reason Award, which the Agile Alliance created to recognize Dale’s unique contribution to the agile community. Dale's personal mission is to help people create joy, value, and meaning in their work. Learn more about Dale at dhemery.com

Speaker Presentations
Wednesday, June 5, 2013 - 8:30am
Keynote
The Art of Change: Influence Skills for Leaders

An organization’s ability to make improvement, whether for greater agility or other goals, involves two components—a technical component and a people component. The technical component is generally logical, linear, and relatively straightforward, and the technical change agents are often skilled at implementing the technology. On the other hand, the people component is never straightforward.

Thursday, June 6, 2013 - 2:15pm
Testing
How to Survive the Coming Test Automation Zombie Apocalypse

Test automation is software development. To automate tests well, you have to have brains. Unfortunately, the very brains that make you good at your job also make you highly attractive to zombies. Like all zombies, test automation zombies are brainless, insatiable, and relentless. Unlike human zombies, test automation zombies can be difficult to recognize. They don’t look like people at all. Some look like org charts. Some look like best practices.

Monday, June 3, 2013 - 1:00pm
Half-day Tutorials
The Developer’s Guide to Test Automation

Your shrinking project deadlines are increasing the need for automated tests—but, simultaneously, reducing the time available for writing them. The system requirements are continually changing. The implementation is changing. You spend more and more time maintaining old tests, leaving less time to write new ones. The tests take longer and longer to run. And when they fail, the problem is as likely to be in the tests as in the system.