Packetfury.net

When you move rapidly from one project to another, you need to adapt, fast. Some clients take the time to create a project, laying out every detail before acting. Others simply do not have the time to prepare, and set out the foundations while working on the project, even if that means doing some of the work twice and seeing some of that work deleted. Some clients literally cannot wait.

Agile is one of the methodologies that I've used, and it was also one that I really liked. I have a tendency to read about everything I can on a subject before deciding what I really think of it. I don't rush in head first, only to find myself in the middle of a mess I really don't like. I take my time to study and think (which doesn't necessarily stop me from finding myself in the middle of a mess). Agile was one of the subjects that I came to learn, and one that I liked from the beginning.

My first experience with Agile was with Ripple Motion, and right from the beginning I had my doubts. The idea of post its everywhere was a little strange, but the visualization that it offered was compelling. I followed in their tracks, but I also read around on my own side. And slowly, I started to find out little details that just didn't sound right. Ripple Motion self-proclaimed themselves as "leaders" in the Agile community, even of they were just two people, running very small software projects. Applications that geolocalize you, or applications that give you "love tips" do not count as major projects. After a few weeks, I noticed that they were using the principles to their own advantage, and to my disadvantage. They were breaking simple rules, and ones that I could quote from a book. It became a situation where I had to apply to the rules, but the direction were free to stray from the tracks. Of course, in any company, the direction is free to do as they please, but not as far as methodology is concerned. Agile was used to point fingers at people, and one principle that should never be used, show who is "slow" and who isn't being part of the team. There were charts showing exactly who did what, personalizing each member of the team where it was supposed to show only what the team did. Members were frightened more than anything else. Scrum allows us to highlight potential problems before they arise, so that we can adapt. If someone is having problems with a particular aspect of the code, he is free to say so, and others around him know that he has a problem, and can offer help, advice or resources. With Ripple Motion, that was clearly used to point fingers at people and blame them for everything that went wrong. Ultimately, my contract at Ripple Motion was terminated for that; while it is written Java on my CV, it is not my strong point, and when I took a long time on a Java ticket, I was accused of not seeing Agile advantages, and I was laid off.

I've learned one thing -  anything that is good can be made bad by evangelists. It was hard enough having Mac evangelists that consider it to be a question of life and death to show that Macs are better than any other machine for everything, but evangelizing a methodology is even worse. From time to time I really considered myself to be in a church, and was openly asked to "preach" their cause outside of work.

Gwaredd Mountain said it right in his blog - "The hype and dogma of Agile evangelists has left in its wake a trail of broken projects, ruined businesses and misguided neophytes bleating the tired doctrines of their long departed prophets."

After this experience, I'll admit that I was a little lost. A tool that is used to help and guide people was used against me, and it cost me my job. The advantage is I didn't need to print a resignation letter, they did it for me, and the next day I had something else. That something else was BlueKanGo, a company that makes SAS applications. They use Agile, they use Scrum. They saw that I use to, but they also noticed that I was a little confused, so they sent me off for some training, some real training, in the form of Laurent Morisseau, a consultant in Rennes that does Agile training. I finally had the answers to my questions, and I returned confident, knowing that I was right. Then I saw Agile applied for a team of up to 20 developers (in 2 teams), on a project that had close to 3 million lines of code. There were no evangelists, only people sincerely interested in the project and the team. Everything that was done was done to show what the team had accomplished. Some developers were better than others, some of them were slower, it didn't matter. Everyone was doing the best he could to get the project done. People have their good days and their bad days, and people do make mistakes. When a mistake was made, and found, it was corrected. No fingers pointed, no accusations made. If someone said that they had a problem, they were guaranteed to have a helping hand within the hour. Now this is what Agile is all about. The development team were transparent, and had confidence in their leaders, and spoke to them in terms they could understand. In exchange, the leaders trusted their developers, and gave them the ressources necessary to complete their task.

Today I am no longer using Agile, but only because the current client  doesn't use it. If the opportunity comes up again, I wouldn't say no, so long as I'm working with professionals.