How to Turn Agile Into Chaos

I got inspired to write this article because of a classmate from the SPM specialization who wrote a post called How my company raped Agile manifesto. I wanted to write a little bit from my experience at a failed project in my company and try to justify my classmate´s company by pointing out how a misinterpretation of the agile manifesto can lead to losing a significant amount of money and failing at a project.

Once upon a time the sales guy on my company approaches a very young and handsome product manager and says "There is this company who wants us to develop this weird project". Well, turns out that this young product manager was me and this “weird project” came along with some complications. Despite of that we took on the project since the client had, what we thought, was a good budget and it was supposed to be a good opportunity for us.

I was on the last year of my Computer Engineering degree and I was taking the software engineering specialization where they taught us this new and revolutionary way of developing software called “agile” so I grabbed the “agile manifesto” and put my team to work.


Individuals and interactions over processes and tools

Every one on the coding team had the client number and vice versa, so we all had face to face interaction and access to the client, but the project had a really big scope and a 5 month launching deadline... just the right formula for chaos.

Our client dreamed of a fancy new idea every night and upon waking up would call me to ask for this new requeriment. As I was aware of the project limitations I told him that this was not possible within the project budget and deadline, but our really smart client was determined to get what he wanted so he started calling the programming team members one by one until one of them said that he was going to do it in the next iteration! So... we had a new requirement being developed without the PM's even knowing!


Working software over comprehensive documentation.

We delivered working software on every iteration without doing any previous documentation because of the very limited amount of time that we had to launch the project.

The problem was that most of the time the the coding team and me failed to really understand the client´s needs and developed what the client thought he needed. So, on almost every delivered piece of software on each iteration the client realized that it was not going to solve his problem and asked for a lot of changes that slowed down the programing team leading to more and more crunch time to make the deadline.


Customer collaboration over contract negotiation.

Hell! one of the coding guys even said "we are going to make all of your dreams come true"... guess who the client called every time a new requirement popped into his head?!. So, we continued to add and add changes to the project trying to maintain the deadline but, of course, at some point there was no possible way of keeping it intact. Now we tell the client that we need to push the deadline, right? Wrong. There was this little amazing thing called contract that the company signed but no one ever read that said that the company had to pay 5% of the project total cost for every week pass the deadline. Beautiful right?


Responding to change over following a plan.

So, here we are, one week prior to the deadline and there I am telling the client that the software is not entirely ready because of all the new requirements and changes that we had to implement along the way, and that I strongly recommend that we don't go into production yet. But the client said that we had to do it and that he would take on the risks... as you can imagine stupid me said: “yes, and we will fix all these huge bugs along the way!” So I leaded my team into coding hell and to one hour of sleep per day.


In conclusion

I learned the hard way that “agile” is a two way street. You can´t just drop the second part of every rule thinking that it doesn't matter or that it is not important.

1- It has to be a controlled and supervised interaction between the coding team and the client so that every one is aware of any changes agreed on.

2- It's important to be as clear as possible on what's the client purpose for every feature so you can understand what he needs, not what he wants, and try to lead him in the right direction (I know this is not as easy as it sounds and it's more of an art than a science).

3- There has to be the proper contract adjustments if necessary when the client needs are getting out of the project scope.

4- You have to be sure that the client is open to respond to change too. Most of the time they lead to the need of more resources and you have to be sure that you count on them.