"I'm getting too old for this shit."
(lieutenant Roger Martaugh: Lethal Weapon)

Self-organizing Team - the Last Unicorn

Autonomous and self-organizing team is the basic rock of the agile framework. But sometimes it seems to me that it is too vague and has nothing to do with reality.  Even better, it is the matter of desired goal – “to become autonomous and self-organizing”. It is definitely not the matter of beginnings, when team is like a bunch of chaotic electrons and protons and project manager is like a “daddy”, who distributes tasks and says what to do & how to do it. Developers are sleeping in their comfort zone and for them project manager is like a soft pillow who takes all the responsibility.  Ok, maybe not a pillow, but an air bag that will amortize every disturbance.

I believe that not every team has the ability to take a responsibility of being autonomous and self-organizing and often need an intervention from the outside in the deus ex machine style. It is good when sometimes project manager push the button and decides about team internal structure and roles.  It takes time to understand that the team itself, not the manager, has a power to change something. And this way, step by step, team is changing, re-allocate its roles and structure. And all that without project manager assistance.

But I must say, autonomous and self-organizing team is still a vague ideal from agile books. Because, in the reality, making a good team is like never ending process of repeating failures and successes. An autonomous and self-organizing team is much more connected with fairy tales character like last unicorn - everyone knows it exists but nobody ever have seen it.

Development team is like a boat which sails “under the permanent construction” in the open sea.  

Knowledge sharing? Storytelling!

Knowledge sharing is a tricky thing. On the one hand we can share knowledge about general rules or framework of particular topic. It is always boring and banal, waste of time. There are books, google and Wikipedia. We can learn from it and we can do it very effectively.

On the other hand knowledge sharing is a risky step. You can share your personal experience, things you’ve done and do it in a good way, or in a bad way. This is a limitless source of incredible knowledge. But you will always get to the point, where you will be forced to explain relations in your team, because every software project has a breaking point, ancient drama of crisis, where people argue and struggle with each other in order to decide, which way they should go or what to do. It is also risky because sharing knowledge can, accidentally, open Pandora’s box. You can never know, if people presented in your story will be so enthusiastic about revealing details about the team that maybe should stay unrevealed. There is also always politics behind.

People don’t tell their stories for those reasons and they just share lifeless and shallow “knowledge”.  

But it’s those personal details that are so rare and precious. Storytelling is the source and juice of life and project management: you will never learn from books or google. As a project manager or a scrum master you often have just one shot, there is no place for trying. You are working with people and every mistake can make harm to team spirit and leave scars on it. When you tell your story this way, your audience should be able to recognize your honest interest and this way they will not abuse your fragile position of storyteller. 

Creativity Meets Criticism

In my previous life – as a literary critic – I was a witness of common situation: in the capital city literary life was divided into several literary groups. There were writers, literary critics, dramatists etc. They discussed each other in such particular group. They supported each other and in the end they were giving prices to each other. There were however no communication between particular groups. Writers, literary critics, dramatists seemed to ignored each other, they fought each other on the pages of their own magazines. The only communication that happened was gossip. Polish vocabulary has a phrase for that, it’s:  “towarzystwo wzajemnej adoracji” (mutual admiration society).

Cracov startup scene with fancy hashtag and hand on hand agile scene is very similar. People are giving compliments to each other and in the same time they have a very aggressive respond to any sign of criticism from the outside. If it’s some kind of sophisticated marketing activity to promote theirselves or  to recruit young programmers, then ok.

But if it’s an attempt to establish a creative space, then I don’t buy it. 

I still stick to the naive hope that things are not as bad as they look, because it would be my loss to not be able to follow the steps of so many talented people in Cracow.

Message In The Bottle

I am writing this blog in English in spite the fact my English is pretty poor. And not only my English. But also my Polish and Czech, even my native Slovak!  Despite my language disability I still hope that the content is what is important. I’m not ashamed of my English, but I definitely don’t want to be ashamed of my thoughts. Cliché, written in perfect oxford English, is still only cliché.


I’ ve learned all about scrum from Tomek Włodarek. Thanks to him I could become a scrum master. Two days with Tomek were in fact much more valualbe than certificate itself. Tomek’s teaching style is Sokrates like, he ask questions all the time. His efford did not dissolved into thin air. It took just a few months and now I am working as PM in ISDC ABB. It turned out that issused explained by Tomek with such a simlicity and elegance are much more challenging in practice. 

Poor Task Estimation

Many poor task estimations are the consequence of the programmer fear that his estimations are too long. There are clients on one side and product owner and other stockholders on the other. They create atmosphere of skepticism and distrust. They suspect and expect that things could go faster (read cheaper). In this atmosphere the programmer feels guilty for he thinks that his estimation are too long. With this consciousness he estimates the time needed to complete the task and his estimations are too short.  He works via wrong schedule, he doesn’t have enough time and – as a consequence – his code and all the work are very weak. Everybody, both client and the product owner are disappointed and they blame the programmer.

In my opinion there is room for scrum master, who must educate both client and product owner that good work can take a while. Scrum master is also responsible for the atmosphere of trust and believe. In fact, he must create it. Only on these circumstances one can generate a perfect code and make a good work. 99% of the developers want to work, write code and improve their skills. There is, of course, 1% of the developers, one can call them “black sheeps”, who will always exploit your trust and openness, but it is just the matter of quick identification.

Summarize: many project are going down not because of the programmer weakskills, but because of the weak task estimation, because there was no time todo thing properly. 

Build atmosphere of trust and believe and work ahead! Identify “black sheep” quickly! Educate client and stockholders and explain, that quick work mostly means weak code!