Samoorganizacja, samoporządkowanie – zjawiska, w których elementy układu złożonego ulegają spontanicznemu uporządkowaniu; tworzenie się zorganizowanych struktur przestrzennych lub korelacji w przestrzeni i czasie pod wpływem oddziaływań zachodzących pomiędzy elementami układu, oraz między układem a jego otoczeniem. [wikipedia]
Samowola – 1. postępowanie tylko według własnej woli, ignorowanie czyichś nakazów, prawa; swawola, samowolność; 2. czyn będący wynikiem takiej postawy [słownik języka polskiego]
Samoorganizacja wokół mnie
Samoorganizacja jest naturalnym zjawiskiem zachodzącym od miliardów lat na poziomie molekuł, atomów, cząstek, komórek i żywych organizmów. Dzieje się zawsze i dzieje się wszędzie. Wpuść stado przedszkolaków do pokoju pełnego zabawek, a zobaczysz samoorganizację w pełnej krasie. Dopiero całkiem niedawno (w skali wszechświata) ludzie zaczęli kontrolować swoje otoczenie sadząc rośliny i hodując zwierzęta. Chwile później wpadli na pomysł, że można również zarządzać innymi ludźmi. W przeciągu wieków doszli do modelu, gdzie jedna osoba podejmuje decyzje, a inne je wykonują. Na marginesie – niektóre firmy opanowały ten model do perfekcji, dzięki czemu czterdziestu managerów może zarządzać dziesiątką „wyoutsorcowanych” deweloperów.
Samoorganizacja w Zespole Deweloperskim
Członkowie zespołu deweloperskiego są najbliżej tworzonego oprogramowania. Nic więc dziwnego, że najlepiej widzą istniejące problemy i najdokładniej je rozumieją, a dzięki temu są w stanie szybko i efektywnie je usunąć. Mogą działać równolegle i podejmować wiele decyzji naraz. Dlatego jeżeli chcemy dostarczać działający produkt co kilka tygodni, to nie mamy czasu na podejmowanie decyzji przez managerów. Nie możemy sobie pozwolić na to, żeby kierownik projektu przypisywał zadania do ludzi, bo nie posiada on tylu informacji, jak członkowie zespołu. Nie ma już możliwości, żeby zbierał postęp prac od każdego z deweloperów, a następnie aktualizował swoje wykresy Gantta, żeby móc określić status projektu i zaproponować akcje korygujące. Ustaleniem statusu prac i podjęciem odpowiednich akcji na podstawie tych informacji musi więc zająć się zespół deweloperski. Dlatego jego członkowie sami organizują swoją pracę. Sami decydują jak skoordynować zadania i jak ugryźć pojawiające się problemy. Tym samym biorą odpowiedzialność za tworzony produkt oraz za sposób działania, czyli za proces.
Czyli robimy co chcemy?
Jeżeli przeprowadziłaś już powyższy eksperyment z przedszkolakami, to pewnie zauważyłaś, że samoorganizacja może mieć pewne wady. Na przykład kompletny bałagan, podbite oko u Krzysia i ryczącego Jasia. Również Twój zespół może się sam zorganizować i pójść na piwo. Dlatego, jeżeli chcemy dostarczyć konkretną wartość dla naszej firmy, to musimy posiadać cel i ograniczenia. W większości firm jedno i drugie będzie chociaż częściowo definiowane na zewnątrz zespołu. I to jest właśnie nowa rola managerów i liderów, w tym Scrum Masterów.
Cele
Każda grupa ludzi ma jakiś cel. Ma go zarząd firmy, ma go koło gospodyń wiejskich ma i zespół projektowy. Gorzej, jeżeli członkowie grupy różnie postrzegają po co ona istnieje. Wtedy, cel staje się rozmyty, a każdy próbuje osiągnąć to co jego zdaniem jest najważniejsze. Ładny kod, fajna architektura, czytelna dokumentacja projektowa, albo dodatkowy punkt do CV. Dlatego pierwszą rzeczą jaką Product Owner powinien zrobić to wyjaśnić cel produktu. Przekazać po co tworzymy lub rozwijamy produkt, aby uzyskać jego spójną wizję. Dzięki temu zamiast pchać w różnych kierunkach, członkowie zespołu zaczynają wspólnie ciągnąć do celu wyznaczonego przez PO. Natomiast zadaniem Product Ownera jest kontrolowanie, czy rozwój idzie w odpowiednim kierunku, z odpowiednią szybkością oraz, czy warunki zewnętrzne i nowe informacje nie powodują zmiany trasy lub celu.
Ograniczenia biznesowe
Drugą rzecz, którą Product Owner definiuje, to ograniczenia wynikające z otoczenia biznesowego. Czyli na przykład ile pieniędzy mamy, na kiedy jest to potrzebne, lub które funkcjonalności muszą znaleźć się w najbliższym wydaniu. Inaczej mówiąc, zespół nie może sam zadecydować, że będzie jeszcze pracował nad systemem do skanowania biletów przez pół roku, jeżeli budżetu mamy na dwa miesiące, albo chcemy go użyć na koncercie w następnym kwartale. Oczywiście nie oznacza to, że PO dostanie wszystko co by chciał, ale w przypadku Scruma, przynajmniej najważniejszą funkcjonalność. Na przykład, żeby skaner robił „bip” przy każdym kodzie kreskowym. Na pierwszą imprezę powinno wystarczyć.
Ograniczenia procesowe
Również Scrum Master jest odpowiedzialny za pilnowania ograniczeń wynikających przede wszystkim z filarów Scruma. Pierwszy filar Scruma, przejrzystość (transparency), ma za zadanie pokazanie rzeczywistego stanu prac, procesu i produktu. Ta informacja jest podstawą drugiego filaru, czyli inspekcji (inspect). Dzięki niemu zarówno Zespół jak i Product Owner analizują rzeczywistą sytuację i podejmują odpowiednie kroki, czyli adaptują (adapt) swoje działania do nowo zdobytej wiedzy. Te cele są najczęściej realizowane przy pomocy codziennych spotkań (Daily Scrum), tablicy zadań (Task Board), wykresów spalania (Burndown charts), Przeglądu Sprintu (Sprint Review) i Retrospektywy. Oczywiście nie oznacza to, że Zespół Scrum musi ograniczać się tylko do tych narzędzi. Jeżeli największym problemem są błędy, to należy je uwidocznić (przejrzystość), przeanalizować (inspekcja) i wyeliminować (adapcja). Z drugiej strony, bez ograniczeń wynikających ze Scruma zespół może zorganizować sie z powrotem do podejścia kaskadowego, zrezygnować z testów, lub dyskutować na temat architektury przez trzy miesiące.
Ograniczenia jakościowe
Kolejne cele wynikają z dążenia do dostarczania działającego produktu na koniec każdej iteracji. Bardzo ciężko to zrobić nie posiadając środowiska do ciągłej integracji (Continuous Integration, CI), czy zautomatyzowanych testów. Zespół musi więc wprowadzić odpowiednie praktyki inżynieryjne, które zapewnią dostarczanie działającego produktu (potentially shipable product increment) na koniec każdej iteracji. I znowu rolą Scrum Mastera jest wspieranie członków zespołu, pokazywanie im praktyk inżynieryjnych, programowanie w parach i pomoc w rozszerzaniu Definicji Ukończenia (Definition-of-Done, DoD). W przeciwnym przypadku, jeden z deweloperów usunie wszystkie testy jednostkowe, bo mu przeszkadzają; albo system do rezerwacji biletów kolejowych nie będzie działał przez tydzień, bo nie wytrzymuje obciążenia.
Otoczenie zespołu
Kim są członkowie zespołu? Gdzie siedzą? Jakie mają dostępne narzędzia? Kolejną rzeczą, na którą mają wpływ managerowie to otoczenie zespołu i jego struktura. Przepisy HR mogą wspomagać współpracę, ale też mogą ją równie skutecznie zabijać, wprowadzając ocenę roczną i każąc porównywać członków zespołu między sobą i nagradzać ich za indywidualne wyniki. A jeżeli zarządca budynku nie zgodzi się na przykręcenie tablicy do ściany to najwyższa pora, byś wkroczył do akcji.
Bezpieczeństwo
Czytałeś może „Władcę Much” Williama Goldinga, albo widziałeś ekranizację książki (Much przez „u”, nie chodzi mi o ten polski animowany serial)? Grupa chłopców ląduje na bezludnej wyspie. Sprawnie organizują się, rozpalają ogień, zdobywają jedzenie. Jednak wkrótce pojawiają się konflikty, a samoorganizacja prowadzi do tyrani i śmierci jednego z dzieci. Raczej nie jest to efekt, który jest pożądany w Twojej organizacji. Dlatego jednym z obowiązków managerów jest zapewnienie bezpieczeństwa członkom zespołu. Jeżeli ktoś stanowi bezpośrednie zagrożenie, zachowuje się agresywnie w stosunku do innych, oszukuje lub okrada firmę, to trzeba go natychmiast usunąć, a nie czekać aż zespół sam rozwiąże problem. Jeżeli nie ma niebezpieczeństwa, to możesz pomóc zespołowi zaadresować sytuację, pamiętając jednak, że w pewnym momencie może być niezbędna interwencja kogoś z zewnątrz. Tak samo możesz być odpowiedzialny za podział wspólnych zasobów takich jak budżetu przestrzeni biurowej czy spinaczy.
Samorządność też jest ok
Oczywiście nie oznacza to wcale, że samorządność (self-governance), czyli wyznaczanie celów i ograniczeń przez sam zespół jest złe. Większość start-upów, czy freelancerów określa je samodzielnie. W Valve ludzie sami wybierają projekty nad którymi pracują. To od organizacji zależy jakie ograniczenia wprowadzi, a jakie decyzje pozostawi zespołom. Zależy to od rodzaju organizacji, jej modelu biznesowego, klientów, struktury i kultury. I to, co sprawdza się w niektórych firmach, może nie sprawdzić się w pozostałych.
P.S. Wszystkie powyższe przykłady są z życia wzięte…
