Assuming Agile

If I would be granted a wish, I would choose to be freed from making assumptions and easy judgments (and maybe sometimes to shut up and listen).
The general assumption when starting with Agile is that it will solve the problems of speed, quality, eficciency… and it will boost performance by itself. It continues further by thinking that agile practices will make a perfect code, or that people will accept Agile as a natural way of thinking and doing business. Even further, we can say that the usual assumption is that daily meetings, visual (task) boards, backlog and small iterations make us agile. It will help, but it goes fairly beyond that. This assumptions lead towards many disappointments and stopping agile transformations. You may take a look at the transformation curve in the section about culture.
Once, I had lunch with colleagues from other company. Discussing the agile SW development, one of them said: “I have very low opinion about people doing Agile. I don’t know you, so I cannot tell.” He actually never tried agile practices and learned about the principles behind them. His (strong) statement was probably based on some previous observations, creating the assumption that the ‘agile gang’ actually escapes from doing the ‘real work’. It imprinted in his mind, so in general he was against Agile. Such an attitude prevented him to see the value that could possibly derive from it and it fairly blocked his need to learn about it.

Not making conclusions based on unconfirmed assumptions is a skill. It requires practice and an open approach with a fair dose of humbleness. Assuming agility will happen without learning and hard work is like swimming towards a distant shore without moving hands and legs.

You may take a look about 10 common fails with agile from TaskWorld:

Top 10 Agile Fails #infographic