When I first encountered with Agile methods several years ago, the fuss was all about eXtreme Programming. The XP community in those days was pretty stringent about doing all 12 practices or nothing, and there was a lot of talk about working software, coding discipline, etc. I had the good fortune of working on a team that implemented XP pretty thoroughly on several projects with pretty amazing results.
Now, it seems like Scrum is the “new black”, and Certified ScrumMaster training is all the rage. Yet, having worked with many teams implementing Scrum, I do find that after some time, teams run up against an improvement plateau. In these circumstances, when the team is developing software, we almost always recommend getting disciplined with XP.
One major difference from the proponents in the early days is that we always recommend a context sensitive approach. Every project, every organization and every team is different. So, to accomodate these differences, we like to see teams adopt XP in a context sensitive way. This might mean doing continuous integration first, before attempting TDD. Or it might mean doing simple design and refactoring, but not pair programming. Always making these adjustments within the context of the project’s environment, but also always making sure we’re pushing the envelope and continuously improving. Of course, there’s always the caveat that these adjustments should be made with expert advice — after one doesn’t want people woh don’t know quite what they’re doing summarily dismissing something that might be quite valuable!
All is all, it’s turning out, that in the midst of all the Scrum success, XP can provide that next level of “lift” in terms of improving time to market and software quality.
