About

I’ve been working in IT for fifteen years and developing software for thirteen.

For five years, I’ve been learning, practicing then coaching agile software development because it fosters passionate, focused teams.

I am a Certified Scrum Practitioner and an IEEE Computer Society Certified Software Development Professional.

My first development job was in a three person consultancy working alone and crashing for a deadline. Classic code and fix. I was pretty successful at it. I generally delivered on time. Often through sheer force of will. My big weakness was not reaching out to learn from other developers. A sure sign of a new or just bad self-taught coder is that they bang away at a problem like no one has ever solved it before. I recognized this in myself and sought out mentors and learning experiences.

As I moved on to larger companies, I suffered under well-intentioned but corrosive attempts at waterfall. Craig Larman’s Agile & Iterative Development has a great description of how these attempts at perfectable planning and design are based on a misinterpretation of W.W. Royce’s writings.

Some of these projects were successful but the process prized simple agreement over trust. At it’s worst it created false hierarchies which hid incompetence and fetishized heroics. I was burning out. My friends were quitting. As if that weren’t bad enough, success often fit Mike Cohn’s description of delivering the wrong software on time and on budget.

Meaningful products can emerge from horrible process. But a way of working that tears down talented people’s desire to work is tragic. To repeatedly participate in this is to sap the world of it’s limited supply inspiration, creativity and joy. This is evil. My main goal is to avoid this evil.

About eight years ago, I took my first training from Stephen McConnell’s Construx. Stephen McConnell inspired me. He is open to different practices, sets high standards for performance, and champions a code of ethics for what he considers an emerging software engineering profession.

It is his work that inspired me to study the SWEBOK and acquire the IEEE software development certification, the CSDP. If nothing else, this study gave me historical context into the fraught disciplines of plan-driven development.

Over time I learned some techniques for effective iterative planning, risk management, and estimation. I learned how to work with others to deliver quality software. Through Earned Value Planning, regular inspection points and risk lists we built transparency into our practices. With realistic schedules we were able to maintain a reasonable work-life balance.

Still, the weakness I saw in my team and in my leadership style was relying way to heavily on the abilities and day to day motivation of individuals. I had to manage the project. My best developer had to work on it. If one of us had a bad day the project might grind to a halt. Our whole wasn’t adding up to the talents of the individuals.

It took me a while to really grok that excellence isn’t about adopting a shared set of practices. It’s about rallying around a shared set of values. I shifted from mentoring my team on how I did things to a conversation about why we do what we do.

The best in us wants to make a contribution, to deliver business value for our employer, be proud of our work, learn, and live honestly. Our humanity demands time for family, friends and outside interests.

I have come to embrace coding practices and a organizational style that supports these values. Specifically, Extreme Programming (XP) and Scrum. My recent focus has been on the management side. My short list of thought leaders includes Alistair Cockburn, Jeff Patton, Ken Schwaber, and Jeff Sutherland.