It's All About the Culture

I was attended in really interestnig conference Agilia Budapest by Aguarra company.

The greatest thing was that almost all speakers brought some new ideas and some new approaches in the subject.

So one of the speakers was Andrei Boghiu Product Manager at Prezi, so you probably know who they are. Adrei talked about the product development process in Prezi, from a feature idea to a deployment. He talked about their: continuous learning, constant feedback from the market, lack of documentation in favour of prototypes, collaboration between people, flat organisational structure and so forth.

I listened to him and in that moment I realized Wait a minute, I've heard something similar! Same story I've heard from Spotify guys and the guys from the ThoughtWorks and Touk and SoftwareMill and from couple other companies.

But you know, every time I hear those speakers, I also see people who try to repeat the success story in their own companies and they fail. What is wrong with that?

My observation is that bright companies talk only about the solution they use. However that solutions are well known it's a hard work to implement them with positive results.

Think about it, even if a company use prototypes and screens instead of stories and scenarios, how they convince people to do that? How they engage the people in taking the responsibility instead of waiting for the orders from top management? Finally, how they created the environment where all that well known stuff perfectly works in?

I asked Andrei about it. I think he was little bit surprised by this question ;) and he mentioned couple interesting things such: they engage people to make failures and learning, people (I mean engineers) directly influence the business activities. These are parts of their organisational culture. Yep, it's all about the culture. The culture is the factor which turn all mentioned solutions from an idea into the everyday habits.

Adrei et al. take their organisation cultures for granted, they find difficult to explain what it exactly is. They are simply affected by the culture of their organisations and work in that way.

This is the question I wonder the most: How the specific culture was created in the organisation? What were the steps they used? I have no any doubts that was made on purpose even if the creators were never named what they actually did.

This question requires some deeper researches and interviews.

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.

Dekomponowanie zadań

Umiejętność dekomponowania zadań uważam za kluczową, jeśli chodzi o zarządzanie czasem. W różnych momentach prowadzenia szkolenia z tego tematu, starałem się formułować mniej lub bardziej zjadliwe procedury do przeprowadzania owej dekompozycji. W końcu mnie oświeciło i wpadłem na tę, jak sądzę, najprostszą, elegancką i skuteczną:)

Definiuj zadania maksymalnie czterogodzinne

Wiem, że brzmi to jak magiczna formułka na wszystkie problemy. Aczkolwiek to proste zdanie to tylko wierzchołek czegoś większego. Zauważyłem, że gdy wyodrębniając zadanie skupiamy się na tym, aby zajęło cztery godziny, przebiegamy w myślach przez kilka procedur i kryteriów dekomponowania, które tak usilnie starałem się wcześniej sformułować.

Trik polega na tym, że fiksując się na owych czterech godzinach, musisz wykonać eksperyment myślowy i dość szczegółowo wyobrazić sobie to, co ma być efektem zadania i jak to wykonasz. Czyli właśnie to, czego nie robią osoby mające kłopot z dekomponowaniem, a w konsekwencji i z dotrzymywaniem szacowań.

Cztery godziny to dość krótka perspektywa czasowa, którą w dodatku, jako homo sapiens, potrafisz dość dobrze percypować (@see Nie myj zębów, rób retrospekcje). Żeby więc to czterogodzinne zadanie wykonać, musisz być pewny, że da się je wykonać i formułujesz je bardzo konkretnie (przechodzi Test Copy-Paste). I to jest druga zaniedbywana sprawa.

Cztery godziny to, rzecz jasna, wartość umowna. Chodzi o to, aby perspektywa czasowa, była na tyle bliska, aby ze spokojem się na niej skupić i realnie o niej myśleć. Poeksperymentuj z godziną, dwoma, trzema - sprawdź, co będzie. Czy z większymi liczbami też? Moim zdaniem - nie.

Sądzę, że raczej nie jesteśmy w stanie wiarygodnie oszacować na np. 8 godzin. Wiarygodnie tzn. ze powtarzalną trafnością.No, może z wyłączeniem zadań typu: przybij tysiąc stempli na kopercie, napisz walidację not null dla pięćdziesięciu textfieldów na stronie, gdzie obowiązuje proste mnożenie.

Zachęcam gorąco do eksperymentowania i postępowania wg własnego uznania:)

---

UPDATE 30/08/13
Komentarz do posta uświadomił mi, że powinienem jeszcze kilka słów dodać:)

Moja teza nie brzmi "szacuj na max, 4h bo powyżej tego źle oszacujesz", lecz "jeśli wyodrębniasz zadanie z wystarczająco krótką perspektywą czasową, to zrobisz to konkretnie, gdyż wymusi to przemyślenie przedsięwzięcia i być może utrzymasz szacowanie - lecz nie z powodu szacowania, a konkretności właśnie"

Tak jak napisałem, 4h przyjąłem arbitralnie. Co do trafienia w większe oszacowanie, to różnie bywa (por. "Szacowanie oprogramowania", Steve McConnell). Jednakże zwróciłem uwagę, że gdy szacujemy, to zazwyczaj szacowania wyglądają np. tak: 8, 8, 24, 16, 8, 12, 24.

Gdy położyłem przed sobą wiele takich szacowań, to zaważyłem, że niemal wszystkie to wielokrotności jakiejś bazowej liczby: często 8 bądź 6.

Wnioski były dla mnie takie:

• szacując operujemy jakimiś tam idealnymi interwałami (osobodniami, efektywnymi dniami), za pomocą których próbujemy odwzorować czasochłonność zadania
• raczej nie szacujemy czasu, lecz rozmiar zadania - jak duże ono jest

Gdyby chcieć podawać rzeczywiste oszacowania, trzeba by zaprzęgnąć jakaś metodę analityczną np. PERT.

Wg mnie sensowna metoda szacowania polega na retrospektywnej analizie zadań. Najpierw musisz popracować, zobaczyć z czym masz do czynienia, szacować na wyczucie. A potem zaprzęgasz statystykę, analizujesz dane, wyodrębniasz klasy zadań i estymujesz przyszłość z założonym prawdopodobieństwem.

Wtedy dopiero wychodzi, jak bardzo szacowanie wrażliwe jest na zmiany kontekstu, środowiska. Innymi słowy, gdy nie mogę sobie zbudować jakiegoś punktu odniesienia i wszystko absolutnie wszystko się zmienia, to szacowanie jest tylko złudzeniem. Lubimy wierzyć w to złudzenie, bo to łatwiejsze, niż przyznanie, że jednak przyszłość nie będzie wyglądać tak, jakbyśmy chcieli.