Back in the early days when Bryan, Jon and I started developing software we didn’t have any kind of methodology. We just gathered requirements as best we could and then built something.
Over time, as we did more projects we learned more tricks. Simple things like mocking up an interface and showing it to a customer… before coding. That was a big step. As the projects we built became more sophisticated, our specs got longer. Some of the longest specs were like books, and we edited them and edited them and finally gave them to the developers to code for months.
It was somewhere around 2006 when Bryan decided he wanted to try out eXtreme Programming. Personally I was luke-warm/skeptical. I didn’t really buy into pair-programming. I didn’t really get the planning game. And our big customer we would try it out on heard “eXtreme Programming” and basically said “No Way!” nicely.
A year or so later Bryan came back wanting to try Agile Software Development which wasn’t really that different, of course, but it sounded different. I think XP was dead in the water from the name. But we could all get behind Agile. I sincerely think the name made the difference with our customer.
It still took a lot of selling. The automated test development effort was a massive investment that we fretted about for a while. Running a parallel team alongside the main product team just for testing… that was just tough to get your head around. Even refactoring is a tough sell when things are working fine and the effort to improve the code and reduce technical debt is massive.
Of course the proof is in the pudding* and at this point most software companies are in some stage of implementing agile best practices. We got lucky – Bryan ran a good campaign for Agile and we picked the right horse early on.
*The original phrase is “The proof of the pudding is in the eating!” Which means you have to eat the pudding to know what’s inside of it.
Photo Credit: FreeFoodPhotos.com