Agile vs. XP – What’s in a name?
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
Rich Clingman
10 years ago
There were struggles when making the change from independent programming to pair/reviewed development. The idea that “my code” was now being changed by others is something hard for most developers to embrace. The thought that someone is going to look over my shoulder while I type my code can also be intimidating. Thinking that someone needs to/should review the awesomeness of my code? There are many challenges when getting developers to make the transition.
Some awesomeness of the new development structure?
Old way: Independently working on a feature for six months only to have the needs change and the code largely discarded.
New way: Working as a team with two week cycles. New features are implemented, reviewed, tested, and released every two weeks.
Automated testing?
A large hard-to-embrace investment up-front to add unit tests and Selenium (web-based) tests to verify functionality. The payoff? Instead of needing two weeks of manual click-by-click testing, we are able to do thousands of clicks per hour with automation and have the assurance that what we say is “done” at 2pm on Wednesday is ready to go live that night.