I’ve worked primarily as a software technical lead, and have always had a strong interest in finding better ways to do good engineering. I started out as an electrical engineer also responsible for the software part of the flight simulators that I worked on. It’s been a long and interesting path (doing testing, systems engineering, even project management) but now I work independently to coach project teams and their managers in the use of Agile and Lean ideas. I say ideas rather than practices because I believe that independent thinking is the best path to take if you are to get all the benefits that Agile ideas offer. But that path requires you to gain genuine understanding. It’s not as simple as following someone else’s set of commandments.
The “independent thinking” path is the one that brought me to Agile practices. After experiencing several advanced techniques (collective code ownership, strong unit testing, incremental delivery) with contractor teams was on, I had a chance to lead the software effort for a new product from scratch, with a team I could recruit. I wanted to try all the practices together. We launched the project and staffed the team. I tracked metrics as the project went forward and they were showing a picture that was hard to believe, and hard to explain. This was the late 1990’s and there was no “Agile” community. We were simply trying ideas and keeping what worked well. Our active bug list never had more than 2 items, and we were delivering releases within a day of estimated time, and our quality levels were about 0.2 defects per function point.
When Kent Beck’s “Extreme Programming Explained” came out, it was a pretty good description of what we were doing and that’s how I came to be associated with the Agile movement. When our project ended and our company got out of that line of work, there was nowhere to go if you wanted to continue using Agile practices. No one had heard of Agile so they weren’t interested in it. I was never going back to the old ways of sequential waterfall development so I decided I would try to help this new thing catch on. If it did, great; If it didn’t, I’d leave engineering and find another field to work in.
Agile did catch on, so much so that it’s in danger of becoming a victim of its own success. But the important things have not changed. They include a mix of technical, management, and teamwork elements that coaching can convey well. That’s why I coach.
