I had been programming for several years when I became tired of supporting the PPP and Frame Relay code in IBM's first router. No, that's not it. What really drove me away was the threat of having to pick up support for LU6.2. Maybe it wasn't LU6.2. Maybe it was something else, but it was definitely SNA. That's not the direction I wanted to go in. I wanted to work on IP. Any part of IP. I'd have been happy supporting basic IP, UDP, TCP. Developing any of the routing protocols would have been great. That's where the future was going to be. SNA? Yuck.
Prognostication in the early '90s -- score one for me.
I pleaded with the manager of the IP group to take me on. He had no openings. Or he no likey me. Or I had no IP knowledge. Whatever.
My manager at the time was Tom, a great manager and a real character. Tom was often railing about how many worthless meetings we had and how many people we had in them. Tom wrote a program in those days to compute the cost of meetings. All you had to know was the salary bands for the various levels and what level each of the attendees were -- stuff most people knew. Today you can get a program that does this for your iPhone. I digress. Tom was disappointed by my desire to leave his group, but was supportive in helping me find a place where I could grow and be happy. We'll come back to Tom in a bit.
A good friend, Sam, was working in the same division on some Smalltalk apps. Cool stuff, I thought, but I didn't realize how cool. Smalltalk will never make it, I thought. "What you are doing is kind of hard to buy into", I thought. C++ is where you want to be. I later said the same thing about Java.
Prognostication in the mid '90s -- Although Smalltalk didn't make it in the market, it would have been the thing to learn. Score one for me against Smalltalk's market-share; But -1 for being against Smalltalk as an important language; -1 against Java.
Sam's manager, Joe, offered me a position and made hints toward his retiring soon. I was thinking that if I couldn't work on IP I just might as well go into management. So I joined up. Sure enough, Joe very soon retired and handed the reigns over to me.
Now back to Tom. Not one month into my new role as manager, something was found to be lacking in our software. I don't recall whether it was a bug or an enhancement request. Whatever it was, Tom needed it for his product. My former manager, Tom, was now my customer. So, wanting to be a strong manager with a backbone, one who could make the tough decisions and stand by them, protect his team and his schedule, I said no. I either said simply 'no', or I gave him a delivery date way out in the future, which might as well have been 'no'. Although Tom was the man who helped me get this job, had given me a promotion along the way, and was now my customer, and although his request was quite small, I said no. When I became a manager I threw out the window all I knew about being collaborative. I stopped practicing what I believed in as a developer. I did what I thought managers were supposed to do. Tom wasn't my only customer. I had bigger customers with big projects and big demands. Tom was furious.
What I didn't know then was that this team of Smalltalkers was quite agile. Of course, we didn't have that term back then. Gosh. This was in the midst of the ISO 9000 certification heyday. I had to document our process. I never new managers had to do that kind of stuff! "What have I gotten myself into?" I thought. I really didn't know how to describe our process. I kind of knew what we did, but document it? I knew I'd need help and thought the team would be as annoyed as I with this task. I dreaded asking the question and I didn't fully understand the answer: "Iterative and Incremental" with a few other words wrapped around it. So, I wrote down Iterative and Incremental on the process document, wrapped a few other miscellaneous made up words around it, then whipped out MS Project and got my project plan in shape. And it was a doozey! Spread out, the project plan covered a very large conference room table. I was so proud. (But it was really quite disgusting.) I could demonstrate when we'd be done (well after everyone wanted it), how I carefully put the plan together (with painstaking detail), and how many more expensive Smalltalk contractors we'd need (don't ask). I knew nothing of negotiating scope. I project managed wrongly what could have been a nice agile project.
I knew I was missing something. I felt ignorant so I started studying. I went back to programming while trying to figure out what I was missing. Steve McConnell's Rapid Development and Steve Maguire's Debugging the Development Process and Fred Brook's The Mythical Man-Month stand out as books that began to point me in the right direction.
Then in '99 I discovered jUnit and very soon after got invited onto an XP team, thanks to Greg Houston. Greg would say I resisted XP. Perhaps I did. But I soon fell in love with it after I got used to pair-programming. That took some number of months. Then I began studying XP, writing about it and tried to spread it. I was there at the start of XP Atlanta, which was led at the time by Obie Fernandez and which we later renamed Agile Atlanta. I attended XP Universe in 2001. I practiced XP on a number of projects then started speaking about it within the company, at a local user group and at a nearby college. I also submitted an experience report and a research paper to XP 2003 in Genova. I knew I'd be using agile for a very long time.
I thought I could convert people, that people would readily see the light and that in just a few short years everyone would be doing XP. They would be won over by my passion if nothing else. People would flock to our XP user group. jUnit would lead people to XP and the XP books would convert everybody. And I knew this would happen throughout the industry.
Prognostication in the early '00s -- score one for industry wide fear, uncertainty and doubt with a big helping of resistance to change.
My Prognostication Score: 2 out of 5.
After some years of being an agile developer and advocate in an organization lukewarm to the concept, I decided that I wanted to get onto a team where everyone really wanted to do XP and management supported it. And I wanted to try my hand at managing again, this time in an agile fashion. I found such a team to manage and I did much better this time (though considering how bad the first time was, this might not be saying much). This project eventually brought me to my desire to practice lean/agile on more projects, so I became a coach for hire.
So that's how I came to agile and here's the moral of the story: I think it's important to remember the route you took and how long it took. For most of you I suspect it wasn't really overnight. It might seem that way on the surface. "I got the book, read it, tried it, loved it, all overnight." Not likely. There was a road that got you prepared for the switch. Those we work with, those we try to coach, are on their own road. Have patience with them.
photo credit: Tomasz Wiech