(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

Technical leader worries: I have too many things to do

Those wonderful days when the only thing you did was writing a code have gone. Now you are a leader. You are doing everything: attending or conducting meetings, removing impediments, mediating between team members and the rest of organisation, reading or writing some kind of reports (and you deceive yourself that spending two hours in excel counts for programming because of some smartly used formulas) and so on, and so on. You are in a hurry all the time and it never ends.

Today I would like you to get familiar with one useful technique.
Before you put a task to your TODO list ask three questions.

Treat those question as something to elaborate about. Those are just reminders. I will explain in short what is going on.

Is me the best person to do the task?
Business world is busy, fast and many things are not well analysed. I remember it for myself that many times I assigned the task to somebody not thinking much about it and that person wasn't the best one to address the subject. Especially if you are a leader ask yourself a question:
Does this task should be done by my team?
Should I personally do this task? 
Many times people in the team are able to do the task so that you may focus on your leader activities (where you are not easily replaceable). If you use pull model (like Kanban) place this task on a team board.

Does it have to be done now?
How many times you have experienced situation where something had to be done till the exact date. And then a few days later after asking: "How about that report?" (supposing the task result was a report) you get in response: "Oh, I didn't have time to took at this".
"Ughhhhhh... So why did I work overtime?" - you think and feel disappointed.
I can tell you why. Because you didn't ensure that it really had to be done till that date (Of course even doing so you will not eliminate such situations entirely.)

You may ask (suppose today is Wednesday):
"I am doing X, Y, Z and I would like to have them done because .... Would it be a problem if I completed this task on Monday?"
Or very similarly (if a task or feature is addressed to whole team):
"We are doing X, Y, Z now and we would like to get them done because ...(explain). Would it be a problem if we started to work on the feature on Monday?"

Does it have to be done it the particular way?
If task definition specifies how task should be done, be sure to check if this is the best way (especially if there is not much time). Make sure that you know the goal (why this task should be done at all and why is should be done this way). If you know the goal you may suggest easier or simpler alternatives.

Encourage your teammates to do the same
This is so good tool that it is worth spreading. Many leaders are little afraid that team members will start to negotiate the tasks and it will be the begining of a rebelion. And you should welcome this with understanding (and I know it is not easy). By practicing this technique people learn to look critically at what happens in the project and you shorten the feedback loop. This is a great way to increase probability of eliminating work that shouldn't be done or simplifying the solutions. This is also good exercise for strengthen trust in your team. Only people being safe (and this is the base for trust) are eager to ask questions like these.

Read More

Unknown 14:51  1 comment

A morning thought: The greatest contribution of Agile

Today morning I came across Henrik Knibberg video http://www.youtube.com/watch?v=Rb0O0Lgs9zU titled Culture over Proces. What hit me was that it was about Culture.

Wait a minute... Culture? But we talk about software development... IT... 0-1 world. So what the fuck Culture is doing here?

For any agilist this is not strange subject. We have been talking about for more than ten years. We (as a community)consider this to be important part of our jobs - so called "soft skills". What's more interesting terms software development and soft skills have the similar wordbase ;-)

I believe that the greatest contribution of Agile is bringing human-side to the techy world.

Not a bunch of methodologies. Not a bunch of pracitces. We have started to think about people. And that is what I love about it.

Read More

Unknown 09:06  No comment

Technical leader worries: my organisation is a mess and nobody cares

Some time ago I coined a funny equation like this:

What is not so funny that reality many times follow this heurisitcs. The bigger organisations the more true it becomes. But it also true for many small organisations so don't bother. The grass in not greener on the other side.
Even if company has an estabished vision, aligned values and rules to follow, the mess is there. It is quite obvious - entropy works so scale and time make the consequences more painful.
What I really mean? Many times I can hear complaining like this:

• My boss is not interested in what I am doing...
• Executives in my company don't care about people
• We are treated as resources
• There is no people development plan
• Our (mine and the team's) needs are not taken into consideration

All these whinings point in some way to organisation. Sometimes situation is really not too friendly. And then I sometime ask a question (especially to those folks who work in the company for a couple of years):
- So why are you still working here?
A couple second of silence take place after the question...
- You know I have family, payments, motgage...
- So you choose security over looking for a workplace which will foster your fulfillment?

Yes. This is something I would like to emphisize.

---

We always have a choice. We can choose what we want to do. Always.

---

And we often choose security and sacrify what is so important to us: fun, development, great work climat. What is more tragically we make that decision uncounciously. If you had done it with full awareness you wouldn't have complained about it because it was your choice.

So do it now. 

I call it Self-demistification Tool. 
Ask yourself:
1. Why do I choose what I am doing now in my professional life?
2. What are the trade-offs of my choice? (probably those things you are whining about)
3. Do you still want to choose it?

• if so, stop whining
• if no, quit the job or start influencing enviroment to make a change. 

Yes. This you who is responsible for this. You. Nobody else.

These questions are very important as you can read in this article (in section about job). The experienced people at the end of their lives encourage us not to work in a job we don't like (old truth but it's worth to remind it as so few follow it).

I have another funny equation which expresses what I write here about:

 You are satisfied with what you do when reality is somehow equal to your expectations. If reality is equal or "greater" than your expectations you will be satisfied. If reality is much below your expectations you will be dissatisfied. Based on this model you can do two things:

1. Change reality - a) change your job, b) change the way you and your team work, c) initiate the change in your organisation
2. Change expectations - d) find mission in what you are doing, e) admit that you choose what you do with all trade-offs

I prefer to do use these strategies in following order: b) c) d) e) a) What it means? First I try to change the way I work, if it doesn't help I try to initiate change in my organisation, if it doesn't work or seems impossible, I try to find (maybe not obvious) mission in what I am doing .. and so on.
But never stay in between too long. Choose something otherwise you will welcome depression sooner than you think. Remember. You always have a choice even if it is not easy.

For those who will decide to initiate some kind of change I would like to clarify one thing. I use the term "initiate" because many important changes require time. Usually much more than you would like (and it is sometimes the reason why we give in). So be prepared for waiting.

Read More

Unknown 16:20  No comment