One day I heard about eXtreme Programming. Wow, I was a student, eager to know, and I tried to live on the edge. Extreme was just what I looked for. Soon after I got Kent Beck's - Extreme Programming Explained, the first edition. I read it very fast and that was a decisive moment in my programming life. I thought everthing in there was good but not appliable. I said , you can never have 100% unit tested code. In time I saw I was wrong. I said PP costs double. I was wrong. Every practice was for me a new impossible and as the time got by, I found it less and less imposible but as the book said very beneficial.
I see lately more and more people hearing about XP and then trying to resist to it after seing that it is really extreme. My advices, a few years later, in a much better context as there are much more people that can help, much more tools, more proven cases and more openness.
I want to adopt XP. What is the plan?
When I first started with agile methodologies, as a developer, I had to think about
what to do to be able to make the team,the company, the business, become agile.
Sell XP to yourself
In order to do that I had to sell XP to myself in the first step. I thought that if I'm both the vendor and the client, I must think what would I, as a developer, like to achieve by moving to another way of working. Since I was selling XP to a developer, I had to show myself how I could go home being confident that the code runs, be able to work 40 hours every week, be able to apply my new ideas very easily, without fear, that I might break what I already did. I discovered that TDD and automated tests can give me the confidence and from that I was be able to move faster and add ideas to my project, motivation started going high. Refactoring and simple design, allowed me to minimize rework (smaller and simpler code is easier to debug and enhances flexibility). Continuous integration is very important, as it lets me go home happy and find in the morning if I broke something in the worst case. Continuous integration maximizes the feedback from the code to me. It is a bell telling me that I broke something. It is by running the tests, the break detector.
After a few months, I was able to have reasonable enough confidence in myself to go to the practices skeptics. I could confront them, not always very well, but as in Alistair Cockburn's - 'shu ha ri' the tree levels in aikido, things must go ahead ,slowly but ahead, to the next level of expertise and knowledge.
After I've convinced myself, I could convince other developers.
In convincing other developers about agile/xp practices, I use the 'self training'
technique, where we take a book/article etc and every morning we all stop work for an hour or so and read a chapter, the answer a few questions to see what each understood then talk until the things described there are understood by everyone. More at: http://danbunea.blogspot.com/2005/05/self-training.html. The others could see that I did not invent the things, but they will read them there and I was able to explain how they work and answer their questions.
Slowly I was convincing the developers. It was time to move upper - management
Sell XP to your management
In convincing managers you have to remember that they are managers and they are
running a business. They don't care about better code design and more automated tests. They care about money, and you need to show them how these practices can maximize profits. I wrote a simple sample about how TDD minimizes costs here: http://
danbunea.blogspot.com/2005/09/how-tdd-improves-development-speed-and.html.
I started small, but I tried to explain the advantages of iterations and customer on site (if that's not possible in direct contact with no proxis). If I were to explain again I would expain that these two eliminate communication gaps and show examples how in the past commujication gaps costed money. A lot of money. Then go further to user stories. Another communication problem. I tried to show that writing very detailed spec is very costly and has a high risk of being thrown away when changes occured. When management sees that costs can be reduces and profits improves (don't overpromise!) they start to be convinced. They like statistics.
Selling to the customer
The customer must be informed from the beginning about what you're planning to do and the iterative circle of life (see Ron Jeffries's XP Installed). Convince them about the benefits, using the same methods as for managers. Less time, less money, better quality, running, tested features after just a couple of months, at maximum.
I needed about 2-3.5 years so far and I am not ready. I am still becoming agile, just like everyone else. But the situation is changing. More and more people hear about the good results of XP and that might bring down the resistance wall faster. The most time was ,needed to sell agile to myself. I was slow, eating more then half the time just to see that it might be possible to work. But when I saw that there was a chance, I was just agile infected.
Conclusion - XP won, slow but I'm XP infected now and don't regret a thing
I tried to share a little about my experiences in becoming agile. We
are very small (as a company), and that's a huge advantage, but I have seen good results even in monster companies. Just determination is needed. And XP will win, as it did with me.
