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

I Congratulate You on the Failure

I Congratulate You on the Failure

Have you heard about the saying – celebrate your failures?
Perhaps we should have. We are supposed to learn from the failures. However, the first feeling when something goes wrong is not really an adorable desire to celebrate. It is rather embarrassment, shame and eventually frustration.

Aubrey C. Daniels, the author of the book – “Performance Management: Changing Behaviors that drive Organizational Effectiveness” would describe the situation of blame and embarrassment as: “get something you don’t want” which is called punishment. I believe that most of us experienced it in our working life. Punishment is further described as a consequence that decreases the behavior. Please check the Empirical People Control post!

We may think and act, as a vast of organizations usually do, that punishment is good (“now you learned the lesson“) so the rules attached to the direct consequences are created – similar to the court laws.

An interesting story I’ve heard from my colleague was about such a case in his company. During the evening hours he received a call about an emergency situation happening to one of the company’s most important customers, operating in the neighboring city. He started to support the operational personnel remotely over the cell phone, but it was not getting any better, so he was asked to urgently come to the site. While still on the phone, he asked his wife to call a taxi for him, since his car was damaged in the accident that morning. Taxi would be the fastest way to get there. Very soon he was heading towards customer premises still providing help guys over the cell phone. The failure in one of the communication modules caused some data loss and a very upset customer. It took him several hours to bring back the majority of data, establish all connections and stabilize the system. It was early morning when he just went straight to the office. He made an incident report and proposed the immediate SW patch to prevent similar cases in other places. Good work, highly appreciated by his boss.
Case closed!? – Well, almost.
He has submitted the report with night hour’s work with attached transportation expenses. Few days after, his report was rejected by the finance department, since he has used the taxi company that was not an approved partner – a very clearly defined policy on the company’s web… Neither he nor his boss after lengthy discussions and a big hassle could convince finances that transportation costs are justified and need to be refunded. The consequence of the “wrong” behavior in the case of company’s directive violation was clear and immediate. Everybody in the company should use the approved taxi partner, also my good colleague. It is just that he now turns his cell phone off as soon as he reaches the front door of his house…

The fear from the failure prevents great things to happen, decreases initiatives to experiment, to innovate and finally to improve.
I am sure we don’t want that.



As leaders we should use positive reinforcement to increase behaviors that add and stimulate a creation of business value, rather than rigidly applying general rules and directives.

Environment that is not tolerant to failures, results in intimidation and blame which decrease creativity and innovation. So, let’s control failures with experimental approach, reflecting and learning from them.

One of the biggest failures is to miss to learn from a failure – I guess everybody heard about that…