my return of experience on AGILE projects

The thoughts below are based on the syntheses of my own experience of 3 years project management, many books and blogs, and finally on the Tech-Ed 2008.

Having being interested in AGILE for a few years by now, and since I had the chance to compare a 1.5 year non-Agile project management and 1.5 year AGILE -one, I wanted to share some experience.

How to ensure an AGILE project to go bad ? It's simple : if you apply the Agile techniques dogmatically, without thinking by yourself !

In the past, I only picked up few elements from the AGILE methodology in my projects, and never claimed to use The AGILE methodology. However, as soon as I tried to make it more Agile on a 6 people team, I was facing some of the problems presented below.

1. Enforce a daily Scrum meeting “by the book” where each person speaks in turn to answer the 3 questions. For our team, tt appeared that only few and minor problems came out of during those meetings. Crutial problems suddenly appear after few iterations (e.g people hating each other, ...). Why? the team was asked to speak in turn, that’s what they did, without really admitting in front of others their problems. Solution: I could probably come out with better solutions, but those two below worked. On top of daily scrum, I added

- non official ones (pubs, coffee, ..) where real problems could be raised unofficially. It enabled to reveal fundamental problems (addressing those problems is another story!).

- a one-to-one interview

2. Deeply involving the client in the iteration process : The good side of it is that we are sure that the application’s fundamentals are implemented. The dark side is that, since we are using “software factory” with 3 platforms (development, integration and production) each delivery has to go thought many phases and tests, which is good … until the customer wants more frequent delivery for good reasons. As a result, instead of a 2 weeks' iteration, I had to deliver every second day, if not every day. Problem? This is leads to unhappy customers facing a bad quality and unstable version to meet the schedule. Moreover, the whole team was spending time in testing and releasing instead of developping new features. Solution: easy! Since it was agreed to perform a fortnight release, I should have refused from the very beginning to deliver within a shorter period of time.


Why those problems ? One of the reasons was that, at that time, I knew too little about SCRUM !, and second, because Agile methodology is like a recipe, with 3 phases:
1. Simply apply exactly what is written (however, you don’t exactly have the same oven, you don’t have exactly have the same ingredients, …)
2. Based on the recipe, you could customise it to have something suitable to your customers
3. Once you have a lot of experience, don’t follow any recipe : follow your own way
To me, in order to achieve a successful “AGILE project”, is to do “agile project” where sentences like “in Agile you must / have to do this and that” should be avoided. According to one of the “creator” of agile methodology, the second and third case should be reached, i.e. have some experience/maturity and be flexible to adapt to the customer’s environment changes (e.g. changes in law regulation since the beginning of the project, new innovative ideas were found after the few first iterations, …). If you simply apply AGILE methodology exactly according to the book without analysing what is written “between the lines”, the project will probably lead to a failure.