Impediment Is My Middle Name

ImpedimentDepending on how far our agile transformation went, different impediments could be faced. Impediment is the state of moderate anxiousness when encountering the obstacle on the way to reach a certain goal.

To my view, impediments can be divided into:

  •        temporary problems (often due to an  improper risk handling)
  •        structural impediments (could be the same reason as above, but (un)knowledge is in the background)


As a child, Impediment was called Risk. If we don’t take care of our children, raise them properly, give them guidelines and education, there is a fairly substantial chance that they turn out into problems. The exact moment when Risk becomes Impediment actually does not exist. It rather goes through the ‘puberty’ phase, a sensitive path, were still a chance to act exists, but rapid development narrows down the maneuver space. So, it is much better to shape risks before this phase.

The success and perception of the organizational transformation will be important for people and teams.If leaders help out to resolve impediments on their way that would contribute to the credibility of incoming changes. Our experience has shown a small number of impediments coming from the teams. Either they were solved by each of the team itself or they were not recognized as such. We believe it’s a mixture. Leaders (together with the team leaders) are there to help teams both to prevent and to recognize impediments.

If an impediment comes suddenly, it means (with some exceptions) that the problem of seeing and managing risks exists. Seeing the risk is a skill and requires system thinking as well as experience (that usually project managers did – please see the post about project managers). Structural impediments are the subjects of our leadership strategy, the main points of our transformation efforts and a vision where to drive the whole organization (even it may sound odd).

Concrete axample: after several years of agile transition and taking Scrum as the main development framework for developing SW, on our leadership team’s impediment board was written:

True deployment of Scrum

It took as long time to hang it there and it stayed hanged for a long time. Why? – Because, if the cultural mindset of the company is to perform, to execute or, to be a bit drastic, only deliver on time, we are convicted to the double change as we go:

  •        Fulfill the existing requirements of the current processes, policies, rules, targets, reports… so we need to make “adapters” towards them to find a place for new practices
  •        Adopt and apply new practices and thinking patterns in the part of the organization we are possible to influence

We progress gradually with the last depending on the former, but also in accordance to the ability to learn and change. If our vision of Scrum deployment is wanted “by the book” with the right SW engineering practices fitting the best our transition moment, we were not there – we had a structural impediment!

Looking deeper, it was indicative that an adequate coaching (or coaches) was missing to deploy Scrum, which was another structural impediment – actually a cause. We were lacking a systematic agile coaching.

This was great! Understanding that the problem exists is a half of the solution! The other half is then left to Mr. Kaizen – continuous work  (see the post) to improve and resolve the issues.



We should learn to see impediments and opportunities to improve in our daily work by regularly and as frequent as possible investing time to think about impediments.

When we visualize impediments, there is an increased possibility for their faster resolution, i.e. a better progress of transformation. Please see also Agile Transition and Transformation post!

I Congratulate You on the Failure

failure-and-successHave 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…