Agile development – advantages and disadvantages – Part 2

In my previous post I wrote about the simple situation when incorrect agreements and lack of proper reactions leads to poor results. Clients always want to know two things. When the thing will be done, and how much it will cost. The rest is less important because they want to trust you. At least they should. Trust is very important because it usually makes the client come back with another order later on. In waterfall approach, trust is usually on the same level from the beginning to the end of the project. In Agile development, since you keep in touch with the client, there is a risk that trust will go away much earlier. Why does this happen? Is waterfall approach better?

You have to earn client’s trust

Definitely, in both approaches (waterfall and Agile) it’s highly possible you need to start from a low level of trust. For instance 3 ( on the scale from 0 -10 where 0 means that the client wouldn’t let you even do the dishes after diner, 10 means that client would let you go camping with his daughter). In Agile, after having status updates with your client (for instance at the end of each sprint) client trust varies. Sometimes you make your client crazy because you forgot to put his name on the website. Later, you get used to him and grasp his way of thinking. Together with your team you managed to improve the trust level and at the last sprint client sent polite email to your boss reporting his satisfaction regarding the results. Really, it happens. At least in GOYELLO we have such nice situation. When you work using waterfall approach, it means that you are not able to make your client mad at you, but you also cannot earn the trust.

Size matters

Project size influences the way how trust is handled. If the project is small usually the client or the client proxy is directly accessible. In this case the client’s trust may be volatile even due to some insignificant yet to him, inappropriate message. FrOn the other hand, such direct communication enormously increases the chance for the project’s success because all issues and misunderstandings can be solved in no time. When project is quite big, usually the end client is represented by the third party. Based on my experience, I know that in such cases the trust is balanced on each person who is in the communication channel. This is the most complex case because if the person in the middle looses their trust, he/she passes it futher up. For instance, when my Project Manager recently fails to fulfill his promises, it makes my boss unhappy, the client facing person on the other side as well, and the end client, of course.

When you work in waterfall, such status checks are made internally, or semi internally. In other words, you show your progress to someone who is responsible for monitoring it but he is not obligated to trust you. Why? Usually, the results of the waterfall approach are presented to the end client and the very last stage – deployment. There is no more time for any fixes etc. Unfortunately, beacuse of lack of interaction with the person who should trust your solution (client) in waterfall approach you have very high risk of unpleasant surprises (not working modules, not in the way client would like to have it etc.). Even waterfall had the trust on the same level throughout the whole project duration, when it came to presenting the results the rest of trust is gone.

Warning! no client commitment = no trust = no Agile

From my experience I learned one very important thing regarding client’s trust while using an Agile development process. If your client (or client proxy) is not committed to attending sprint review meetings with you, this is not Agile development at all. If you want to work in an Agile way you do not have to arrange all kind of meetings but you have to show your results to the client when a sprint is finished. Always try to designate, at the very beginning of the project, at least one responsible person from client’s side who will accept your sprint review schedule and will attend them.

Tags: Agile