Is Agile only for fearless companies?

Why is it so hard to implement an Agile methodology in some places when it looks so simple?. I think this has to do with fear, and how fear affects people. Let me show what happens many times with this dialog. It's between an Experienced Project Manager (PM), and a Agile Mentor (AM) in a big company:

- PM: When will we be done? I told them we would have things done by last friday, and they want to kill me already!
- AM: This is the first question managers ask when they turn to agile. There are many ways to know that, you can use your old method if it ever worked out for you, but it doesn't seem to work this time. The best thing to do, is to be real about it.
- PM: What do you mean with "be real"?
- AM: it means, you cannot break the sound barrier in a chariot, no matter how many horses you want to use or have a baby in 1 month with 9 women.
- PM: That is far from my reality, so... what do you actually mean?
- AM: That means, you can only guess, and the less you know the worst the guess will be.
- PM: If I only guess, then Agile is not being of much help! Give me back my money!
- AM: Sorry, no refunds... but the answer you are looking for is, this is an empirical process, meaning, you learn from observing.
- PM: I can observe that you are doing nothing for me so far, so tell me when I will be done?
- AM: Easy answer, if your team velocity is 10, and you have your users stories in your backlog estimated by the team for a total of 200 story points, it will take you about 20 weeks.
- PM: my stories are not estimated by the team yet, so that doesn't work for me.
- AM: see, agile is already paying for itself, that means you need to at least estimate your user stories to know when you will be done.
- PM: Ok, imagine I get the user stories right, and the team estimates them in the story time meetings, and it works as you said, that means we will be done in 20 weeks, not a day more!
- AM: No... you still don't get the essence of it, it will be highly impossible to have it by that exact date, since that was a guess when you knew little.
- PM: WHAT! Then... you owe me money boy!, this is not what the business want to hear! They want results!
- AM: You just say it, results, not lies!
- PM: Ok, you got me on that one, then, What do I do?
- AM: Ok, after each iteration, you will show them the progress of the team, we will make this very clear. Also you will know the updated team velocity, allowing you to recalculate the remaining work, and give them an updated competition time. Which will be more accurate than last time.
- PM: But... hmmm...then... using an agile methodology means things will take longer than expected, we are not able to do more with less as it promises.
- AM: Well, there is truth in those words, but... that is because you expected way too much, so... using an agile methodology, makes that very clear for you right after the first iteration, and will allow you to adjust the curse of the project to avoid bigger problems.
- PM: I'm starting to get the picture I think... but...then in a week or two, I will have to go to the business and tell them we will not be able to make it on time.
- AM: Well, I think that's great, it's better to fail earlier than later.
- PM: Nobody likes to fail!, why do you say that??
- AM: Because now it's a small failure, but will allow you to discuss with the business, show them the problem, and adjust what is needed to prevent a bigger failure later when there is no turning back.Now we have a methodology which will help you and them to make better choices, because you know things will go wrong, way before they get worst, so you only lost a little.
- PM: I'm starting to like that, but... still, I'm scared to tell them we will not make it on time, we need to change things. What should I do?
- AM: You need to tell them, they should know right away. The faster they know, the better the solution will be.
- PM: But, they will tell me we will not make more with less being agile, what should I answer to that?
- AM: Only with good management you get better results, because better ideas are the ones that lead to do more with the same or less. You now count with a great tool to know your problems faster, to make things better, avoid failure and lead the change the company needs to shine over the rest. You are not better because you are good hiding problems, you are better when you solve them with better ideas.

Fears

People doing software development know they need to progress. Many times, their way to show it is just committing to an impossible date. They will start pushing everybody to get to it, and many times sacrificing things that are important for the business. So using an agile methodology, they will realize they cannot do what they promised right after the first iteration, and they think they are failing. The first reaction is the same in many cases, hide the problem and try to do anything to show things are working by the end date, even if it's missing critical parts for everything to work or making the development team work tons of extra hours. This is fear, the fear to fail cause people to do crazy things instead of using their heads.

Other times, dates are set by the business, and instead of creating a realistic plan and focus on what is really needed, and leave nice to have for later, people just push to get everything done. Everybody lose focus of what are the important things, lot of time is spent on things which could be never used. You might end with a really nice splash screen, but it doesn't process any data because you couldn't finish the process part. It's very hard to say no we cannot do everything you want by the end date. You need to talk to the users and find out what will give them the most out of the application, and focus on those. This requires the development team to work closely to come up with a good idea on what has to be built or changed to solve the problem. Without good communication allowing the team to know what is needed and have them committed, it will be very hard to solve the problem. Fear of saying "no we can't", gets you in muddy place which will be hard to come out, and harder as more time goes by and you remain silent.Event if you are doing an agile methodology, if you don't speak up, nothing changes, you are in the same place as before.


Fear to Testing and Test Driven Development. Many people claim to be test infected once they started doing it. Unfortunately not everybody has been in touch with Testing and TDD to get infected. So telling a guy who has been doing development for years and years you have to do TDD and write Unit Tests for all the new code, will cause as much fear as telling a guy who does TDD not to write any test for his code. Specially if your are always on the run on your projects dealing with a long list of issues and tight deadlines.

Also, when you are on your introspective meeting, many people is afraid to talk about problems they see. e.g: Rob never run his tests before committing his code to the repository breaking CI build. Or the specs and details we get from the initial discussions with Peter have nothing to do with all things we had to do during the iteration making it take more time just because he didn't think of this before. We are not getting enough training.  There are always things to improve and fear giving feedback, won't let you get better. You should encourage people to give feedback to their peers, and at the same time not making it personal.

So changing the way people is used to do things causes many fears, it takes courage and training to overcome them. Why it takes courage and training? you might ask. I think it takes courage to put your self in a path to the unknown, and it takes training, to make things known.

Many big companies lack of both, they don't give any training and they do not have people with the courage to deal with many others frighten to change. I think those places could be really hard to implement an Agile methodology. I think if your are in those cases, you should aim to build a special team, probably with people from outside with experience in Agile projects, and start adding the people that has already been in the company, specially the referents in different projects. Once you took fear out of them and they are comfortable with agile methodology, TDD, testing, CI, etc., you can start building more teams.

I've seen the slow and gradual change of existing teams and processes is too hard and almost impossible if team members are not convinced of the change. They always end in a crazy intermediate approach. They claim they are doing "agile" but they just ignore many agile principles. Those intermediate approaches should be based on the agile principles to consider agile. Also, if there is no powerful sponsor, the team will be trying things and taking the risk of failing on their own. Fear will beat them as soon as they start running into issues as they get into too many unknowns, and they will just fall back to the same way of working as before.

I would ask, why are people afraid to change would use an agile methodology? I think if you are not changing for better, you are changing for worst, and specially on IT, where everything else changes so fast.