Rethinking Agile Methodologies Part I: How I started to use Scrum

In the beginning I used waterfall. There I said it. Looking back at the mid to late 1990s, I can’t believe how I ever got software developed at all! ;)

I was first introduced to Agile methodologies ten years ago. When I was the CTO of Zagat, one of our board members gave me a copy of Kent Beck’s original Extreme Programming Explained. At the time Zagat was doing a modified version of waterfall that was more “agile”, meaning we were doing things quickly and responding to the needs of the business (this was the .COM boom you know!), however, we were not Aglie insofar as we practiced any specific agile methodology. I read over Kent’s book (note to all of you CTOs out there, a board member gives you a book, you read it) and dismissed the concept of pair programming, but embraced several things in the book, including continuous integration and short iterative release cycles. At the time I don’t think it was called “iterations” but I sold it to the CEO as “short iterative chunks” of functionality. I would not make the argument that we were implementing XP, however, we did take some tenants of XP and roll it into our process. We even hired Steve McConnell to come in and help us with that. (That was the best part of the .COM era, we had budget to bring in Steve McConnell!)

After I left Zagat, I started my own business in New York. It was an online service to allow people see how the economy was doing by looking at the ad spend in certain categories (like jobs, autos, and real estate). At my new company we had 1 developer at first, so we started using a blended Waterfall/XP/Sprial/fly by the seat of your pants process since we were in startup mode. After we grew and had a few more developers, my lead developer forwarded me a blog post about Scrum. I read it over and told him that it was cool, but probably just a fad. (He still likes to remind me of this!)

A few years later we augmented our developers with a team in India. We suffered communication gaps and poor quality. (This was BS, or “before skype” in like 2004.) I was desperate to get a productivity boost from the team in India. It seemed that after each of my frequent visits to India, the team was running at like 200% for a few weeks and then leveled off back to the poor productivity. I decided to try out Scrum since the parts of our process that worked were the items we borrowed from XP.

Almost overnight Scrum worked very well for us. The team in India and the team in New York were in complete sync and the business was on board with the rapid release cycles (sprints). Since we were a small company, the entire company could participate in the daily scrum, increasing the communication flow and buy in from the business side. The team in India got addicted to the daily scrum and were in the zone. We were running circles around our competition. Life was good.

Then I read the scrum books. I read the section on “A cost effective alternative to offshore development.” (p136.) The guidance was not to use Scrum with offshore developers! (The argument was the scrum made teams so efficient that you did not need to go offshore.) There was also a section called “Rules.” I realized that I broke just about every rule! I was young and impressionable, so I figured that even though Scrum was working so well, if I followed all of the rules, I would get even better results. So I decided to become a certified scrummaster.

After a lot of trial and error, I realized that it was best to break the rules. More on this in my next post. ;)