"You may say I'm an extremer (...)"

I found this one years ago #nostalgic...


Imagine there’s no requirements.
It’s easy if you try
Just a bunch of coders,
reachin’ for the sky
Imagine all the people,
coding for today

Imagine there’s no schedules.
It isn’t hard to do
No silly project deadlines,
no one supervising you
Imagine all the people,
coding hand in hand

You may say I’m an extremer
but I’m not the only one
I hope someday you’ll join us
and make coding lots more fun.

Imagine oral documentation.
I wonder if you can
No need for UML diagrams.
Just words passed, man to man
Imagine just refactoring,
playing in the sand

You may say I’m an extremer
but I’m not the only one
I hope someday you’ll join us
and make coding lots more fun


Public activities calendar

I publish my public activities calendar because I want o meet you, share our ideas and talk about our professional experiences.

You will find the calendar on this blog on the left or you may subscribe it via xml, ical or html.

So let's stay in touch, I hope to see you soon :)

The most valuable lesson learned from GTD

Whole GTD framework is worth to familiarize yourself with. But the one thing was a rocket jump for me - tasks chunking.

David Allen advice is tasks should be actionable. It means they should be ready to do now. You may examine your tasks by asking: Is it a physical action? where physical means you may express it in the language of your senses and you body. For example 'Process input data' is not physical action. Why? Try to show a process activity by your hands:). Impossible.

In opposite to tasks above: 'Talk to Peter about object model for input data', 'Draw down sketch of classes', 'Write down steps of the data processing algorithm', 'Write initial unit tests for data processing service',... are more 'physical'. So if you are aware of the context these tasks are ready to do as they are now. And this is what we call task chunking.

When I start working on a project I write down some general epics, stories, goals. But I never start working on them unless I write down at least one actionable task. In fact one actionable task is the minimum you need. Ok, I do mistakes and sometimes I take a task which is too general to accomplish it and then I always fail. The only rescue is tasks chunking.

I have also my own actionability cirterion I call it Copy-Paste Test:
'copy' a task and 'paste' it into different context; the less sense it make the more actionable it is. The reason is that specific and actionable task are strongly coupled with its context. So 'copying' them into different context make them incomprehensibled.

Consider: 'Implement the finding service' fits to every context so it is unactinable, but 'Implement service for finding Employee entity by department and salary' is stronger coupled with its context and it is more actionable.

About tools

Personally I use a kanban board on my fridge, at work we currently use LeanKit.com/. These two help me to keep clarity and limit work in progress. For tasks chunking I use todoist.com.

Quora.com - my new public service

I made a resolution to contribute to the Community more than I used to. I chose the quora.com to be my first step. Reading my blog or tweets you probably have some ideas what I am involved in. So, do not hesitate to ask detailed questions, if I know the answer I will let you know. You may follow your questions and my quora.com activity as well.

Conversation Patterns: Polowania na czarownice i czarowników

This article is part of my work on Conversation Patterns for Software Professionals

---

(...) uzmysławiamy sobie tę prostą prawdę, że za wszystkimi komunikatami, którym dotychczas pozwalaliśmy brzmieć groźnie, stoją jedynie ludzie o niezaspokojonych potrzebach, którzy proszą nas, abyśmy coś zrobili dla poprawy ich samopoczucia, Marshall B. Rosenberg

A gdy już coś pierdyknie, to zaczyna się poszukiwanie przyczyny niepowodzenia. Skądinąd ta racjonalna idea opiera się na uproszczonym założeniu, że gdzieś istnieje single point of failure, lub double. No, skończona ilość pojedynczych przyczyn.

Jednak dyscyplina system thinking wskazuje, że niepowodzenie jest wypadkową złożonych interakcji w "systemie". Ciekawe studium przypadku w tym kierunku możesz znaleźć w Efekcie Lucyfera by Philip Zimbardo.

A więc szukamy winnych...

...ponieważ, czujemy potrzebę rozładowania emocji, z którymi sobie nie radzimy. Kolejne szczegółowe objaśnienie znajdziesz w Porozumieniu bez przemocy, skąd pochodzi początkowy cytat.

...ponieważ, to najłatwiejszy sposób do uzyskania poczucia, że problem został zrozumiany, i że w przyszłości będzie można go uniknąć. Oczywiście owo "poczucie", nie oznacza, że sprawa rzeczywiście została rozwiązana. Oznacza to wyłącznie tyle, że skoro polała się krew, to wszyscy zestresowani zainteresowani odetchnęli z ulgą, że oberwał ktoś trzeci i że sprawę załatwiono.

...ponieważ nie umiemy sobie radzić z "otwartymi" sprawami. Trudno zająć się czymś innym, gdy nurtuje Cię pytanie, na które nie znasz odpowiedzi, test, który nie przechodzi, czy //XXX, którego nie możesz namierzyć. Ta zasada jest podstawą każdej hmmm... metodologii efektywności m.in. 7 Habits of Highly Effective People, Getting Things Done, Personal Kanban, Awake the Giant Within, które dają przepisy na przekształcanie "otwartych" spraw w motywujące mierzalne cele.

Psikus z otwartymi sprawami polega na tym, że gdy czegoś nie rozumiemy i w dodatku mamy do tego mocno emocjonalny stosunek, to rozpaczliwie szukamy zamknięcia otwartej sprawy, choćby owo zamknięcie było najgłupszym z możliwych. W ten sposób zadowalamy się prostymi odpowiedziami na trudne pytania i preferujemy tanie suplementy intelektualnej diety.

Co z tym fantem?
Poniżej podaję kilka pomysłów, jak przeciwdziałać poszukiwaniu winnych. Nie są to rozwiązania instant, ale kilka z pewnością się przyda.

• Omawiaj wtopy po weekendzie; będzie nieco czasu na ochłonięcie
• Omawiaj wyłącznie fakty (ad rem). Fakty dotyczą tego, co do mózgu dostarcza nam jeden z pięciu podstawowych zmysłów, czyli to co można zobaczyć, usłyszeć, powąchać itd; szósty zmysł a więc wszelkiego rodzaju mind reading zostawiamy w spokoju
• Jak ognia unikaj zdań zawierających: jesteś (ad personem), zawsze, nigdy, ciągle, wciąż, żaden (kwantyfikatory)
• Jak piekielnego ognia unikaj ocen - ten punkt jest dla wielu z nas nie do przejścia. Zdanie Zobaczyłem, że to spieprzyliście nie jest stwierdzeniem faktu lecz oceną, bo czynności spieprzenia nie można zobaczyć, ale można zobaczyć, że: w połowie iteracji na tablicy wisiało dużo zadań z błędami, burn-up chart ma 20 schodków, ktoś zatwierdził kod z błędami itd.
• Omawiaj fakty tylko z pierwszej ręki. Zabawa w głuchy telefon jest śmieszna w przedszkolu i to tylko wtedy, gdy traktuje się ją jako zabawę; tymczasem dorośli traktują głuchy telefon śmiertelnie poważnie
• Najpierw zbierz wszystkie punkty widzenia, a dopiero potem je omawiaj. Z szacunku dla tajemnicy ludzkiego umysłu bezpiecznie jest założyć, że nawet gdy ktoś coś komuś zrobił, to każda ze stron ma świadomość tylko wycinka całej sytuacji. Najpierw zbierz wszystkie puzzle, a dopiero potem staraj się zobaczyć obrazek
• Rozwiąż problem lokalnie, a potem standaryzuj
• Trenuj Technikę pozytywnej intencji

Dużo piszę o faktach. Mówimy o faktach, ale wszystko to w obrębie empatycznego porozumienia, po które odsyłam do książki Marshalla Rosenberga.

Niezadowolenie ma sens

Product Owner, który "odpuszcza" w trakcie demo, działa przeciw zespołowi. O co chodzi?

Iteracja była trudna. Wyskoczyło sporo bugów, związanych z niezaplanowaną refaktoryzacją dawno zapomnianego kawałka systemu. Zespół pracował na najwyższych obrotach, a schodki na burn-up chart zdawały się nie mieć końca. W ostatnim tygodniu wszyscy z utęsknieniem czekali na piątek, a gdy już nadszedł, od samego rana czuć było podekscytowanie zbliżającym się demo.

Wysprzątany pokój, rozstawiony rzutnik, zespół w świątecznym nastroju. Brakuje tylko czerwonych goździków dla zasłużonych. Wszyscy z uwagą śledzą rozmowę PO z jednym z programistów, prezentującym implementacje poszczególnych historyjek. Scenariusz po scenariuszu idą jak z płatka i nagle..&^@%!@

W tym momencie w zgodzie z niektórymi teoriami Wszechświat się rozgałęzia i mogą wydarzyć się co najmniej dwa scenariusze.

Scenariusz A

Następuje chwila niezręcznej ciszy, podczas której PO patrzy na napięte twarze zespołu, na których między wielkimi, jak u Puszka Okruszka oczami, powiększa się nabiegły łzami znak zapytania.

Ktoś powiedział, że największe boje w historii ludzkości wydarzają się w zakamarkach ludzkiej duszy. Nie inaczej jest teraz. Po długiej jak wieczność chwili, na twarzy PO pojawia się miękki uśmiech.
- Ok - rzuca ciepło - powiedzmy, że jest zrobione. Dokończycie w międzyczasie ("międzyczas" - niepotwierdzony żadną poważną teorią bufor czasowy, w którym da się wykonać więcej pracy, niż w całym projekcie łącznie).

Wszyscy oddychają z ulgą. Znów jest miło. Po zakończonym demo ludzie w pośpiechu wymykają się z biura. Już weekend. Można odsapnąć i zająć się czymś innym niż to natrętne, kołaczące na skraju świadomości odczucie wewnętrznego "fuj".

Niestety historia lubi się powtarzać, więc i ta się powtórzyła. Po trzeciej podobnej repecie, idąc na demo ludzie zaczynają włączać autopilota itd., itd., itd.

---

Scenariusz A'

Nastąpiła pełna napięcia cisza. Cisza. Przeciągająca się cisza. PO wziął głęboki oddech i:
- Przykro mi, ale to jest DONE. Nie zgodnie z tym, co ustaliliśmy jako DONE.
- Ale przecież jest to tylko kwestia kosmetyki. Parę godzin i będzie gotowe. A ta druga historyjka jest gotowa, tylko jeszcze nie wdrożona. Projekt nam się za długo buduje.
PO popatrzył na rozmówcę wzrokiem Johna Wayne'a i powiedział:
- Gdybyś miał za tę pracę zapłacić z własnych pieniędzy, to zapłaciłbyś?

Niemal w tej samej chwili, Piotrek wybiegł z sali trzasnąwszy drzwiami, a w reszcie grupy, wybuchła gorąca dyskusja, od czasu do czasu ocierająca się o kłótnie.
- Nie - powtórzył twardo PO - Nie jest DONE. Nie odbieram.
Na tym dyskusja się zakończyła.

Gdy pył opadł, zespół zasiadł do retrospekcji. Mieli nad czym dyskutować, więc ledwo zmieścili się w założonym czasie. Ustalono, że: Paweł z Marcinem rozpoznają temat serwera CI i one-click building, koncept zadania zawsze będzie analizowany zespołowo, blokery będą omawiane na forum i w razie potrzeby zespół decyduje się na swarming, historyjki z najbliższego sprintu zostaną ponownie przeszacowane, refaktoring będzie robiony zawsze parami.

Ludzie wychodzili z biura w znakomitym nastroju. PO ich cholernie wkurzył, ale znaleźli rozwiązanie. Zawsze znajdują. Wprowadzili do swojej pracy niezbędne modyfikacje. To się już nie powtórzy. Nie ma prawa się powtórzyć. Po weekendzie zaczyna się nowy sprint. Każdy z programistów już widzi najbliższe demo i PO śpiewającego peany na ich cześć.

---

Wniosek

Czasem, nie chcąc sprawiać komuś przykrości, robimy mu krzywdę.