On January 17th, 2008, BA flight 38 approached landing at London Heathrow airport. During its final approach one of the engines stopped. Shortly after, the second engine stopped too. At the moment when the pilots needed to increase thrust for their final approach towards the runway, the huge flying metal object became a weight dropping from the sky. The plain crashed about 300 metres from the runway. Miraculously only 47 people were injured (the worst injury was a broken limb) and there were no fatalities. As in any flight incident, the crash was investigated, and possible reasons were eliminated one by one. Pilots fuel operation fault, shortage of fuel, fuel pipes blockage - all were overruled. Finally investigators had one last hypothesis: when flying over the arctic, a fairly new route at the time, fuel flow was blocked due to humidity in the fuel freezing into ice crystals. They had no proof, since by the time of the crash all ice was melted. But this was their best bet. 

Although this is not the typical topic in a software team retrospective, the way airlines and aircraft makers handle incidents is indeed relevant for us. 

Add a comment

Who cares? I do! Why?

First,  because it offers an opportunity for a blog post (that increase social media presence, etc.… J), second because some of you are using those words in a wrong way which leads to wrong decisions being made which leads to pain and suffering (more commonly known as poor performance). 

I am not trying to find right or wrong answers, or which is better, my aim is just to clarify meaning. Let's create some order in this confusion.

Add a comment

“Your main goal for this quarter is Agile”, said Jane, the VP R&D during the performance review, “you do know what is Agile, right?”

Bob didn’t know what Agile is. That is, he knew what the word agile means, but not in the context of his job as a director of software development at Slough Comm, a maker of telecommunications equipment.

“Yes, of course. We will do Agile in 3 months”.

“No, don’t do Agile. Be… never mind. I’m sure you’ll figure it out. Just talk to me whenever you need help, and let’s stay updated on this every two weeks in our status meeting”.

Add a comment

Last week, my colleague, Ilan Kirschenbaum, and one of my agile mentors, published in his blog post “Recipe for becoming a scrum master”.
I really related to his post, because it is actually tracing the steps I went through on the way to become an agile coach (and I continue repeating those steps every day, this blog post is an evidence :)).
Still, I have something to add - some base assumptions I have embraced during the way, which I think worth sharing.
A moment of honesty, the idea for this post came up during NLP lesson, I have recently started. The following base assumptions are also the foundation for the NLP, so I (or we) did not invent anything new here - it is just perfectly blended into being agile. 


So, let’s begin with the first one, and for me, it was also the hardest one to acknowledge and embrace.

First assumption:

Everyone is doing the best they can (with the resources they have available)

Add a comment