Monday, July 9, 2012

Extreme Programming Explained: Embrace Change, by Kent Beck with Cynthia Andres

The second book in the stack 8th Light has given me, Extreme Programming Explained: Embrace Change, wasn't what I was expecting it to be. Normally when I hear about XP, it's some eccentric way those new-age developers do things. Not something a real business can afford the luxury of. So going into the book, I was expecting some crazy, wacked out things like; the Batman programming technique is practiced by spends exactly 13 minutes everyday coding... while hanging upside down.

Turns out, nothing of the sort. The book just lists a bunch of really good ideas; test-first, automated tests, continuos integration, quick feedback, caring about quality, sitting with your teammates, communication focus, and so on. You know, the stuff that is really good for a development team and the business.

One of my previous employers practiced much of what the book covers, and oddly enough hadn't told me it was XP. My last employer ran from the word, cursing it to die. However they loved the idea of the individual concepts that I tried to push on them. It's odd how so many use good terms for their buzz and never really understand them.

So, what is XP?

Besides being a refresher for me, the book really took care to explain and relate amongst itself the various aspects of XP. I've seen most of the ideas in practice here and there, utilizing many myself. They really aren't anything that would be considered out of the norm for most teams that aren't afraid to keep up with the times. But the bigger picture that I was missing is how they feed into each other, making each more effective.

Sitting together in an open room wasn't just about creating a more friendly environment, it was also about building better communication. Communication wasn't just about better understanding, it was also about building the clients trust. Planning for and working short development cycles wasn't just about getting quick feedback, it was also about getting the entire company to shift their way of thinking. Testing wasn't just about confirming bug fixes and elevating fear, it was also the stepping stone towards building what the client needs in this cycle. Automated tests weren't just for one button test runs, continuos integration wasn't just to keep us from having to clicking publish; they were to reduce our stress levels, so we could code more clearly. Which I do decree; I will take to heart any practice that purpose it is, to reduce stress.

XP: Extreme Process

Another aspect of the book that jumped out at me was the care it took to reinforce that you don't have to be a programmer to be able to utilize XP. Quickly the book begins to tie in the practices of XP to the other aspects of a company. The practices build trust with the clients, the team, the employers. While improving the process and elevate pain for the other departments, the development team and all of the individuals involved. By tying the practices so closely to the other groups of people involved, you begin to affect how they work. All of a sudden clients, managers, executives, all have their role to play to make XP really work.

Embrace Change

In the end, utilizing one of these practices, a few, or all; doesn't become the focus of what XP is about. Its the change in the mind set. The breaking apart inefficient or down right bad development practices. Its about moving yourself, your team and your environment in a better direction.