Natural Course of Refactoring online on InfoQ

I am so delighted that article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before so please retweet it and share it wherever you can.

Fruitful reading!

Read More

Unknown 14:34  2 comments

(Polish) Nie daj się konfliktom

.

Intro

Kiedyś na rozmowie rekrutacyjnej kandydat na lidera zespołu stwierdził, że udaje mu się pełnić swoją rolę bez konfliktów. To wyznanie budzi podejrzenia. Brak konfliktów, to symptom, który wymaga szczególnej uwagi. Życie projektowe jest pełne konfliktów i należy im pozwolić zaistnieć, aby w efekcie móc znaleźć rozwiązanie, które będzie satysfakcjonować obydwie strony. 

Pewna historia

Jakiś czas temu miałem okazję pracować z firmą, w której kierownicy projektów nie dogadywali się z zespołem programistów. Sytuacja nawarstwiała się przez wiele miesięcy aż przyszedł taki moment, kiedy niemal każde spotkanie kończyło się nerwową wymianą zdań i brakiem rzeczowych ustaleń. Zespół techniczny narzekał na zbyt dużą ilość dokumentacji, którą musiał tworzyć, gdy tymczasem kierownicy chcieli jej jeszcze więcej. Programiści chcieli więcej czasu na refaktoryzację, kierownicy chcieli, aby cały czas był w pełni poświęcany na rozwój funkcjonalności. Zespół techniczny narzekał na brak jakiejkolwiek wiedzy technicznej wśród kierowników projektów.

Moim zadaniem było znalezienie rozwiązania przedstawionych problemów. Zaprosiłem na spotkanie przedstawicieli obu stron i poprosiliśmy o przedstawienie argumentów. Kiedy tylko jedna strona zaczynała przedstawiać swoje racje, druga natychmiast ripostowała i dyskusja przeradzała się w kłótnię. Po bardzo żmudnej i długiej pracy udało się wypracować jakieś rozwiązanie, ale było ono dalekie od ideału. Nie byliśmy z niego w pełni zadowoleni.

Tak się dzieje zazwyczaj wtedy kiedy w przypadku konfliktu, obie strony próbują racjonalnie przekonać siebie nawzajem. Problem tkwi w tym, że przedstawiają argumenty ze swojego punktu widzenia, które zazwyczaj nie docierają do drugiej strony. W większości przypadków doprowadza to do kłótni, ewentualnie tylko jedna ze stron wygrywa, a w najlepszym przypadku dochodzi do kompromisu.

Kluczem do sukcesu jest zasada, iż „konfliktu nie można rozwiązać na poziomie, na którym powstał”. Trzeba rozwiązania szukać na wyższym poziomie. A co to znaczy?

Prosty przykład

Załóżmy, że pewna para mieszkająca razem, chce pomalować pokój. On chce pomalować go na niebiesko a ona na biało. Co w takim przypadku? Mogą wypracować kompromis – dwie ściany niebieskie a dwie białe. Pewnie żadne z nich do końca nie będzie zadowolone. Niektórzy mówią, że w takich sytuacjach zawsze kończy się rozwiązaniem zaproponowanym przez kobietę. My będziemy bardziej ambitni. Spróbujmy zadać pytanie: dlaczego to jest dla ciebie ważne?

On: Ja chciałbym pomalować pokój na niebiesko.

Ona: Grrrr… a ja na biało.

Mediator: Dlaczego to jest ważne dla ciebie, aby pomalować pokój na niebiesko?

On: Bo nie chcę mieszkać w szpitalu. (Nie chce białego).

Mediator: A ty dlaczego chcesz pomalować na biało?

Ona: Bo chciałabym mieć pokój w jasnych kolorach.

Mediator: Jeśli ty nie chcesz białego, a ty chcesz jasny. To może – różowy?

On: Nie lubię różowego. Tak samo jak białego.

Mediator: To może inny jasny kolor? Jasny fiolet?

Ona: OK

On: Dobra, niech będzie.

W przypadku konfliktów – nie ma poprawnych odpowiedzi. Dobra jest taka, która dla obu stron jest satysfakcjonująca. Jeśli na końcu jest zgoda, to znaczy, że udało się rozwiązać konflikt.

To co zostało przedstawione za pomocą powyższego dialogu, możemy przestawić za pomocą następującego schematu:

Większość konfliktów opiera się na tym, iż każda ze stron ma określone stanowisko w zadanym temacie. To stanowisko to stwierdzenie: chcę X, rozwiązanie Y będzie najlepsze. 

Żeby rozwiązać konflikt poszukujemy intencji lub potrzeby, która stoi za stanowiskiem, do czego prowadzi wariacja pytania „Dlaczego to jest dla ciebie ważne?”. Jeśli dotrzemy do intencji, która zazwyczaj jest bardziej ogólna, jest sformułowana na wyższym poziomie abstrakcji, to mamy większą przestrzeń do poszukiwania potencjalnych rozwiązań, które będą satysfakcjonować obie strony.

Nasz schemat uzupełnijmy o elementy struktury (zaznaczenie stanowisk oraz potrzeb i intencji):

Struktura

Sama struktura rozwiązywania konfliktu wygląda następująco:

Kilka uwag praktycznych:

•   może się okazać, że czasami trzeba zadać kilka razy pytanie o intencję, aby móc znaleźć rozwiązanie;
•  w przypadku konfliktów między różnymi zespołami czy działami, można się posłużyć wartościami organizacji (które są forma intencji);
•  potrzeby i intencje są subiektywne i nie należy ich oceniać w jakikolwiek sposób, szczególnie w kategoriach prawidłowe-nieprawidłowe;
•  obie strony muszą mieć chęć znalezienia rozwiązania, również takiego, które może się różnić od początkowo przedstawionego;
•  czasami intencje mogą po obu stronach wydawać się podobne, wtedy warto je skonkretyzować (np. jeśli intencją jest wysoka jakość kodu, zadaj pytanie: co konkretnie oznacza dla ciebie jakość kodu).

Przykładowe pytania

Poniżej znajdziesz przykładowe pytania, które możesz zadać w celu poszukiwania intencji:

•      Dlaczego to jest dla ciebie ważne?
•      Czego potrzebujesz w tej sytuacji?
•     Jak jest twoja intencja?

Algorytm

Algorytm rozwiązywania konfliktów przedstawia się następująco:

1.  Upewnij się, że uczestnicy rozmowy chcą znaleźć rozwiązanie, które będzie satysfakcjonować wszystkie strony.
2. Przedstaw strukturę rozwiązywania konfliktów i uzyskaj zgodę na jej zastosowanie.
3. Rozpocznij od sprecyzowania stanowisk.
4. Dla każdego ze stanowisk poszukaj intencji lub potrzeby.
5. Na bazie intencji lub potrzeb obu stron poszukaj innego rozwiązania.
6. Jeśli nowe rozwiązanie nie jest satysfakcjonujące, dowiedz się dlaczego i na nowo zdefiniuj intencję (lub potrzebę). Wróć punktu 5.

Przykład

Kierownicy projektu nie mają nawet minimalnej wiedzy technicznej

Konflikt dotyczy sytuacji, w której programiści (P) wystosowali zarzut, iż kierownicy projektów (KP) nie mają nawet minimalnej wiedzy technicznej. Mediator (M).

P: Nie macie żadnej wiedzy technicznej!

KP: Nie jesteśmy od tego, aby znać się na szczegółach technicznych.

M: (do programistów) Dlaczego to jest dla Was ważne?

P: Gdyby bardziej się orientowali w technikaliach, to łatwiej byłoby rozmawiać o wymaganiach i ich konsekwencjach.

M: Co dzięki temu będzie możliwe?

P:  Będzie łatwiej rozmawiać o tym, jakie rozwiązanie będzie najlepiej wybrać.

M: A czy potrzebujecie, aby kierownicy mieli głęboką wiedzę techniczną?

P: Nie. Ważne jest to, żeby mieli pewną orientację w temacie.

M: (do kierowników) Dlaczego nie ma dla was sensu, aby znać się na szczegółach technicznych? Co wtedy możecie robić w zamian?

KP: Nie musząc znać i angażować się w szczegóły techniczne, mamy więcej czasu, aby ogarniać projekt i wspierać wszystkie działania, które mają doprowadzić jest do celu?

M: Czy dobrze słyszę, że kluczowe jest dla was do, aby projekt zakończył się powodzeniem?

KP: No tak.

M: Chciałbym podsumować. Dla was (do programistów) ważne jest to, aby kierownicy mieli orientacyjną wiedzę techniczną, aby można było łatwiej decydować o najbardziej korzystnych rozwiązaniach?

P: Zgadza się.

M: A dla was (do kierowników) ważne jest to, że nie wchodzić w szczegóły techniczne, ale jednocześnie wspierać swoimi działaniami powodzenie projektu?

KP: Tak, żeby nie wchodzić w szczegóły, ale móc wspierać.

M: Co można zrobić, żeby spełnić jedną i drugą potrzebę?

KP: Może jesteśmy w stanie nabyć jakąś minimalną wiedzę niedużym kosztem? Może jakiś bardziej biznesowy programista przygotowałby miniszkolenie w tym temacie?

P: Ma sens. Można spróbować.

Myślę, że nie mieliście problemu, aby odnaleźć elementy struktury rozwiązywania konfliktów w tych dialogach. Dla jasności została ona przedstawiona poniżej:

Ćwiczenie

Praktyka jest matką wszelkich umiejętności. Mamy dla ciebie ćwiczenie.

Znajdź aktualną sytuację konfliktową, która dotyczy cię bezpośrednio. Sprecyzuj stanowiska. Znajdź dla nich intencje oraz potencjalne rozwiązanie, używając struktury rozwiązywania konfliktów.

Gdzie jeszcze?

Najbardziej bezpośrednie zastosowanie tego schematu to konflikty personalne – w zespole, między zespołami, między konkretnymi osobami. A w jakich sytuacjach jeszcze można użyć tej struktury:

·         w przypadku ustalania reguł zespołowych;

·         w przypadku wybieranie jednego z dwóch rozwiązań technicznych;

·         w przypadku dyskusji o wymaganiach z klientem.

Zatem do dzieła! Czyńmy świat piękniejszym :)

Read More

Unknown 17:11  1 comment

Agile Prague 2014 notes

.

It's been almost a week since Agile Prague finished. It was a great time of interesting discussions and meetings. I have had a privilege to talk with Linda Rising about patterns, their history and current state (still under development). She also gave wonderful talks about Agile mindset and trust.

It was also a pleasure to discuss with Paul Klipp and take part in his talk about communication - the subject I am always interested in.

Another two interesting subject I listened to were ones presented by:

• Vasco Duarte - about NoEstimates approach, which in my opinion is not exactely about not doing estimation, but to extremeley simplify the way you do it. In short: estimate an item with 1 point. If it is too big (should be more than 1), split it.
• Louis Goncalves - about getting rid of performance appraisals.

I have also a privilege to give my talk about Natural Course of Refactoring. You can find slides here.

I had a very nice and positive feedback.

See you soon at Warsjawa.

Read More

Unknown 11:36  No comment

JDD, Warsjawa, Agile Prague and Cambridge Agile conferences

Vacation time is over and it is time to start to hard work :) I have a privilege to speak at 3 conferences so if you would like to meet me and talk, don't hesitate - join the conferences as soon as possible.

 My first talk will be about refactoring and concept of Natural Course of Refactoring in Prague on 16th September. There is a big chance that I will show more advanced example with many tricky and non-trivial transformation.
More details about the event can be found at http://touchmyconference.com/AP2014/#sessions

 The second activity will be a workshop on Soft Skill for Tech guy in Cambridge on 2nd October. So if you want to learn how to use very useful model to handle conflicts just come.
More details about the event can be found at http://agilecambridge.net/ac2014/programme/ 

In addition to that I will be talking at great Polish conference in Cracow called JDD that I have been with for ages (from the beginning). The talks will be held in Polish. The first one will be "How your code speaks to you" and the second one with Michał Bartyzel about "Strategic refactoring".
More details about the event can be found at http://14.jdd.org.pl/.

Ohh... I forgot. Warsjawa! Yes. There will be great opportunity to put hand on keyboard and repair legacy code during "Working with legacy code" workshop.
More details about the event you can find here http://warsjawa.pl/

Ouch! Now I realized that it will be very busy time :)

Read More

Unknown 06:59  No comment

Time for non-violent rebel

 

Agile thinking has been with us for several years. There is a lot of humanity behind Agile thinking and this is what is great about it. But Agile like every idea is just the idea. Not easily applicable in life and many times distorted to be convenient (and not necessarily useful). People focus on practices and loose the spirit of the idea. Agile is just an example. All in all the problem is deficit of humanity in business context.

The deficit of humanity is driven by profit maximising what leads to short term optimisation. In consequence leaders face goals that are profit oriented (expressed in strict timeframes, number of features, low budget). And these forces make them afraid. And they try to force team members to achieve this profit oriented goal. It creates a lot of pressure and there is very little space for humanity.

What makes the problem bigger leaders (especially Technical ones) don't know how to deal with so called  difficult situation, when someone doesn't agree, someone complains about something not forcing them to do something and be effective at the same time. It is big challenge for them to give away the power to people. Many of them declare it, but very few really do it.

And it is time to rebel! It is time for non-violent rebel. It is time to clear the misunderstanding that you can only fight in style "An eye for an eye, a tooth for a tooth" in order to change anything. It is time to see that you can be honest and take care of your needs and at the same time be in connection with other people in your team and outside your team so that you can look for ways to help them satisfy their needs... without violence. It time to settle the humanity in world of business.

Will that be easy? I want to be honest. No. I has its price. Is this possible? Yes. It will require a lot of work but very satisfying work.

If you want to look for your own just google for "non-violent communication". If you are patient or want to see NVC in IT world just come here from time to time.

Read More

Unknown 11:42  No comment

How to be productive

I have recently came across this beautiful infographics from +Anna Vital

I have been a productivity fun for ages but my approach evolved through time and it's time to make some kind of summary here.
When I look at elements in this great mindmap, I recognize almost all of them. Most of them I have tried and many of them I use. But now I look differently at such things than 10 years ago. Those days it was just a bundle of handful hints that I read from time to time and they didn't mean much to me. Just like all those fancy "good practices" that everybody knows and very few does. It was a time when I was hungry for fast solution - easy 10 points that would change my life. And they didn't of course. Because important changes require time. They require patience and perseverance and it's less and less common nowadays.
It took me almost a year to recognize how can I manage my anxiety doing workouts (runnings) with all those nuances that can be helpful to do it effectively. And believe me I am a smart guy, so the stupidity was not the reason of a timeframe.
I spent almost a year to REALLY experience what it means to focus on important things and suppressing urgent. What isn't done in most organizations although they all declare it. Because it is not easy to tell your customer with courage in heart "We will not do it under that conditions, in that timeframe".
I took me couple of months to start making conscious decisions about healthy food, understand and feel consequences.
I took me at least ten tries before I gave up being in touch with the news.
I took me TEN year before I really understood and experienced that lack of sleep is disastrous and in contradiction to productivity at all.
And so on and so on. All that stuff because knowledge not practiced is just a noise.

After those ten years I realised that the most important thing is to slow down and give yourself time. Important changes require time and you cannot do them in fast track mode. Many books and trainers promise us fast results but remember it is just marketing.

I remember that 10 years ago I loved such lists like the one above, because as a tech guy I liked to have short lists with most important information. So then I read them but nothing lasted in my head.

They are great as a reminder if you practice all this staff, but not much helpful to really use it as a daily routine when you start. Then you need at least a book on each subject or better go to training, and after that time practice it for months. Then you will succeed.

There is one thing when you have a deep understanding of a rule after long time of practicing: you don't need that rule at all, then you have it built in and you strictly know when to apply it and when to broke it. But it comes with time. No shortcuts.

Last thing is obsession with productivity but we have to remember that productivity is in opposite to creativity (http://lifehacker.com/5918138/is-productivity-killing-your-creativity). As a knowledge worker you cannot be 100% productive otherwise you just become a reflectionless robot.

Read More

Unknown 12:22  3 comments

Is Poland Christ of nations?

I have recently came across a very interesting article about pitfalls of Polish style of management and its historical roots. It is more generic than just IT but it includes so called participatory management (eg. Agile). If you understand Polish language you can read an article here http://biznes.gazetaprawna.pl/artykuly/801950,kapitalizm-po-polsku-folwark-ma-sie-dobrze.html

For other guys here are the main points from article (just a few):

• Current polish mentality comes from historical circumstances - starting from XVI century Poland was mostly a food supporter for countries in western parts of Europe and it had a great impact on internal relashionship between layers of Polish society (master - slave relationship between "big" owners and single farmers (villein?))

• A farm mentality was focused mostly on surviving what wasn't enough when capitalism became a mainstream where the profit is the most important goal of the organization.

• The master - slave relationship leads to compliance but sacrifice creativity which is crucial in capitalism.
• Most polish companies even international corporations locally fall into this schema. In western divisions vision, mission, people and values are respected but in Poland it goes down to that master slave mentality. Top managers are masters and all guys "below" have to be obedient otherwise they are punished. No chance for participatory management (me: Agile for example). People in such an environment don't take full responsibility for their work. The opposite is Scandinavia for example.

I find similarities in such master-slave mentality also in other  Central European countries (Czech Rep., Hungary, Ukraine, Lithuania etc.).

I love such articles because they always broaden my perspective and understanding of a surrounding reality. But I am also very cautions because it is very easy to abuse the history, consequences of different historical circumstances because it is more complex than simple or complicated. So here is my point of view that comes from my personal experience (and dealing with different, mostly Polish companies).

Based on the article we could draw the conclusion that Agile mentality is not much compatible with Polish master-slave mentality. And this is what I can see quite common especially in big companies (corporations) that their flavour of agile is not so agile. But also smaller companies are no better in this case. I have seen just a few companies that fully employed Agile mentality.

But on the other hand I wonder whether it is only Polish problem. Our industry is very international, it is almost global industry and we know that the master-slave mentality is quite common also in other countries (called command-and-control way of management) and it is also very difficult to transform that mentality to Agile. So it is difficult also in US, UK, France and other countries. What differs these countries from Poland is that it may be a little bit easier to do Agile transformation (what doesn't mean it is simple). There is a little more openness and trust in people in Scandinavia, France, UK than in Poland.

What also comes to my mind is Nonviolent Communication movement that tries to provide an alternative to so called violent communication (when there is an assumption that somebody is right and the other is not correlated with master-slave mentality and that we were trained to be correct in social terms but not authentical and it is source of violence) and it was invented in US not in Poland.

Therefore I wouldn't overvalue the hypothesis that this specific Polish historical background is crucial because described problems are not only Polish after all. I believe that it had an important influence on our  (Polish) mentality but there are many more social, historical, financial, anthropological processes that influenced the current situation. Maybe it makes a little bit more difficult to employ participatory management practices (like Agile) in Poland than is some western countries but we are not so special as it was described in the article.

I can see it in a different way. The XX century was the time when humanism started to grow (thinking that people are important) and it is one of the root causes of the movement from command-and-control to self-organizing management. Every country has its own history and background that strengthened the command-and-control thinking (force based). The story in the article might be a Polish story. Other countries have theirs. Some of them had stronger or weaker influence. And that's all about it.

On the other hand  in order to employ participatory management (ie. Agile) it really requires supporting mentality (like Japan Samurai mentality or  Scandinavian openness and trust) to make it easier.

(Poland As Christ of nations is a Polish cultural concept from XIX century that Poland is the chosen country to suffer for other nations; you can find more here http://en.wikipedia.org/wiki/Christ_of_Europe)

(image src: http://img.thesun.co.uk/aidemitlum/archive/01587/JESUS-620_1587358a.jpg)

Read More

Unknown 14:29  16 comments

Being busy is an easy way

I have had a great opportunity to take part in some kind of experiment. I consciously got rid of most tasks from my personal and professional life that I considered not be fully joyful and purposeful. What I expected was that I would be more focused on things that really matter to me and I could consciously choose what to do (and what not to do).

I stopped checking my phone every 10 minutes, including Facebook, Endomondo and Twitter. I and Michal decided to strongly simplify the way our company works (including the employment decrease). I stopped to start new books (I used to start many and finish few). I stopped to obsessively do tasks from my TODO list. I stopped doing most stuff that everyone does. I focused on family, my core professional stuff and running. I have created a lot of space and time to think.

And you know what? It is hard. It is extremely hard. It is not easy to find out what is really worth doing. It is not easy to make decisions with full awareness. It is a big relief when sometimes I forgot about my experiment and start doing things compulsively. I don't have to think! Of course I am doing much thinking then, but it is about solving a particular problem. I more react to circumstances than I am aware of what I am doing. Like a drug. Doing anything is like a drug. You loose your conscious thinking and start compulsive, reactive thinking (which may require a lot of IQ).

Now I think I fully understood (or would be better to say "I internalized") that:
Doing anything, being busy is an easy way. Because (what is commonly known) it is extremely hard to do the right things. And it is really much harder to figure out which thing is right rather than do it. What I notice is that we are not taught to think this way and not used to it.

Being busy is a sickness of our times. It is motto of professional life. Most decisions are made because there are so many things to do and we have to react in some way. But these are not conscious decisions. These are reactive decisions and many time destructive ones.

(photo from: http://www.intervarsity.org/sites/default/files/uploaded/busy2.jpg)

Read More

Unknown 10:36  3 comments

Task-doing vs. responsibility taking - a subtle distinction

I have been reading a book on a fathership recently (yep, tech guys also read such books:-)) and there has been a discussion about responsibility. Even when fathers devote their time to spending time with children and doing some tasks related to children and family they may still don't take responsibility for it. So you can take your children to doctor when they are sick, bring them to school or kindergarten everyday, go with them to a playground... and still not taking responsibility.

How come?

Because responsibility is not about doing (at least in a first place), it is about having in mind what you are responsible for and taking care for it (ie. anticipate and respond to the situation).

Common! Fuzzy? A little bit :-)

Let's go back to the children example. You may go to doctor because your partner told you to do it ("Honey, I have an important meeting in the morning, please go with Kate to doctor"). This is just a task. If you accomplish it (or you can't for some reason - for example doctor is not available today), you are done. Now it is again your partner's worry. She still has to think about it. You have just done you task. To take responsibility is to think about the subject of responsibility (to have in mind) . Example: As a father I proactively think what to do when my child is sick (organize a medical appointment, a babysitter or go to a sick leave) and in longer term to remember about immunization, important dates etc. Then you can tell you take responsibility for your children's health. It is more about thinking and being aware than doing (which is also important after all).

Ok. But what does it have in common with my team? Many leaders want folks in team be responsible (and what is funny they are not able to define what it means).

In business context we very often use the word responsibility mostly in context of a task. "You are responsible for this task", what usually means: do it from the beginning to the end. But in such situations it is much like going with child to a doctor. It is task-doing and not responsibility-taking - for your team, process, product. Being responsible just for tasks makes folks passive, creates the illusion they have no impact on what is happening around you, that the "others" decide. And then they feel powerless and their work becomes boring. It takes juice of life out of you. Who likes it? Hands up!

What to do in real life:

• If you are a leader: Discuss with  your team what "responsibility" means. Create your own definition. It is unique because of your different expectations and past experiences.
• If you are a leader: Create environment where people can are encouraged to take responsibility (and not only for task-doing): let people estimate, let people choose task they do (according to priorities), let people influence the way they work (through retrospectives) etc.
• If you are a team member: Suggest such discussion in a team. Discuss difference between task-doing and responsibility taking and how it harms you.

To sum up let's define what responsibility means when applied to different "things":

• task responsibility - doing the task from the beginning to the end, anticipating problems and proactively looking for solutions when problems arise; it is situation when nobody else have to take care of the task (unless it is shared task);
• team, process responsibility - being aware of what is happening in the team/process and proactively looking for ways to improve the way it works (yep, in my opinion it is not only team leader job); look for ideas, improvements, experiments, insights, questions that can influence what is now;
• product responsibility - consciously, sometimes critically looking at a product evolution, look for ideas and express them (and it is not only your Product Owner's job).  

To clarify: take a context into account, because sometimes you may be just a small planet at the edge of Milky Way (let me emphasize: SOMETIMES).

(photo: https://drschiffman.files.wordpress.com/2012/04/responsibility.jpg)

Read More

Unknown 10:43  No comment

I'll be there (for you) ...

I am very excited and happy to announce that you can hear my talk at two Agile conferences in Europe:
Agilia Conference 2014 in Brno (I'll be speaking on 25th March)
http://agiliaconference.com/2014/en
and
Optional Conference 2014 in Budapest (I'll be speaking there on 8th April)
http://www.optionalconference.org/

I will be presenting talk titled:
Structured soft skills (not only) for Technical Leaders
You are not a born leader. You haven't been prepared to be one but you were chosen to be. And then everything changed. Now you should be a good communicator, negotiator, mediator, facilitator, motivator. You have heard that you should be a servant leader, should prefer collaboration over contract negotiation, people over processes but … you think: „What the heck should I exactly do?“ Most of the leadership hints are general, fuzzy and unstructured. If it sounds familiar to you, this is a talk for you.
We will talk about fundamental soft skills in a structured way. You will see a lot of schemas, diagrams, algorithms, dependencies you weren't aware of before. This way misty soft world will become familiar and easier to understand for left-brainers (people loving to think in an analytical way).
What we will talk about?

• How to resolve tough (conflict) situations.
• How to find a problem solution.
• How to conduct effective meetings in a way nobody told you about earlier.

Who will benefit from this?

• Technical leaders, team leaders, any other kind of leaders working dealing with software development.
• Leaders and all technical folks interested in developing their soft skills.
• Technical guys (developers, testers, ux designers) at least having clue that soft skills might be really important in their work.

-----

I am excited and a little bit stressed as these will be my first talks in English.

Keep your fingers crossed and come if you can.

Read More

Unknown 15:41  2 comments

... and what if you are just a small planet at the edge of Milky Way

I have talked recently with my colleague  about importance of domain expert availability in the project so that you can clarify the domain specific question.
- In most cases your work is more buggy and costly not having such a person available - I said.
- But what if the product is not so important in the context of the whole company (big insurance corpo for example)? And will be replaced by another project within two year. But it must maintained and developed for that time to keep business working in this area. Then business is not so eager to dedicate valuable domain expert for this case... And then the team is wandering looking for good domain answers but it is included in the cost.
- You might be right - I said.
(Of course I could have been convincing him that people may not be motivated or frustrated, but so what if the case is not that important for business and from business point of view there is no greater sense to get much involved.)

It may sound sad but be frankly speaking not everyone works on first class projects, the shining stars in the sky, where everybody is excited just thinking about it...
Then just do your work in a way you can be proud of (with as much craft as possible) or change your job.

(photo: http://horoscope.com.sg/wp-content/uploads/2013/01/shiningstar.jpg)

Read More

Unknown 10:39  2 comments

Building knowledge in a team. Main mistakes and strategies.

(This is translation from original Polish post)

For IT leaders the topic of knowledge management is no man’s land. There is a silent assumption that it happens on its own. Well, to some extent it’s true, because as software developers we are used to the fact that not to fall out of circulation in our field we have to learn new things all the time. But that’s not enough. It’s not enough if all the team members (in fact half of them) will get to know something on their own. If the team is to work efficiently, they need knowledge that is consistent and up-to-date. And in this case cutting-edge technologies skills have a small value only.

Therefore, dear leader, you need to know that it is important to be mindful in managing the development of your team’s knowledge. It is often treated as secondary aspect of the functioning of the team – or even ignored, since it is not coding, it is difficult to put it into schedule and people somehow do without it. Well, as the old saying goes, the devil’s in the detail and this “somehow” makes a big difference. Based on my experience, the best teams that I have ever met in my life had really well-developed methods of team knowledge management.

Why is it so important? Below you will find selected pathologies that really happen, and heuristics that usually work well:

• lack of architecture documentation – Yes… yes… Currently we are all Agile, so we don’t need any documentation. It’s high time to put these excuses aside. You DO need the documentation. Especially the high-level one. What I mean are the drawings which document the system from the bird’s eye view – context diagram/drawing, component diagram/drawing, architectural mantra, diagram/drawing with the main mechanisms that we developed (i.e. the frameworks). When you don’t have these documents, it is particularly difficult to talk about solutions, changes in the system or introduction of a new person, because we have no point of reference. Without it, how do we know that we are talking about the same thing? How do we know the structure of our system? Low-level documentation (sequence diagrams and diagrams of particular functionalities) is not very useful. This is rather a temporal type of documentation that we need for the development phase, so a simple ad hoc drawing on the board is perfectly enough;
  
  
• lack of strategy for introducing new hires – sometimes you have it, but it’s rarely done in a correct way. In most of the cases (assuming that you have one), the strategy boils down to providing the new person with a few days of chaotic introduction which is more about organizational matters (company procedures), environment configuration, repo, etc. And, perhaps, a couple of words about the system… “He/she’ll will find the rest in the code.” And what happens then? The new person gets to know the system based on its code. Instead of 2 weeks, it takes 3-4 months to (more or less) look around the system, its building blocks, the preferred solutions and the domain in which this system works. Yup! Getting to know the system on your own is several times longer than mentoring provided by a selected team member. “Well…., but someone has to spend time on it instead of coding.”
  
  At this point leaders/managers unconsciously use local optimization, which means that they want to use the new person ASAP. But it’s no use, because for the first months such a person is inefficient.
  
  Apart from the strategy to introduce new people (i.e. a 2-3 week plan that specifies what, when and who should teach the newcomer), you need to complete the previous point, that is the high-level documentation which will shorten the time needed for mentoring. BUT it is important not to treat it as a document to be read (“There you go, just read it.”), but as a tool and a starting point for the discussion with the mentor. The document itself – regardless of how well written it is – is of no use;
  
  
• people do not know the code/the system – this problem is a direct consequence of the previously mentioned two problems. Due to the fact that people don’t know the system very well or their knowledge is rather peacemeal, they waste their time on searching and other people’s time on answering their questions. Apart from that they have to learn as they code and many times copy the solutions they find – not even knowing if they are desired or not;
  
  
• lack of consistent rules – currently the shared coding standard has in fact become (nomen omen) the standard, but it’s not enough. Because of the fact that there are many other factors that influence code readability or cleanness of the architecture which should be shared – consider, for example, clean coding rules, implementation patterns used and building blocks (architectural mantra). If you haven’t set that and you don’t monitor it, it leads to the erosion of the architecture caused by application of inconsistent solutions. At first you might not notice it at all, but over time, with the development of the project, you start to struggle with the snowball effect;

• lack of exchange of knowledge in the team/between the teams – it often happens that you neither have money nor time for trainings, but I have the impression that leaders/managers do not appreciate the most valuable tool that they have – the knowledge and experience their people gained in their project. Can you think of any better source of knowledge that is tailored to the needs of the team? You have to create the environment for the exchange of knowledge – let a part of retrospective be a time for promoting good solutions that are worth popularizing, create a base of code examples (e.g. how to code a good service or a controller), stimulate short internal trainings such as “What have we learnt using the X library?”, let your people work in pairs – if not all the time, at least at the beginning and at the end of creating a solution. Not all the developers can work together – sometimes you have to put effort into teaching them how to do it, i.e. how to find a common solution when there are different vantage points.
  
  Dear leader, building the environment of continuous learning should be one of your main goals. Thanks to it you will have well-motivated and efficient people who will create consistent solutions.
  
  What will you get if you don’t initiate such a process? You might already be familiar with it – there will be implementations of the same mechanisms in difference places. You will have problems if someone leaves the team, because knowledge and expertise will be linked to particular people.
  
  Lack of exchange of knowledge means lack of motivation and boring environment, so over time you will start struggling with higher turnover in your team and the outflow of knowledge and experience will be more and more noticeable. Apart from that the general expertise of your team will decrease. In fact, it will stop at one level, which in software development means regress.
  
  
• lack of knowledge updates about system – each developer or a leader who has some experience is aware of the fact that systems change faster than we think and in a different direction than we have expected. Therefore, all the arrangements about system architecture, libraries and mechanisms used will have to be modified. Leaders often forget that they have to put effort into implementing and maintaining the change. One of the most frequent mistakes that leader or (the main) architect make is that they are the only people who know the direction of the system and “the currently correct” version of the architecture. Sometimes they even forget to announce it (that’s odd, right?). Sometimes they only write an e-mail and send a document. And that’s not enough.
  
  First, you need to gather feedback from people and know what difficulties they see in applying the vision and what resources they need. Second, in the first phase of implementation you need to have the method for monitoring changes and focus on design during code review, applying verification lists (checklists) checking key assumptions. And you should do retrospectives, which through the analysis of problems and successes will enable you to monitor the efficiency implementing architecture vision.
  
  
• lack of places to gain new knowledge – many companies have a strategy like that: here people learn on their own. This is perfectly OK. I am the representative of this way of thinking as well ;-)
  
  But this approach has its drawbacks.
  
  First, when you learn on your own, you limit yourself to the context that you know. It is hard to go beyond it. For this reason it is much harder to find other, more novel solutions and a different approach to the problems that you have to solve, because your perception is limited by your so far experiences. Second, learning on your own is often snippy as you collect a lot of information, but you can’t glue it up as a whole. That is why self-learning leads to the impression that we still have a lot to learn. It’s hard to tell what is grain and what is weed. You need a few years of experience to learn how to distinguish between these two and say: that’s enough. Third, other people serve as the best inspiration that you cannot substitute with individual work. Most of our ideas stem from contacts with other people – be that personal contacts (which I perceive as the most efficient) or contacts through internet.
  
  This is the reason why trainings, conferences and events that are not fully connected with what developers do in their everyday job are extremely valuable. Your task as a leader is to focus and catalyze the knowledge and experience gained, for example through the following question: “How can you use what you’ve learnt there?” And don’t let them give you short shrift by fast and simple answers. Dwell on and you will get a more conscious and knowledgeable team member.

Below you will find a short cheat sheet (click to enlarge).

Read More

Unknown 14:40  No comment

If you were to do one thing, it should be...

I have had an interesting conversation with my friend who is also a manager in one of Polish companies. In a certain moment he said:

- You know, what I have been doing recently was mostly convincing business not to start a particular project or to start it later. It took me a lot of time - he said, having in mind it was a loss of time.

- That's great - I said. - I think it's one of the most important things any leader should do, especially when working in a high pressure environment. As Steve Jobs said one time: the most important tool to improve programmers productivity is reducing number of features they have to implement.

It's the most common disease software teams have to deal with. It's quite common that a few projects are run in the same time and then another one is added to the stream. All Kanban and Lean practitioners will tell you it is a waste. And it really is. Don't you believe? Try Knibberg's Multitasking Name Game. Play it with your business and then discuss what can you learn from it.

(Picture from Multitasking Name Game manual).

Read More

Unknown 08:12  No comment

Simple, complicated, complex and chaotic systems, in other words Cynefin. And how does it relate to software development?

Intro

You might have already come across terms such as complex systems, complicated systems or complex adaptive systems; especially,  if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s ideas about the applicability of Scrum. It might sound intriguing, but finding logic in it is difficult without some background theory. This is the point at which Dave Snowden’s Cynefin concept comes in handy. This concept is based on complex systems theory, anthropology, evolutionary psychology and, last but not least, cognitive psychology.

What’s the matter with software development?

For about forty years people who deal with software development have been wondering what it really is. Can we compare it to anything? Initially, people approached it the same way as it was in Ford’s factories, i.e. through classical management methods and tools such as hierarchies, division of work, specialization, plans, etc. It did not work, though. The popular metaphor, according to which software development is like the process of designing and building a building, did not work either. It was Agile that went a step further – it was finally accepted that change is a natural element of any project. Technologies change. Requirements change. Our co-workers change (which is obvious considering the fact that it takes months or years to complete some projects). Therefore, whenever we run a project, we have to take changes into account.  And we have to adapt to them. That is how Agile has aroused, including the most popular method Scrum. Sometimes they proved effective, sometimes they did not.  People started seeking for a theoretical background that would allow them to understand why Agile really works and what are the criteria  that would help them decide whether they should use it or not.

The Cynefin Model

In this respect the Cynefin model comes in handy, as it organizes problem domains that we come across depending on the applicability of approaches used. The basis of this model is the relationship between the cause and its effect. As a result, the following areas of problem (system) complexity can be listed:

·         Simple – systems, in which we can easily associate the cause and the effect. This area includes domains that are well-identified and thoroughly described in literature; they do not require complex interpretation and there is a huge number of resources that deal with them. When you buy a new mobile phone and you want to configure it using the instruction manual, it means that this is a simple domain (of course, as long as the manual is clear enough). In this area you can use recipes, best strategies and models that you can easily and directly put into practice.

·         Complicated – systems, in which there is a cause-effect relationship, but it is difficult to detect it. Finding a solution to problems from this domain often requires expert knowledge, a lot of experience and complex analysis. Apart from that these are usually static systems or systems that are not really vulnerable to changes (if there is a change, you can easily predict and analyze it). Examples of such systems include a watch, a car or a house – they are static, but to create or repair them we need some expert knowledge.

·         Complex – systems, in which there are no clear cause-effect relationships, because they change with time. We can detect them through experiments and investigations into the current state of affairs. Even expert knowledge does not allow us to arrive at a solution, but we can use it to set the direction of investigations. Systems under this category are live, organic and changing. Where there are people, there are usually complex systems. Examples of such systems include a stock market, a brain, the immune system, societies.

·         Chaotic – systems in which there are no cause-effect relationships. We cannot detect them, because they do not exist. Examples of such systems include all emergency situations, fires and disasters.

·         Disorder – a situation in which we are unable to define the type of the system that we deal with.

How does it relate to software development?

Below you will find a couple of examples. We have a simple system whenever we have a first-line support. The client calls us, because he/she does not know how to add another lead in the CRM. First-line support worker leads him/her by the hand and helps solve the problem (which could be solved by the client if he/she spent more time on it).

Another situation. You want to install additional software on your PC. It turns out that it requires drivers. You download the drivers. Next you install them. It works. This is an example of a problems from a simple system. But let’s assume that you work with a Linux-related OS and to install the drivers you have to recompile the kernel. A common user just won’t manage. Thus, we enter the area of complicated systems.

Most of our development job revolves around complicated systems. Container and development system configuration, authorization, authentication. This is expert knowledge that we need to develop software. On the whole, in its basic form design and programming are complicated systems as well, but… Yeah, but that’s not so obvious. Let’s assume that you program for yourself, you are the source of requirements, you write a piece of code that you can complete in 10 hours or so, and your code will mostly remain unchanged. This is a complicated system. Even when we consider a serious long-term project (at least a few months’ long) and we are lucky enough to have requirements that are well-defined, settled and do not change, we still deal with a complicated system.

Talking about maintenance we can also talk about complicated systems, but only on condition that the system that we maintain does not develop (our work boils down to fixing the bugs).

But if the situation is different, i.e. the requirements change, they are specified in the course of the project, or the project participants change, we have a complex system. In such cases programming – both the design and the code – has to be perceived as a complex system. I think that we are all aware of the fact that most development projects fall into this particular category.

Of course, some of them are chaotic systems as well. It is so if there are no rules, the team works ad hoc and most of the work boils down to putting out fires. This is chaos. Both literally and metaphorically. 

What does it give us?

Exactly. Theory will always remain theory. There is one important question – what do we need it for? According to the Cynefin model, when we define the system, we can apply means that are context-dependent. These means are:

·         The main strategy

·         Leader’s activities

·         Tools

Context	Strategy	Leader’s activities	Tools
Simple systems	1. Sense 2. Categorize 3. Respond	monitor the process, standardize, delegate, use best practices,	best strategies, 5 WHYS, manuals, recipes, PMBOK
Complicated systems	1. Sense 2. Analyze 3. Respond	form an expert panel mediate	processes, standards, expert panels, Kanban, PMBOK
Complex systems	1. Probe 2. Sense 3. Respond	leave space for the team self-organization, improve communication, empower	trials, experiments, discussion, limited self-organization, Agile, Kanban
Chaotic systems	1. Act 2. Sense 3. Respond	act and conclude on this basis, communicate in a simple and unambiguous manner, command and control	do whatever, intuition

Practically speaking, it is impossible to classify a project into one type only. Contexts are mixed, but there is usually one dominant context. If the simple or complicated system dominates, PMBOK tools will be useful. If we deal with a mostly complicated or complex systems,  Agile and Lean/Kanban tools might help.

Summary

As we could see, Cynefin gives us a way of seeing the complexity of problems that we come across. It divides them into four main areas and suggests some workable actions to take. Thanks to it we know that a self-organizing team does not have to be the best solution in each development project, and that in the case of chaos the best way is to use command-and-control management. Chaos might result from frequent and unpredictable changes in the project or in the team. Alternatively, it may be a natural consequence of poor skills of the team members. On the other hand, however, in predictable environments you don’t necessarily have to struggle to use Agile as the only justifiable solution and classical methodologies might prove ineffective in complex domains.

Nevertheless, Cynefin is not only a model – this is also a set of strategies that we can use, especially in complex domains.

But... life is not so simple though. The model itself doesn't give you direct answers. Even Dave Snowden is not always sure were to put some software development practices (you can dig into his blog here). On the other hand it is a quite interesting perspective you can take into consideration while making decisions.

Read More

Unknown 11:05  3 comments

(Polish) Systemy proste, skomplikowane, złożone i chaotyczne czyli Cynefin.

Być może wcześniej miałeś do czynienia z pojęciami typu systemy złożone, skomplikowane, złożone systemy adaptacyjne na przykład przy okazji czytania Management 3.0 Jurgena Appelo albo czytając rozważania Kena Schwabera na temat aplikowalności Scruma. Być może to brzmi intrygująco, jednak trudno odnaleźć w tym logiczny sens jeśli nie ma się pewnej bazy teoretycznej. I tutaj warto się przyjrzeć koncepcji Dave'a Snowdena zwanej Cynefin opartej między innymi na teorii systemów złożonych, antropologii, psychologii ewolucyjnej,  psychologii poznawczej.

O co chodzi w tym wytwarzaniu oprogramowania

Już niemal od czterdziestu lat ludzie zajmujący się tematem wytwarzania oprogramowania zastanawiali się, co to tak naprawdę jest, do czego można to porównać, jakiego typu to zagadnienie. Pierwotnie próbowano zastosować do tego celu klasyczne myślenie związane z zarządzaniem rodem z Fordowskich fabryk (czytaj: hierarchie, rozdzielona praca, specjalizacja, plany). To niestety się nie sprawdzało. Nie do końca sprawdzała się również metafora odnosząca tworzenie systemów informatycznych do projektowania i budowania budynków. Agile w swoim myśleniu poszedł dalej – założono, że zmiana jest naturalną częścią projektów. Zmieniają się technologie. Zmieniają się wymagania. Zmieniają się ludzie, z którymi pracujemy (co jest dość naturalnie przy kilku lub kilkunastomiesięcznych projektach). Zatem podejście do realizacji projektów powinno zakładać tę zmianę i adaptować się do niej. Tak powstały różne metodyki z rodziny Agile, w tym obecnie najpopularniejszy Scrum. Czasami się sprawdzały. Czasami nie. Zaczęto poszukiwać teoretycznej bazy, która pozwoli odpowiedzieć na pytanie, dlaczego Agile w ogóle ma prawo działać oraz jasnych kryteriów, kiedy warto rozważać jego zastosowanie, a kiedy nie.

Model Cynefin

Z pomocą może przyjść wspomniany wcześniej koncept Cynefin, który jest modelem porządkującym dziedziny problemów, z którymi mamy do czynienia i adekwatności stosowanych podejść. Bazą dla tego modelu jest zależność między przyczyną a skutkiem przez nią wywołanym. Wyróżniono w ten sposób następujące obszary złożoności problemów (systemów):

·         Proste (ang. simple) – to systemy, w których jednoznacznie można powiązać przyczynę ze skutkiem. Dobrze rozpoznane, opisane dziedziny, gdzie dostępna jest wiedza, gdzie występujące problemy nie wymagają złożonej  interpretacji czy doświadczenia należą do tego obszaru. Jeśli właśnie nabyłeś nowy telefon i chcesz go skonfigurować na bazie podręcznika użytkownika, to masz do czynienia z dziedziną prostą (o ile podręcznik użytkownika rzeczywiście wystarczy). W tym obszarze lokują się wszelkie receptury, najlepsze strategie oraz modele, które można bezpośrednio zastosować w praktyce.

·         Skomplikowane (ang. complicated) – są to systemy, w których istnieje powiązanie między przyczyną i skutkiem, ale nie są one proste do wykrycia. Często wymagają wiedzy eksperckiej, dużego doświadczenia oraz złożonej analizy, aby znaleźć rozwiązanie problemy z danej dziedziny. Ponadto system tego typu jest statyczny lub przynajmniej mało zmienny (zmienność można przewidzieć i przeanalizować). Przykładem takiego systemu może być zegarek, samochód, dom. Są one statyczne, jednak żeby je stworzyć, naprawić, rozwiązać problem potrzebna jest wiedza ekspercka.

·         Złożone (ang. complex) – są to systemy, w których nie ma jednoznacznych powiązań między przyczyną i skutkiem, gdyż zmieniają się one w czasie. Może je wykryć poprzez eksperymenty i dociekania obecnego stanu rzeczy. Wiedza ekspercka nie daje jednoznacznych odpowiedzi, może za to służyć jako baza do decydowaniu o kierunku poszukiwań. System tego typu to system żywy, organiczny, zmienny w czasie. Zazwyczaj tam gdzie mamy do czynienia z ludźmi mamy do czynienia z systemami złożonymi. Systemy złożone to także giełda, mózg, układ odpornościowy, społeczności.

·         Choatyczne (ang. chaotic) – są to systemy w których brak jest powiązań między przyczyną i skutkiem. Nie można ich odkryć, bo ich tam nie ma. Wszelkie sytuacje alarmowe, pożary, katastrofy są przykładami takich systemów.

·         Nieuporządek (ang. disorder) – to sytuacja, w której nie jesteśmy w stanie, określić z jakiego typu systemem mamy do czynienia.

Co to ma wspólnego z wytwarzaniem oprogramowania?

Przedstawmy kilka przykładów. Mamy do czynienia z systemem prostym, kiedy myślimy o pierwszej linii wsparcia. Dzwoni klient, bo nie wie jak dodać nowego leada w CRM. Pracownik z pierwszej linii prowadzi klienta za rękę i pomaga rozwiązać problem (który pewnie klient sam byłby w stanie rozwiązać, gdyby poświęcił temu więcej czasu).

Inna sytuacja. Chcesz zainstalować dodatkowe oprogramowanie na komputerze PC. Okazuje się, że potrzebuje ono sterowników. Ściągasz je. Instalujesz. Działa. To przykład problemu z systemu prostego. Ale załóżmy, że pracujesz z systemem operacyjnym z rodziny linux i instalacja sterowników wymaga rekompilacji jądra. Zwykły śmiertelnik dalej tego nie pociągnie. Wyraźnie wchodzimy w obszar systemu skomplikowanego.

W programowaniu większość naszej pracy to systemy skomplikowane. Konfiguracja kontenera, systemu budowania, autoryzacja, uwierzytelnianie. To typowa wiedza ekspercka, która jest potrzebna do skonstruowania oprogramowania. W zasadzie w swojej podstawowej formie projektowanie, programowanie to również systemy skomplikowane. Ale… No właśnie. Tutaj sprawa nie jest tak oczywista. Jeśli weźmiemy pod uwagę taki przypadek, w którym programujesz sam dla siebie, jesteś źródłem wymagań, piszę kawałek kodu, który jest do zrobienia w ciągu kilkunastu godzin, mój kod nie będzie dramatycznie modyfikowany, to wtedy jest to system skomplikowany. Albo nawet w sytuacji, kiedy bierzemy pod uwagę długotrwałe i niebanalne przedsięwzięcie (kilka lub kilkanaście miesięcy) i jesteśmy szczęściarzami, bo nasze wymagania są dość dobrze zdefiniowane, spisane i nie zmieniają się, to cały czas mamy do czynienia z systemem skomplikowanym.

Mówiąc o utrzymaniu również możemy mówić o systemie skomplikowanym, pod warunkiem, że utrzymywany system się znacząco nie rozwija (prace głównie polegają na naprawie bugów).

Jeśli jednak tak nie jest – wymagania się zmieniają, są doprecyzowywane w trakcie, zmieniają się ludzie biorący udział w projekcie, to mamy do czynienia z systemem złożonym. Wtedy samo programowanie - powstający design oraz kod w konsekwencji należy również rozważać w kategorii systemów złożonych. Chyba to już jasne, że duża część projektów programistycznych mieści się w tej kategorii.

Choć pewna część mieści się również w kategorii systemów chaotycznych – tam gdzie nie ma reguł działania, kiedy zespół pracuje ad hoc, kiedy praca odbywa się głównie na zasadzie gaszenia pożarów. Tam mamy do czynienia z chaosem. I dosłownie i w przenośni.

Co z tego jest do wzięcia?

No właśnie. Teoria teorią. Pytanie tylko – po co to wszystko? Mianowicie wg modelu Cynefin, jeśli już określimy z jakiego typu systemem mamy do czynienia, wtedy możemy dobierać środki odpowiednie do kontekstu. Te środki to:

·         Główna strategia

·         Działania lidera

·         Narzędzia

Kontekst	Strategia	Działania lidera	Narzędzia
Systemy proste	1. zintepretuj 2. skategoryzuj 3. zareaguj	pilnuj procesu, standaryzuj, deleguj, używaj najlepszych praktyk	najlepsze strategie, 5 WHYS, podręczniki, receptury, PMBoK
Systemy skomplikowane	1. zinterpretuj 2. przeanalizuj 3. zareaguj	stwórz panel ekspertów, mediuj	procesy, standardy, panele eksperckie, Kanban, PMBoK
Systemy złożone	1. zaeksperymentuj 2. zinterpretuj 3. zareaguj	daj przestrzeń zespołowi do samoorganizacji, usprawniaj komunikację, empowerment	próby, eksperymenty dyskusje samoorganizacja w ograniczonym środowisku Agile, Kanban
Systemy chaotyczne	1. działaj 2. zinterpretuj 3. zareaguj	działaj i wnioskuj na tej bazie, prowadź prostą, jednoznaczną komunikację command and control	zrób cokolwiek, intuicja

Praktycznie żaden projekt nie jest czystej postaci, typy kontekstów są ze sobą przemieszane, natomiast zazwyczaj istnieje typ dominujący. Jeśli mamy do czynienia z dominującym systemem prostym lub skomplikowanym użyteczne będą narzędzia z rodziny PMBoK, jeśli mamy do czynienia z systemami skomplikowanymi lub złożonymi użyteczne będą narzędzia z rodziny Agile, Lean/Kanban (przy czym należy dodać, że w swojej źródłowej formie – Lean Manufacturing, to przede wszystkim narzędzie dla systemów skomplikowanych, które udostępnia dodatkowe do uporządkowania dziedziny problemu).

Na koniec

Jak widzieliśmy Cynefin proponuje nam pewien sposób postrzeganiu złożoności problemów, z którymi mamy do czynienia. Dzieli je na cztery główne obszary sugerując możliwe działania w tych obszarach. Dzięki temu wiemy, że samoorganizujący zespół nie musi być najlepszym rozwiązaniem w każdym projekcie programistycznym, że w przypadku dużego chaosu, najlepsze będzie zarządzanie twardej ręku (typu comand-and-control). A chaos może być efektem częstych i nieprzewidywalnych zmian w projekcie, ludziach czy też może być naturalną konsekwencją kiepskich umiejętności zespołu. Z drugiej strony w przewidywalnych środowiskach, niekoniecznie trzeba się silić na Agile, twierdząc, że jest to jedyne słuszne rozwiązanie. A z trzeciej strony stosowanie klasycznych metodyk będzie nieefektywne w przypadku projektów o charakterystyce  złożonej.

Jednak Cynefin to nie tylko ten model, to także szereg strategii, które można zastosować szczególnie w dziedzinach złożonych, ale to już inna historia.

Łyżka dziegciu. Oczywiście sam model nie daje jednoznacznych odpowiedzi. Nawet sam twórca Dave Snowden ma wątpliwości odnośnie tego, jak przyporządkować niektóre kwestie związane z metodykami zwinnymi (co można prześledzić na jego blogu). W każdym razie mimo wszystko jest to ciekawa perspektywa, którą warto uwzględnić na swojej ścieżce decyzyjnej.

Read More

Unknown 16:25  2 comments