januszew.ski

  • English

Tag: scrum

Myśli, którymi chciałbym się podzielić o Scrumie i roli Scrum Mastera

  • rePlan: Dlaczego Twoja tablica w Jira kłamie, czyli jak odzyskać kontrolę nad Sprintem

    rePlan: Dlaczego Twoja tablica w Jira kłamie, czyli jak odzyskać kontrolę nad Sprintem

    Znasz to uczucie? Kończy się Planowanie Sprintu. Zespół „zakomitował się” do celu. W Jirze (lub Azure DevOps) wszystko świeci się na niebiesko w kolumnie „To Do”. Wygląda to jak plan. Ale czy nim jest?

    W rzeczywistości to tylko lista życzeń. Jira świetnie odpowiada na pytanie „CO” mamy do zrobienia. Ale milczy w kwestii tego, „JAK”, „KIEDY” i „Z KIM” to zrobimy.

    Przez lata pracy jako Scrum Master, Agile Coach i Enterprise Transformation Coach w dużych organizacjach (od telekomów po bankowość) widziałem ten sam schemat: silosy kompetencyjne, efekt „ja swoje zrobiłem, teraz ty się martw” i panika w ostatnich dwóch dniach sprintu.

    Dlatego stworzyłem rePlan. Narzędzie banalne w swojej konstrukcji, ale rewolucyjne w skutkach. To nie jest kolejny plugin. To zmiana mentalna.

    Czym w ogóle jest rePlan?

    Wyobraź sobie prostą siatkę.

    • Wiersze: To Twoi ludzie. Janek, Kasia, Bartek, Zosia.
    • Kolumny: To dni Sprintu. Poniedziałek, Wtorek… aż do Review.

    To nie jest Gantt, którego tworzy manager i narzuca zespołowi. To plansza do gry zespołowej, którą zespół wypełnia sam. Podczas planowania nanosimy na nią:

    1. Dostępność: Urlopy, szkolenia, wyjścia do lekarza (realna pojemność).
    2. Zadania w czasie: Kreski oznaczające, kiedy planujemy pracować nad danym Story.
    3. Zależności: Jeśli Kasia potrzebuje kodu od Janka, jej zadanie nie może zacząć się wcześniej, niż skończy się zadanie Janka.

    Brzmi prosto? Siła tkwi w tym, co dzieje się później.

    Efekt 1: Śmierć „Bohatera” i narodziny „Roju” (Swarming)

    W tradycyjnym podejściu developer bierze zadanie i znika na 3 dni. Na rePlan widać to jako długą, samotną linię. Zespół od razu to widzi: „Hej, Marek, zajmujesz się tym gigantem przez pół sprintu sam. Co jak zachorujesz? Co jak utkniesz?”.

    rePlan naturalnie wymusza Swarming (pracę roju). Zamiast jednej długiej linii, zespół zaczyna rysować dwie lub trzy krótsze, równoległe linie przy tym samym temacie.

    Zysk: Wiedza nie jest uwięziona w głowie jednej osoby (Bus Factor), a zadania są zamykane szybciej.

    Efekt 2: Daily Scrum przestaje być spowiedzią

    Większość spotkań Daily Scrum to status meetingi: „Wczoraj zrobiłem X, dziś zrobię Y”. Nuda. I strata czasu.

    Z rePlanem Daily zmienia się w taktyczną odprawę. Patrzymy na tablicę:

    • „Mieliśmy skończyć ten moduł wczoraj (widać koniec linii na wtorku), a jest środa i wciąż to robimy. Linia przesuwa się w prawo. Co to oznacza dla reszty sprintu?”
    • „Widzę, że jutro Zosia ma szkolenie, a Bartek czeka na jej Code Review. Mamy korek. Kto inny może to sprawdzić?”

    Dyskusja przenosi się z przeszłości („co zrobiłem”) na przyszłość i zarządzanie ryzykiem („czy zdążymy”).

    Efekt 3: Koniec z „Testing Squeeze”

    Klasyczny problem: Developerzy kodują przez 8 dni sprintu, a Testerzy mają 2 dni na sprawdzenie wszystkiego. W Jirze tego nie widać, dopóki zadania nie wpadną do kolumny „Ready for Test”.

    Na rePlan widać to w sekundę podczas planowania. Jeśli linie u Developerów są pełne do czwartku, a linie u Testerów puste na początku sprintu, a przeładowane na końcu – tablica krzyczy, że plan jest nierealny.
    Wymusza to wcześniejsze angażowanie testerów lub rozbijanie historyjek tak, by testować je od 2-3 dnia sprintu.

    Dodatkowo zespół łatwo przechodzi do trybu pracy, kiedy to podczas rozpoczynania prac nad danym tematem testerzy zaczynają definiować jak będzie on testowany. W efekcie na koniec pozostaje tylko wykonanie zdefiniowanego już testu.

    Case Study: Transformacja w finansach

    Jako Enterprise Agile Coach pracowałem z dużym Tribe’em (ok. 16 zespołów), który zmagał się z brakiem przewidywalności i niskim zaangażowaniem.

    Sytuacja PRZED:
    Zespoły dowoziły „punkty”, ale nie dowoziły wartości. Integracja rozwiązań następowała rzadko i boleśnie. Panował podział: „My devowie, Wy biznes”.

    Wdrożenie rePlan:
    Wprowadziłem rePlan nie jako narzędzie kontroli, ale jako narzędzie uzgadniania rzeczywistości.

    1. Na początku był opór. „To mikrozarządzanie!”. „Szkoda czasu na rysowanie kresek”.
    2. Przełom nastąpił, gdy jeden z zespołów dzięki tablicy zauważył w połowie sprintu, że przez nieobecność kluczowego architekta nie dowiozą Celu. Zamiast udawać, że jest OK, zmienili zakres w trakcie sprintu, informując Product Ownera.
    3. Sprint zakończył się sukcesem, bo dowieźli to, co najważniejsze, bez nadgodzin. Inne zespoły to zauważyły.

    Efekty PO 3 miesiącach:​

    • Time to Market (TTM) skrócony o 35%: Dzięki wizualizacji zależności zespoły przestały się blokować. Czas oczekiwania (Waste) został drastycznie zredukowany.
    • Wzrost zaangażowania o 40%: Ludzie poczuli, że mają wpływ na plan. To nie był plan managera, to był ich plan, ułożony na ich zasadach.
    • Kultura planowania z kontekstem celów: Zespoły przestały planować „zamykanie tasków”, a zaczęły planować „osiągnięcie celu” w konkretnym czasie.

    Skalowanie: rePlan na poziomie wielu zespołów

    Siła rePlan rośnie wykładniczo, gdy położymy kilka tablic obok siebie (np. na wirtualnej tablicy Miro dla całego Tribe’u).

    Jeśli Zespół A buduje API dla Zespołu B, to na zwykłym planowaniu słyszymy: „Dostarczymy to w tym sprincie”.
    Na zintegrowanym rePlan widać:

    • Zespół A planuje skończyć API w piątek.
    • Zespół B planuje użyć tego API w środę.

    Wizualizacja pokazuje kolizję zanim napisana zostanie pierwsza linijka kodu. Dzięki temu zespoły mogą negocjować kolejność prac przed startem sprintu, co jest kluczowe dla budowania zintegrowanego przyrostu w dużych organizacjach.

    Podsumowanie: Od Silosów do Współpracy

    rePlan leczy najcięższą chorobę zespołów Agile – samotność w tłumie.
    Rozbija silosy, bo pokazuje, że pusta kratka w moim wierszu to okazja, by pomóc koledze, który w swoim wierszu „tonie”.

    Zmienia narrację z „Ja zrobiłem swoje zadanie” na „My zrealizowaliśmy nasz plan”. I o to w tym wszystkim chodzi.

  • Kciukologika Sprintowa

    Kciukologika Sprintowa

    czyli jak jeden palec zmienia cały Daily

    O co chodzi?

    Wprowadzam tę mikro-technikę od lat w różnych zespołach, i za każdym razem widzę te same zaskoczone miny: „Naprawdę? To takie proste?”. Tak, to takie proste. I właśnie w tej prostocie tkwi cała siła.

    Pytanie: „Jak bardzo jesteśmy pewni, że dowieziemy cel sprintu?”
    Odpowiedź: kciuk w górę 👍 lub kciuk w dół 👎.

    Zero dyskusji, zero niuansów – czysta binarka. Po minucie już wiemy, czy mamy zieloną, czy czerwoną lampkę. Nie ma „może”, „prawdopodobnie”, „zależy od…”. Jest pewność lub jej brak. Jest zespół, który czuje się komfortowo z obecnym stanem rzeczy, lub zespół, który sygnalizuje niepokój.

    To nie jest głosowanie demokratyczne – to temperatura zespołu. Jeden kciuk w dół w pięcioosobowym zespole to już sygnał, że warto się zatrzymać i porozmawiać. Trzy kciuki w dół to sygnał, że sprint ma poważny problem.

    Dlaczego to działa? (Zyski)

    Błyskawiczna diagnoza zespołu

    W 5 sekund widzisz temperaturę sprintu – termometr projektu bez wchodzenia w Jira-labirynt. Nie musisz analizować burn-down chartów, liczyć story pointów czy sprawdzać, ile tasków jest w kolumnie „In Progress”. Patrzysz na kciuki i od razu wiesz, czy zespół czuje się pewnie, czy ma wątpliwości.

    Ta szybkość diagnostyki to nie tylko kwestia efektywności – to także kwestia psychologiczna. Zespół od pierwszej sekundy Daily wie, że będzie miał okazję wyrazić swoje obawy w bezpieczny sposób. Nie musi czekać na koniec, nie musi przerywać komuś opowieści o swoich taskach.

    Psychologiczny „ice-breaker”

    Palce rozgrzane, języki też – łatwiej zacząć konkretne rozmowy po symbolicznym geście. Jest w tym coś z rytuału, coś z zabawy, ale także coś z wspólnotowości. Wszyscy robimy ten sam gest, w tym samym momencie. To buduje poczucie, że jesteśmy jednym zespołem, a nie zbiorem indywidualnych wykonawców.

    Zauważyłem, że po wprowadzeniu tej techniki ludzie częściej się uśmiechają na początku Daily. Może to przez ten element gamifikacji, a może przez to, że wiedzą – mają bezpieczną przestrzeń do wyrażania wątpliwości.

    Wspólna odpowiedzialność za cel

    Każdy kciuk to głos, „my” dowozimy cel, nie „oni z backendu” czy „frontend znowu nie nadąża”. To bardzo subtelne, ale potężne przesunięcie w myśleniu. Kiedy cały zespół pokazuje kciuk w dół, nikt nie szuka winnego – wszyscy czują się odpowiedzialni za znalezienie rozwiązania.

    Wczesny system ostrzegawczy

    Pierwszy 👎 często pojawia się kilka dni wcześniej niż pierwszy czerwony wykres w Sonarze czy pierwsze opóźnienie w harmonogramie. To jak kanarkowe ptaki w kopalni – zespół wyczuwa problemy intuicyjnie, zanim pojawią się w metrykach.

    Przez lata obserwacji zauważyłem, że doświadczeni developerzy mają niesamowitą intuicję co do tego, czy sprint będzie udany. Często nie potrafią tego racjonalnie wytłumaczyć, ale czują, że coś jest nie tak. Kciuk w dół to kanał dla tej intuicji.

    Lek na „Daily-sleepy-syndrom”

    Ruch i micro-gamification podnoszą tętno spotkania. Zamiast ospalego mamrotania „wczoraj robiłem to, dziś będę robić tamto”, mamy moment aktywności, moment w którym wszyscy jednocześnie muszą się zastanowić nad stanem sprintu i wyrazić swoją opinię.

    Skąd się biorą kciuki w dół? (Powody)

    Niepewne wymagania

    „Jeszcze nie wiemy, jakie pola ma mieć raport PDF… a już połowa sprintu za nami”. To klasyk – user story wydawała się jasna podczas planowania, ale w trakcie implementacji okazuje się, że kryje dziesiątki szczegółów, o których nikt nie pomyślał.

    Symptomy: Deweloperzy zadają coraz więcej pytań, Product Owner odpowiada „sprawdzę i wrócę do Was”, a zadania wiszą w „In Progress” bez postępu.

    Blokery techniczne

    Środowisko testowe znowu wstało lewą VM-ą, API zewnętrznego dostawcy działa „czasami”, a baza danych testowa ma dane z epoki kamienia łupanego. Techniczne przeszkody, które paraliżują pracę zespołu.

    Symptomy: Ludzie siedzą przed ekranami, ale nie mogą wykonać swojej pracy. Slack wypełnia się wiadomościami „u mnie też nie działa” i „ktoś już zgłosił do IT?”.

    Nadmierny zakres

    Klasyk: Product Owner dorzucił „tylko drobną poprawkę” wielkości Godzilli. Albo okazało się, że „proste” zadanie wymaga refactoringu połowy aplikacji. Scope creep w najczystszej postaci.

    Symptomy: Zadania, które miały być „małe”, rosną jak na drożdżach. Estymaty okazują się śmiesznie niskie. Zespół ma wrażenie, że sprint się „rozlewa”.

    Niedostępność kluczowej osoby

    Dev Ops na urlopie, a my bez merge’ów jak bez kawy. Architekt zachorował w kluczowym momencie. Product Owner wyjechał na konferencję akurat wtedy, gdy potrzebujemy jego decyzji.

    Symptomy: Decyzje się nie podejmują, praca stoi, ludzie improwizują rozwiązania, które mogą nie być optymalne.

    Zbyt optymistyczne estymaty

    Yesterday’s weather? Wczoraj chyba świeciło słońce na Marsie. Zespół niedoszacował złożoność, nie wziął pod uwagę wszystkich zależności, zapomniał o testach czy nie przewidział komplikacji integracyjnych.

    Symptomy: Burn-down chart przypomina raczej „burn-up”, ludzie pracują nadgodziny, a mimo to zadania się nie domykają.

    Kciuk w dół? Co dalej? (Scenariusze)

    Kiedy widzisz kciuk w dół – lub kilka kciuków w dół – nie panikuj. To nie jest wyrok. To jest zaproszenie do rozmowy.

    Pierwsza reakcja powinna być prosta: „Dlaczego?„

    Nie „kto jest winny”, nie „co robiliśmy źle”, tylko po prostu: dlaczego czujesz, że możemy nie dowieźć celu sprintu? To pytanie powinno być zadane w bezpiecznej atmosferze, bez oskarżeń czy presji. Każdy kciuk w dół to cenny sygnał, a nie powód do wstydu.

    Faza pierwsza: Zrozumienie

    Daj zespołowi przestrzeń do wyrażenia obaw. Czasami okaże się, że to tylko mglisty niepokój – „coś mi się nie podoba, ale nie wiem co”. Czasami to konkretny problem – „API nie działa od wczoraj”. Czasami to intuicja – „mam wrażenie, że to zadanie jest większe niż myśleliśmy”.

    Wszystkie te sygnały są wartościowe. Nawet mglisty niepokój często okazuje się dobrze uzasadniony, gdy zespół wspólnie go przeanalizuje.

    Faza druga: Poszukiwanie rozwiązań

    Po zrozumieniu problemu przychodzi czas na drugie kluczowe pytanie: „Co możemy zrobić?„

    Nie „co powinniśmy zrobić” – to brzmi jak przykazanie z góry. Nie „co musimy zrobić” – to brzmi jak kara. Tylko „co możemy zrobić” – to brzmi jak zaproszenie do współpracy.

    W tej fazie mogą pojawić się różne rozwiązania:

    • Zmniejszenie zakresu sprintu
    • Przeniesienie części zadań do następnego sprintu
    • Poproszenie o pomoc innych zespołów
    • Zmiana podejścia technicznego
    • Eskalacja blokera do management
    • Doprecyzowanie wymagań z Product Ownerem

    Faza trzecia: Kolejny kciuk

    Po przedyskutowaniu problemów i potencjalnych rozwiązań, zadaj pytanie ponownie: „Jak teraz czujecie się z celem sprintu?”

    To nie jest formalność – to sprawdzenie, czy zespół naprawdę czuje się lepiej po rozmowie. Czasami okaże się, że dyskusja pomogła i kciuki idą w górę. Czasami okaże się, że problemy są głębsze i nadal mamy kciuki w dół.

    Oba scenariusze są w porządku. Ważne, że mamy prawdziwą informację o stanie zespołu, nie iluzoryczną pewność.

    Kiedy kciuki nadal są w dół

    Jeśli po rozmowie i poszukiwaniu rozwiązań zespół nadal pokazuje kciuki w dół, to może oznaczać, że:

    • Problem jest poważniejszy niż początkowo sądziliśmy
    • Potrzebujemy więcej czasu na implementację rozwiązania
    • Cel sprintu rzeczywiście jest zagrożony

    I to też jest wartościowa informacja. Lepiej wiedzieć o tym na początku tygodnia niż w piątek po południu.

    Jak wprowadzić tę sztuczkę bez palców w drzwi?

    1. Opowiedz historię

    Ludzi przekonują anegdoty bardziej niż slajdy. Zamiast teoretyzować o korzyściach, opowiedz o konkretnym zespole, który dzięki tej technice uniknął katastrofy sprintowej. Albo o tym, jak kciuk w dół jednego developera uratował cały release.

    2. Zacznij od siebie

    Pierwszy podnieś kciuk (albo opuść, jeśli trzeba). Pokaż, że to normalne, że Scrum Master też może mieć wątpliwości. Jeśli zespół zobaczy, że nie boisz się pokazać niepewności, będzie mu łatwiej zrobić to samo.

    3. Nie interpretuj publicznie pojedynczych kciuków

    Czerwony palec ≠ czerwony Dev. Nie mów „widzę, że Michał ma wątpliwości”. Skup się na ogólnym obrazie: „widzę kilka kciuków w dół, porozmawiajmy o obawach zespołu”.

    4. Dbaj o bezpieczeństwo psychologiczne

    Palec w dół to prezent, nie wstyd. Podkreślaj, że sygnalizowanie problemów to odpowiedzialność każdego członka zespołu. Dziękuj za szczerość, nie krytykuj za „pesymizm”.

    5. Śledź trend, nie punkt

    Trzy kolejne sprinty na zielono? Można luzować pasek. Trzy czerwone? Czas na poważniejsze zmiany. Jeden kciuk w dół to informacja, trend kciuków w dół to sygnał do działania.

    6. Dostosuj do kultury zespołu

    W niektórych zespołach lepiej sprawdzi się pięć palców (od 1 do 5), w innych kolory (zielony/żółty/czerwony). Ważna jest idea – szybka, wizualna, bezpieczna komunikacja o stanie sprintu.

    Podsumowanie

    W dobie zaawansowanych dashboardów, AI-predictorów i innych cudów technologicznych, mały kciuk nadal może zdziałać cuda. To nie jest kolejny framework czy metodologia – to po prostu narzędzie do szybkiej komunikacji. Proste, skuteczne, ludzkie.

    Spróbujcie jutro na Daily. Zadajcie pytanie, zobaczcie kciuki, porozmawiajcie o tym, co zobaczycie. Najwyżej… pokażecie mi kciuk w dół – i też będzie dobrze, bo coś się dowiemy. 😉

    Pamiętajcie: cel to nie zielone kciuki za wszelką cenę. Cel to prawdziwa informacja o stanie sprintu i zespole, który czuje się komfortowo z mówieniem prawdy. Kciuk w dół to nie porażka – to starting point dla lepszego sprintu.

    Na zdrowie sprintom – i Waszym palcom!

  • Warsztat: Instrukcja obsługi zespołu

    Warsztat: Instrukcja obsługi zespołu

    Abstrakt

    Dokument opisuje zasady prowadzenia ćwiczenia z zakresu budowania zespołu, które polega na przeprowadzeniu sesji tworzenia autoprezentacji w formie instrukcji obsługi. Pisząc ten dokument, myślę o zespole Agile z prowadzącym Scrum Masterem, ale może być aplikowany do dowolnych zespołów – od korporacyjnych po startup’owe, od zdalnych po tradycyjnie biurowe.

    Jaki cel ma ćwiczenie?

    Cel jest prosty jak budowa młotka: lepsze poznanie siebie i zespołu. Brzmi jak truizm? Może trochę, ale w praktyce okazuje się, że większość z nas pracuje ramię w ramię z ludźmi, o których wie tyle, ile o sąsiadach – czyli praktycznie nic poza tym, że są i czasem się odzywają.

    Ćwiczenie ma na celu:

    • Przełamanie barier komunikacyjnych – bo łatwiej rozmawiać z kimś, kogo trochę znasz
    • Zrozumienie preferencji współpracy – jedni lubią cisze, drudzy burze mózgów, trzeci potrzebują kawy co godzinę
    • Odkrycie ukrytych talentów – może okaże się, że kolega z IT świetnie gra na gitarze, a koleżanka z HR ma patent na uspokajanie zdenerwowanych klientów
    • Stworzenie atmosfery zaufania – gdy ludzie wiedzą, że możesz „zwariować” po trzech nieudanych deploymentach, łatwiej ci pomoże
    • Zwiększenie empatii w zespole – rozumienie, że każdy ma swoje mocne i słabe strony

    Jakich efektów można oczekiwać?

    Efekty sprawdzają się jak szwajcarski zegarek – pod warunkiem, że zespół podchodzi do sprawy z otwartością większą niż okno w letni dzień.

    Efekty krótkoterminowe (widoczne od razu):

    • Rozluźnienie atmosfery – ludzie się śmieją, żartują, okazuje się, że praca to nie tylko deadline’y i stres
    • Lepsze zrozumienie ról – każdy wie, kto za co odpowiada i w czym może pomóc
    • Wzrost komfortu komunikacji – łatwiej poprosić o pomoc, gdy wiesz, że druga osoba lubi pomagać
    • Odkrycie wspólnych zainteresowań – może znajdziecie się fani tej samej książki, filmu czy gry

    Efekty średnioterminowe (po kilku tygodniach):

    • Poprawa jakości komunikacji – ludzie wiedzą, jak się do siebie zwracać, żeby być zrozumianym
    • Zwiększenie skuteczności współpracy – mniej nieporozumień, więcej synergii
    • Lepsze rozwiązywanie konfliktów – łatwiej zrozumieć punkt widzenia drugiej strony
    • Wzrost zaangażowania – ludzie chętniej współpracują z tymi, których znają

    Efekty długoterminowe (po miesiącach):

    • Silniejsze więzi zespołowe – zespół staje się więcej niż sumą swoich części
    • Wyższa produktywność – mniej czasu na wyjaśnianie, więcej na działanie
    • Lepsze zarządzanie stresem – ludzie wiedzą, jak wspierać się nawzajem
    • Zwiększona retencja – ludzie zostają tam, gdzie czują się dobrze

    Założenia

    Zanim przejdziemy do konkretów, ustalmy zasady gry – bo bez nich to jak granie w piłkę bez bramek:

    • W ćwiczeniu bierze udział moderator i zespół – moderator to ten, który pilnuje, żeby nikt nie uciekł z sali
    • Zespół może brać udział zarówno lokalnie, jak i zdalnie – pandemia nauczyła nas, że można robić wiele rzeczy przez ekran
    • Sesja nie ma ograniczeń liczby osób – sprawdza się od 3 do 30 osób, choć z większymi grupami moderator potrzebuje więcej cierpliwości
    • Ćwiczenie jest prowadzone w formie lekkiej zabawy – żadnego korporacyjnego patosu, tylko luz i śmiech
    • Z ćwiczenia nie będą wyciągane konsekwencje – to nie jest ocena pracownicza, tylko poznawanie się
    • Instrukcje nie będą opracowywane poza zespołem – są pisane przez zespół i dla zespołu, punkt

    Przebieg sesji

    Sesja ma swoją choreografię – nie tak skomplikowaną jak balet, ale strukturę ma:

    Wprowadzenie (10-15 minut)

    • Moderator tłumaczy cel ćwiczenia – lepsze poznanie siebie i zespołu, bez korporacyjnego bełkotu
    • Moderator przedstawia założenia – żeby wszyscy wiedzieli, na co się piszą
    • Moderator pokazuje przykładową instrukcję oraz proponowany szablon – bo bez wzorca to jak gotowanie bez przepisu
    • Moderator wzbudza dyskusję nad ćwiczeniem – zachęca do aktywnego udziału, ale nie zmusza jak sprzedawca odkurzaczy

    Właściwe ćwiczenie (30-45 minut)

    • Ćwiczenie rozpoczyna się wyborem – „To kto chce być pralką?” – i tu zazwyczaj pada pierwsza seria śmiechu
    • Każdy pisze swoją instrukcję – może samodzielnie, w parach lub małych grupach
    • Moderator krąży i wspiera – odpowiada na pytania, dodaje otuchy, pilnuje czasu

    Prezentacja i dyskusja (20-30 minut)

    • Zespół czyta instrukcje – każdy prezentuje swoją lub grupa prezentuje wspólną
    • Omawianie wniosków – bez głębokiej analizy, ale w formie zabawy
    • Komentarze i pytania – „Aha, więc dlatego zawsze prosisz o wszystko mailowo!”

    Zakończenie (5-10 minut)

    • Całość instrukcji jest archiwizowana w zespole – można do nich czasem wracać, szczególnie gdy dołącza nowa osoba
    • Podsumowanie – krótkie, pozytywne, bez przemów

    Zalecenia

    Żeby nie wpaść w korporacyjne pułapki, warto pamiętać o kilku rzeczach:

    1. Sesja powinna zostać wcześniej zapowiedziana, a udział w niej dobrowolny – nikt nie lubi niespodzianek, szczególnie w pracy
    2. Moderator powinien mieć przygotowaną instrukcję – żeby wyznaczyć poziom, pokazać lekkość i oczekiwania od zadania
    3. Posiadanie instrukcji nie zwalnia moderatora z pisania – jeśli chcesz, żeby inni się otworzyli, sam musisz dać przykład
    4. Nie należy narzucać sposobu wykonania – może być samodzielny, w parach czy grupach, choć samodzielny jest najbardziej oczekiwany
    5. Moderator powinien dostarczyć wzory – wydrukowane instrukcje obsługi sprzętów lub chociaż zdjęcia
    6. Instrukcje powinny być zróżnicowane – pralka, telewizor, smartfon, ekspres do kawy – im więcej różnorodności, tym lepiej
    7. Nowa osoba w zespole może uzupełnić zestaw – świetny sposób na integrację nowicjuszy

    Przykładowy szablon instrukcji

    Nazwa urządzenia: Roman 2000 Full-Stack
    Model: Programista uniwersalny z funkcją debugowania
    Klasa energetyczna: A+ (po kawie), C (przed poranną dawką kofeiny)

    1. Przeznaczenie „urządzenia”

    Roman 2000 Full-Stack to zaawansowany model programisty przystosowany do obsługi projektów od frontendu po backend. Idealny do pracy w zespołach Agile, gdzie wymagana jest elastyczność i szybkie przełączanie między różnymi technologiami. Posiada wbudowany moduł rozwiązywania problemów i funkcję automatycznego uspokajania zdenerwowanych klientów.

    2. Zasady „instalacji”

    Przed pierwszym użyciem:

    • Zapewnić dostęp do kawy wysokiej jakości (minimum 2 filiżanki dziennie)
    • Przygotować stanowisko z dwoma monitorami (trzeci monitor zwiększa wydajność o 30%)
    • Zainstalować Slack, ale ograniczyć powiadomienia do pilnych spraw
    • Umieścić w pomieszczeniu z naturalnymi źródłami światła
    • Zapewnić dostęp do internetu (urządzenie bez internetu to jak pralka bez wody)

    Konfiguracja początkowa:

    • Pierwszego dnia pokazać, gdzie jest najlepsza kawa w biurze
    • Przedstawić zespół i jego specjalizacje
    • Udostępnić dokumentację projektów
    • Ustawić spotkanie 1:1 z bezpośrednim przełożonym

    3. Opis funkcji i możliwości

    Funkcje podstawowe:

    • Programowanie w JavaScript, Python, Java
    • Debugowanie kodu (własnego i cudzego)
    • Code review z konstruktywnymi komentarzami
    • Architektura systemów od zera

    Funkcje dodatkowe:

    • Tłumaczenie wymagań biznesowych na język techniczny
    • Uspokajanie zdenerwowanych PM-ów
    • Automatyczne wykrywanie potencjalnych problemów w kodzie
    • Funkcja mentorowania juniorów (aktywuje się po 2 latach doświadczenia)

    Tryby pracy:

    • Tryb głębokiego fokus – najwyższa produktywność, nie przeszkadzać
    • Tryb współpracy – dostępny do dyskusji i pair programmingu
    • Tryb kreatywny – generuje innowacyjne rozwiązania
    • Tryb awaryjny – uruchamia się automatycznie przy krytycznych bugach

    4. Warunki użytkowania

    Optymalne warunki pracy:

    • Temperatura: 20-22°C (może pracować w szerszym zakresie, ale narzeka)
    • Wilgotność: nie krytyczna, ale suche powietrze może powodować elektryzowanie się przy dotykaniu klawiatury
    • Oświetlenie: naturalne światło + lampka biurkowa
    • Poziom hałasu: maksymalnie średni (słuchawki z noise cancellation załączone w zestawie)

    Godziny pracy:

    • Szczytowa wydajność: 9:00-12:00 i 14:00-17:00
    • Tryb slow-start: 8:00-9:00 (wymagana kawa)
    • Tryb awaryjny: dostępny po godzinach w krytycznych sytuacjach

    Sposób komunikacji:

    • Slack dla szybkich pytań
    • Email dla formalnych spraw
    • Rozmowa twarzą w twarz dla skomplikowanych problemów
    • Karta Jira dla zadań do wykonania

    5. Wykrywanie problemów

    Sygnały ostrzegawcze:

    • Nadmierne używanie słów „refaktor” i „to trzeba przepisać”
    • Zwiększona konsumpcja kawy (powyżej 4 filiżanek dziennie)
    • Mamrotanie pod nosem podczas czytania cudzego kodu
    • Spontaniczne rysowanie diagramów na kartce/tablicy
    • Częste sprawdzanie Stack Overflow

    Komunikaty błędów:

    • „To nie będzie działać” – oznacza konieczność przedyskutowania rozwiązania
    • „Hm, ciekawe…” – wykrył potencjalny problem, wymaga dalszej analizy
    • „Może spróbujmy inaczej” – obecne podejście wymaga zmiany
    • Cisza dłuższa niż 10 minut – prawdopodobnie wszedł w tryb głębokiego debugowania

    6. Warunki gwarancji

    Gwarancja zostanie utracona w przypadku:

    • Wymuszonego używania Internet Explorer do testowania
    • Zmian w kodzie bez code review
    • Spotkań dłuższych niż 1 godzinę bez konkretnego celu
    • Przerywania w trybie głębokiego fokus bez ważnego powodu
    • Braku aktualizacji dokumentacji przez dłuższy czas

    Zalecane konserwacje:

    • Cotygodniowe spotkania 1:1 z przełożonym
    • Miesięczne retrospektywy zespołu
    • Kwartalne przeglądy kodu i architektury
    • Roczne szkolenia z nowych technologii

    Aktualizacje:

    • Automatyczne pobieranie najnowszych wersji bibliotek
    • Regularne czytanie tech blogów i dokumentacji
    • Uczestnictwo w konferencjach programistycznych
    • Eksperymentowanie z nowymi technologiami w czasie wolnym

    Ostrzeżenia:

    • Nie wystawiać na długotrwały kontakt z legacy kodem bez odpowiednich zabezpieczeń
    • Unikać pracy w trybie ciągłego crunch time – może prowadzić do wypalenia
    • Nie pozostawiać bez nadzoru przy dostępie do produkcyjnej bazy danych

    Inne informacje

    Rozróżnienie pojęć – bo precyzja to podstawa:

    • Ćwiczenie – całość działania od zapowiedzi przez wykonanie aż do konsumowania efektów
    • Sesja – konkretne spotkanie, na którym tworzone są instrukcje

    Alternatywne podejście – jeśli zespół woli bardziej poważną formę, można zastosować podejście opisane przez Dominika Juszczyka, które zawiera elementy:

    • Kiedy jestem najlepszą wersją siebie – warunki, które pozwalają mi się rozwinąć
    • Wartość, jaką wnoszę do zespołu – moje mocne strony i umiejętności
    • Potrzebuję od Ciebie – co mi pomoże w pracy i współpracy
    • Możesz na mnie liczyć – w czym chętnie i skutecznie pomogę
    • Warto o mnie wiedzieć – dodatkowe informacje, ciekawostki, hobby

    Podsumowanie

    Instrukcja obsługi zespołu to nie kolejny korporacyjny wymysł, tylko praktyczne narzędzie poznania. Jak każde narzędzie – działa, gdy się go używa, a nie trzyma w szafie. Najważniejsze to pamiętać, że za każdym „urządzeniem” w zespole stoi człowiek z własnymi potrzebami, preferencjami i sposobem działania.

    A może najważniejsze odkrycie będzie takie, że kolega z działu obok też nie lubi poniedziałkowych spotkań o 8:00 rano. Czasem to właśnie takie małe rzeczy budują najsilniejsze więzi zespołowe.

  • Rekrutacja przez zespół – czyli jak przestać zgadywać, kto do nas pasuje

    Rekrutacja przez zespół – czyli jak przestać zgadywać, kto do nas pasuje

    Wyobraź sobie sytuację: HR przysyła ci nowego kolegę z komunikatem „Oto wasz nowy członek zespołu. Ma świetne CV i przeszedł wszystkie etapy rekrutacji”. A ty patrzysz na niego i myślisz „Okej, ale czy będę z nim mógł pracować przez następne dwa lata?”. Brzmi znajomo?

    Problem z tradycyjną rekrutacją

    Klasyczna rekrutacja to trochę jak kupowanie butów przez internet – na zdjęciu wyglądają świetnie, ale dopiero gdy je założysz, okazuje się, że uciskają w palcach. HR sprawdza kompetencje, manager sprawdza doświadczenie, a zespół? Zespół dowiaduje się o nowym członku w poniedziałek rano.

    Efekt? Nowy człowiek może być genialnym specjalistą, ale jeśli jego sposób komunikacji przypomina telegram z 1920 roku, a zespół lubi gadać o wszystkim i niczym podczas Daily – mamy problem. Albo odwrotnie – ktoś, kto potrzebuje ciszy jak mnich w klasztorze, trafia do zespołu, który dyskutuje każdy kawałek kodu jak eksperci od futbolu w telewizji.

    Rekrutacja przez zespół – jak to działa w praktyce

    W kilku firmach udało mi się przekonać ludzi do zupełnie innego podejścia. Proces wygląda tak:

    Etap 0: Rekruterzy przedstawiają kandydatów (opcjonalny)
    Klasyczne przesiewanie CV. Nic nowego pod słońcem.

    Etap 1: Krótka rozmowa techniczna
    Jeden ze specjalistów z zespołu rozmawia z kandydatem 30-45 minut. Cel? Sprawdzić poziom wiedzy i doświadczenia. Bez wchodzenia w szczegóły implementacji algorytmu sortowania bąbelkowego czy pytań typu „ile waży słoń w Javie”. Po prostu: czy ta osoba wie, o czym mówimy?

    Etap 2: Rozmowa z całym zespołem
    I tu dzieje się magia. Kandydat spotyka się z całym zespołem, w którym ma pracować. Wszyscy zadają pytania, wszyscy obserwują, wszyscy podejmują decyzję. To nie jest przesłuchanie – to poznawanie się.

    Etap 3: Rozmowa o kasie
    Manager liniowy ustala warunki finansowe. Koniec, kropka, podpis na umowie.

    Dlaczego to ma sens?

    Kiedy wprowadzałem ten system, zawsze pytałem kandydatów na koniec rozmowy: „Jak by się Pan/Pani czuł, gdyby następny etap to spotkanie z zespołem?”. I przedstawiałem argumenty:

    • Masz być częścią zespołu – więc niech zespół sprawdzi, czy twój charakter pasuje do tego, co sam o sobie opowiadasz
    • Masz przynieść wartość zespołowi – może pozwólmy zespołowi ocenić, czy widzi tę wartość
    • Jeśli zespół powie „Tak” – będziesz miał wsparcie od pierwszego dnia
    • Jeśli zespół powie „Nie” – cóż, nie ma sensu się męczyć

    Reakcje? Zawsze pozytywne. „Nigdy nie byłem na takiej rozmowie, ale widzę duży sens”. Niektórzy wyrażali obawy, ale stwierdzali, że warto spróbować.

    Przykłady z życia wzięte

    Przypadek pierwszy: Senior Developer z problemem komunikacyjnym
    Kandydat miał świetne CV – 8 lat doświadczenia, znał wszystkie frameworki na pamięć. Podczas rozmowy technicznej błyszczał. Ale gdy spotkał się z zespołem, okazało się, że jego sposób komunikacji to seria monologów. Zespół pracował w trybie ciągłych konsultacji i współpracy. Verdict? „Świetny specjalista, ale nie dla nas”.

    Przypadek drugi: Junior z potencjałem
    Młoda programistka, rok doświadczenia, CV skromne jak mniszka. Ale podczas spotkania z zespołem zadawała świetne pytania, słuchała uważnie, a jej energia była zaraźliwa. Zespół stwierdził: „Nauczymy ją wszystkiego, ale chcemy ją u siebie”. Rok później była jedną z najlepszych w zespole.

    Przypadek trzeci: Ekspert, który nie pasował kulturowo
    Kandydat z 15-letnim doświadczeniem, guru w swojej dziedzinie. Ale podczas rozmowy z zespołem wyszło, że jego podejście to „ja wiem lepiej, a wy się uczcie”. Zespół cenił sobie równość i wzajemne uczenie się. Mimo kompetencji – nie przeszedł.

    Co zespół sprawdza podczas takiej rozmowy?

    Chemię zespołową
    Czy ta osoba będzie pasować do naszego sposobu gadania, żartowania, rozwiązywania konfliktów? To nie jest pytanie o kompetencje – to pytanie o to, czy będziemy się lubić przez następne lata.

    Podejście do pracy
    Jeden zespół lubi długie dyskusje o architekturze, inny woli szybkie decyzje i iteracje. Jeden ceni sobie precyzję, inny eksperymentowanie. Kandydat może być genialny, ale jeśli jego styl pracy jest przeciwny do zespołowego – będzie cierpienie.

    Motywację i wartości
    Czy ta osoba chce się rozwijać w tym samym kierunku co zespół? Czy ma podobne podejście do jakości kodu, testowania, dokumentacji? Czy będzie ciągnąć zespół do przodu, czy hamować?

    Korzyści dla wszystkich

    Dla zespołu:

    • Mają wpływ na to, kto do nich dołącza
    • Biorą odpowiedzialność za integrację nowej osoby
    • Czują się współodpowiedzialni za sukces rekrutacji

    Dla kandydata:

    • Wie, z kim będzie pracować
    • Może ocenić, czy zespół mu odpowiada
    • Zaczyna z poparciem całej grupy

    Dla firmy:

    • Mniejsze ryzyko nietrafionej rekrutacji
    • Szybsza integracja nowych ludzi
    • Lepsze dopasowanie kulturowe

    Kiedy to nie działa?

    Ten system ma sens tylko w zespołach, które rzeczywiście współpracują. Jeśli ludzie siedzą w swoich norach i kontaktują się tylko przez Slacka, to rekrutacja przez zespół to strata czasu. Ale jeśli pracujecie razem, planujecie razem, rozwiązywacie problemy razem – to zespół wie najlepiej, kogo potrzebuje.

    Podsumowanie

    Zespół wie najlepiej, stanowi sam o sobie, podejmuje decyzje, podejmuje odpowiedzialność. Kto spróbował tego podejścia, chyba nigdy już nie wrócił do klasycznej rekrutacji. Bo po co zgadywać, skoro można zapytać tych, którzy będą pracować z nową osobą każdego dnia?

    Jak mówię zawsze – można budować zespoły na siłę, a można pozwolić im się budować samym. Drugie wyjście jest po prostu mądrzejsze.

  • Kanbanosis Acute: Czemu Kanban i Scrum Tworzą Toksyczny Związek

    Kanbanosis Acute: Czemu Kanban i Scrum Tworzą Toksyczny Związek

    Czy kiedykolwiek widziałeś zespół Scrumowy, który z dumą prezentuje swoją tablicę Kanban z dziesiątkami kolumn i karteczkami wędrującymi od osoby do osoby? Ja widziałem. I za każdym razem czuję, jakbym obserwował powolną katastrofę – coś, co nazywam „Kanbanosis Acute”. To jak oglądanie kogoś, kto próbuje jeździć rowerem, jednocześnie grając na akordeonie – teoretycznie możliwe, ale po co się tak męczyć?

    Tech Lead: „Obawiam się, że masz Kanbanosis Acute – ostrą odmianę kanbanozy.”
    Junior Dev: „Czy to poważne?”
    Tech Lead: „Zacząłeś organizować swoje testy jednostkowe, zamówienia kawy i emocje w kolumny Do Zrobienia, W Trakcie i Zrobione.”

    Łączenie Kanbana ze Scrumem to jeden z tych pomysłów, które na pierwszy rzut oka wydają się sensowne. W końcu oba podejścia należą do rodziny Agile, prawda? Problem w tym, że często prowadzi to do więcej zamieszania niż korzyści, a w skrajnych przypadkach może być jednym z powodów upadku zespołów Scrumowych i odwrotu od Agile w organizacjach.

    Dlaczego Kanban i Scrum to toksyczne małżeństwo?

    Scrum ze swojego założenia został stworzony do dostarczania wartości przy rozwiązywaniu skomplikowanych i złożonych problemów. Kanban na odwrót – do prostych i powtarzalnych zadań.  

    Sprint vs Flow – fundamentalny konflikt

    Scrum opiera się na sprintach, które z założenia zaczynają się „na czysto” (żadna praca nie jest w toku) i kończą się „na czysto” (wszystko zaplanowane jest wykonane). To jak przygotowywanie posiłków na cały tydzień w niedzielę – czysta lodówka na początku, pełna pojemników z jedzeniem na koniec.

    Tymczasem Kanban to ciągły przepływ, gdzie zadania płyną przez system jak woda przez rurę. Kiedy próbujemy wtłoczyć flow Kanbana w ramy sprintów, tracimy główną zaletę Kanbana – możliwość mierzenia stałości przepływu. To jak próba mierzenia przepływu rzeki, ale tylko w określonych tygodniach roku – dane będą niekompletne i mało użyteczne.

    Stabilizacja flow kosztem inspekcji i adaptacji

    Chęć ustabilizowania przepływu w Kanbanie często prowadzi zespoły do wydłużania sprintów. „Hej, może zróbmy trzytygodniowe sprinty zamiast dwutygodniowych, żeby lepiej zarządzać flow?” – słyszałem to wielokrotnie. Problem w tym, że dłuższe sprinty oznaczają rzadsze okazje do inspekcji i adaptacji – fundamentalnych elementów Scruma.

    To jak rzadsze wizyty u lekarza – możesz się czuć lepiej, bo rzadziej słyszysz złe wieści, ale nie oznacza to, że jesteś zdrowszy.

    Zespół jako jednostka vs indywidualne kolumny

    W Scrumie zespół powinien być traktowany jako jedna osoba ze wspólną odpowiedzialnością. Wszyscy razem wygrywają lub przegrywają. Tymczasem Kanban, szczególnie w tradycyjnym wydaniu, zachęca do tworzenia kolumn odpowiadających różnym etapom pracy, często przypisanym do konkretnych osób lub ról.

    „Analiza”, „Rozwój”, „Testy”, „Wdrożenie” – każda kolumna to potencjalne silos, a zadania są przekazywane między nimi jak gorący kartofel. Handover pracy w kontekście jednego zespołu po prostu nie ma sensu – to jak podawanie sobie piłki między lewą a prawą ręką.

    Specjalizacja vs cross-funkcjonalność

    Budowanie kolumn i przypisywanie do nich osób utrudnia współdziałanie całego zespołu. Gdy mamy kolumnę „Testy” przypisaną do testerów, programiści naturalnie skupiają się tylko na kolumnie „Rozwój”. To prowadzi do specjalizacji, która jest przeciwieństwem cross-funkcjonalności, do której dążymy w Scrumie.

    To jak mieć w domu osobę odpowiedzialną wyłącznie za odkurzanie, a inną tylko za mycie naczyń. Może i są ekspertami w swoich wąskich dziedzinach, ale co się stanie, gdy jedna z nich zachoruje?

    Najczęstsze błędy przy stosowaniu Kanbana w Scrumie:

    Zbyt wiele kolumn

    Najprostszy i najczęstszy błąd: tworzenie zbyt wielu kolumn. Widziałem tablice z kolumnami takimi jak „Do zrobienia”, „Analiza”, „Projektowanie”, „Rozwój”, „Code Review”, „Testy”, „Dokumentacja”, „Wdrożenie”, „Zrobione”. To nie tablica Kanban, to mapa metra!

    W większości przypadków wystarczą trzy kolumny: „Do zrobienia”, „W trakcie”, „Zrobione”. Wszystko ponad to często wprowadza sztuczne podziały i zachęca do przekazywania pracy zamiast współpracy.

    Obsesja na punkcie mierników przepływu

    Kanban oferuje wiele mierników: lead time, cycle time, throughput… Zespoły często skupiają się na tych miernikach kosztem tego, co naprawdę ważne – dostarczania wartości[3].

    „Nasz cycle time spadł o 15%!” – świetnie, ale czy klienci są zadowoleni z produktu? Czy rozwiązujemy właściwe problemy? Mierniki są jak termometr – przydatne do diagnozy, ale same w sobie nie leczą choroby.

    Push zamiast pull

    W prawdziwym Kanbanie zadania są „ciągnięte” (pull) przez system, a nie „pchane” (push). Jednak w praktyce często widzę, jak programiści kończą swoje zadanie i natychmiast przesuwają je do kolumny „Testy”, nawet jeśli testerzy są już przeciążeni pracą.

    To jak wrzucanie kolejnych naczyń do zlewu, mimo że jest już pełny – zamiast pomóc w zmywaniu. Prawdziwy Kanban wymaga dyscypliny i szacunku dla limitów pracy w toku (WIP), które często są ignorowane.

    Kiedy nie stosować Kanbana

    Zadania skomplikowane

    Kanban świetnie sprawdza się w przewidywalnych, powtarzalnych procesach. Pisanie oprogramowania rzadko takie jest. Każde zadanie może napotkać nieoczekiwane problemy, wymagać głębszego zrozumienia lub zmiany podejścia w trakcie realizacji.

    To jak stosowanie przepisu kulinarnego do eksperymentowania z nowymi potrawami – możesz mieć listę składników i kroków, ale prawdziwa magia dzieje się, gdy odchodzisz od przepisu i improwizujesz.

    Zadania wymagające współpracy wielu specjalności

    Jeśli twój zespół nie składa się wyłącznie z „pełnych stacków” (100% fullstack-QA-SEC-OPS), Kanban może prowadzić do silosów i opóźnień w handoverach. Współczesne wytwarzanie oprogramowania wymaga ścisłej współpracy między różnymi specjalnościami, a nie sekwencyjnego przekazywania pracy.

    Realizacja celów zamiast zadań

    User Stories, Epics i Features to nie są zadania, to cele użytkownika. Kanban jest świetny do zarządzania zadaniami, ale nie celami. Kiedy próbujemy wtłoczyć cele użytkownika w ramy Kanbana, często tracimy z oczu prawdziwy cel – dostarczanie wartości.

    Kiedy warto stosować Kanban

    Powtarzalne zadania

    Kanban narodził się w fabrykach Toyoty, gdzie procesy są powtarzalne i przewidywalne. Świetnie sprawdza się w obsłudze serwisowej, produkcji przemysłowej czy innych scenariuszach, gdzie zadania są podobne i dobrze zrozumiane.

    Proste zadania w dużej ilości

    Jeśli masz do wykonania setki prostych, podobnych zadań (jak obracanie monety czy składanie pudełek 😉 ), Kanban może pomóc w zarządzaniu przepływem i identyfikacji wąskich gardeł.

    Zadania wykonywalne przez każdego członka zespołu

    Kanban działa najlepiej, gdy każde zadanie może być podjęte przez dowolną osobę w zespole. W przeciwnym razie powstają wąskie gardła i zadania czekają na konkretne osoby, co niweluje korzyści z płynnego przepływu.

    Suma zgodności z powyższymi kryteriami

    Kanban warto stosować tylko wtedy, gdy 100% wykonywanych zadań spełnia powyższe kryteria. W przeciwnym razie ryzykujemy stworzenie systemu, który działa dobrze dla części pracy, ale utrudnia realizację pozostałej.

    Dodatkowe powody, by unikać Kanbana w Scrumie

    Rozmycie odpowiedzialności zespołowej

    Kanban może prowadzić do myślenia „to nie moje zadanie”, gdzie każdy odpowiada tylko za swoją kolumnę. To podważa fundamentalną zasadę Scruma o wspólnej odpowiedzialności zespołu za dostarczenie wartości.

    Utrata przejrzystości sprintów

    Sprinty w Scrumie dają jasną ramę czasową i zakres pracy, co ułatwia planowanie i zarządzanie oczekiwaniami. Dbanie o flow powoduje przenoszenie pomiędzy sprintami i nakładanie koncowych etapów na początek kolejnego sprintu. To z kolei rozwala przewidywalność zespołu i może powoli degradować zaufanie biznesu do developmentu.

    Jak uniknąć Kanbanosis Acute?

    Najlepiej… nie wprowadzaj Kanbana. a jeśli już musisz używać elementów Kanbana w Scrumie, oto kilka wskazówek:

    1. Utrzymuj prostotę tablicy – trzy kolumny to często wszystko, czego potrzebujesz.
    2. Zachowaj współpracę zespołową – unikaj przypisywania kolumn do konkretnych osób.
    3. Szanuj limity WIP – to fundamentalna zasada Kanbana, bez której traci on sens.
    4. Nie rezygnuj z ceremonii Scruma – Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective są nadal kluczowe.
    5. Pamiętaj o celu – dostarczanie wartości jest ważniejsze niż piękne wykresy przepływu.

    Podsumowanie

    Jestem wielkim fanem Kanbana – naprawdę! To potężne narzędzie, które zrewolucjonizowało produkcję przemysłową i może być niezwykle skuteczne w odpowiednich kontekstach. Jednak przy wytwarzaniu oprogramowania w podejściu Agile, gdzie wymagana jest współpraca, a nie handover, Kanban często wprowadza więcej problemów niż rozwiązań.

    Zamiast ślepo łączyć Kanban ze Scrumem, zastanów się, co naprawdę chcesz osiągnąć. Jeśli twoim celem jest lepsza wizualizacja pracy, może wystarczy prosta tablica z trzema kolumnami. Jeśli chcesz poprawić przepływ, może warto skupić się na zmniejszeniu wielkości User Stories i lepszej współpracy zespołowej.

    Pamiętaj, że metodyki są narzędziami, a nie religią. Używaj ich mądrze, dostosowując do swoich potrzeb, ale nie zapominaj o fundamentalnych zasadach, które stoją za nimi. W przypadku Scruma są to przejrzystość, inspekcja i adaptacja. W przypadku Kanbana – wizualizacja, ograniczenie pracy w toku i zarządzanie przepływem.

    I jeśli kiedykolwiek zauważysz u siebie lub swojego zespołu objawy Kanbanosis Acute – nadmierne mnożenie kolumn, obsesję na punkcie przepływu kosztem wartości czy przekazywanie zadań zamiast współpracy – wiedz, że jest na to lekarstwo. Czasami najlepszym rozwiązaniem jest powrót do podstaw i przypomnienie sobie, po co właściwie stosujemy te metodyki.

    Bo ostatecznie nie chodzi o to, czy używasz Kanbana, Scruma czy jakiejkolwiek innej metodyki. Chodzi o to, czy skutecznie dostarczasz wartość swoim klientom. A to wymaga współpracy, adaptacji i ciągłego uczenia się – niezależnie od tego, jak nazywasz swój proces.

  • Facylitacja bez sztywnego kołnierzyka – gdy plan się wali, a uczestnicy szukają innej drogi

    Facylitacja bez sztywnego kołnierzyka – gdy plan się wali, a uczestnicy szukają innej drogi

    Rozmawiałem z koleżanką na temat facylitacji spotkania, które ma organizować. Była to taka typowa „burza mózgów na temat burzy mózgów”, czyli odbicie myśli, żeby sprawdzić, czy poprawnie myślimy. I wiecie co? Odkryliśmy, że ten przypadek może dosięgnąć ciekawe zagrożenie nazywane przeze mnie nad-facylitacją. Brzmi trochę jak jakieś przewinienie drogowe, prawda? „Za nadmierną facylitację grozi mandat w wysokości jednego nieudanego spotkania i dwóch punktów karnych w reputacji zawodowej.”

    Ale żarty na bok. Nad-facylitacja to sytuacja, gdy facylitator tak bardzo zakochuje się w swoim starannie przygotowanym planie, narzędziach i strukturze, że staje się ślepy i głuchy na faktyczne potrzeby grupy. Dochodzi wtedy do jednej z dwóch wpadek:

    • albo facylitator zupełnie przegapia, że uczestnicy chcieliby pójść inną drogą i uparcie prze do przodu ze swoim planem (jak kierowca GPS-u, który każe skręcać w prawo, mimo że droga jest zamknięta),
    • albo orientuje się, że jego struktura nie działa, ale nie ma w zanadrzu planu B, C czy nawet Z (jak kucharz, który umie gotować tylko jedno danie i wpada w panikę, gdy skończą się składniki).

    W obu przypadkach wynik jest podobny – spotkanie nie osiąga swojego celu, uczestnicy czują się sfrustrowani, a facylitator wygląda jak człowiek, który przyszedł na bal przebierańców w garniturze.

    Uważność – supermoce facylitatora

    Jak więc temu zapobiec? Jednym z kluczowych elementów jest stan uważności, czyli, ujmując rzecz prosto, bycie w pełni obecnym „tu i teraz” podczas facylitacji spotkania. Nie chodzi tu o jakieś ezoteryczne praktyki (choć medytacja faktycznie pomaga), ale o zwykłą (a właściwie niezwykłą) zdolność do zauważania, co rzeczywiście dzieje się w pokoju.

    Uważny facylitator to taki, który:

    • Obserwuje język ciała uczestników (czy przysypiają, czy pochylają się do przodu z zainteresowaniem)
    • Wyłapuje zmianę energii w grupie (nagłe ożywienie lub spadek zaangażowania)
    • Zauważa, gdy dyskusja spontanicznie skręca w innym kierunku niż zaplanowany
    • Rozpoznaje momenty „aha!” i potrafi je wykorzystać
    • Wyczuwa napięcia i konflikty, zanim staną się one widoczne dla wszystkich

    Bycie uważnym to jak posiadanie radaru, który nieustannie skanuje przestrzeń spotkania, wyłapując sygnały, które mówią: „Hej, tu dzieje się coś ważnego!” lub „Uwaga, zbliżamy się do ściany, trzeba zmienić kurs!”

    W praktyce oznacza to, że musisz mieć podzielną uwagę. Część mózgu śledzi proces i czas, a część jest całkowicie zanurzona w tym, co mówią i robią uczestnicy. To trochę jak jazda samochodem i jednoczesne prowadzenie ciekawej rozmowy – można to zrobić, ale wymaga to praktyki.

    Aktywne słuchanie – więcej niż dwoje uszu

    Siostrzaną umiejętnością uważności jest aktywne słuchanie. I nie, nie mówię tu o potakiwaniu głową i wtrącaniu „mhm” co kilka sekund, choć to też jest element tej układanki.

    Aktywne słuchanie w kontekście facylitacji to:

    • Słuchanie nie tylko słów, ale też emocji i intencji, które za nimi stoją
    • Wychwytywanie tematów i wątków, które pojawiają się w wypowiedziach różnych osób
    • Rozumienie, co naprawdę jest ważne dla uczestników (często nie jest to to samo, co zostało zapisane w agendzie)
    • Zadawanie pytań, które naprawdę zgłębiają temat, zamiast prowadzić do z góry założonych odpowiedzi
    • Parafrazowanie i podsumowywanie, aby upewnić się, że dobrze zrozumiałeś intencje i potrzeby grupy

    Dobry facylitator słucha tak, jakby od tego zależało jego życie – bo faktycznie zależy od tego życie spotkania!

    Jednym z kluczowych sygnałów, że uczestnicy potrzebują innego przebiegu spotkania, jest moment, gdy dyskusja zaczyna krążyć wokół tematu, który nie był planowany, ale wyraźnie budzi zainteresowanie i energię grupy. Albo gdy przygotowane ćwiczenie spotyka się z oporem lub brakiem zaangażowania. W takich chwilach trzeba umieć powiedzieć: „Widzę, że ten temat jest dla was ważny. Czy chcecie, żebyśmy poświęcili mu więcej czasu, nawet kosztem innych punktów agendy?”

    Arsenał facylitatora, czyli dlaczego jeden młotek to za mało

    Dochodzimy do kluczowego punktu – konieczności posiadania wielu narzędzi, technik i podejść w swoim facylitacyjnym repertuarze. Wyobraź sobie, że jesteś elektrykiem, który przychodzi naprawić instalację mając przy sobie tylko śrubokręt. Albo lekarzem, który na każdą dolegliwość przepisuje ten sam lek. Tak właśnie wygląda facylitator, który zna tylko jedną metodę prowadzenia spotkań.

    W moim „plecaku facylitatora” zawsze noszę kilka alternatywnych scenariuszy i narzędzi do każdego spotkania. Jeśli planowana burza mózgów nie wypala, mogę szybko przejść do techniki 6 kapeluszy myślowych. Jeśli dyskusja w całej grupie nie przynosi rezultatów, dzielę uczestników na mniejsze zespoły. Jeśli cyfrowe narzędzia zawodzą, mam zawsze pod ręką analogowe zamienniki.

    Budowanie takiego arsenału to proces, który trwa latami, ale warto zacząć od kilku solidnych, uniwersalnych narzędzi, które sprawdzają się w różnych kontekstach. Z czasem będziesz dodawać kolejne, bardziej wyspecjalizowane, dostosowane do konkretnych sytuacji i grup.

    Doświadczenie – nie da się tego ściągnąć z internetu

    Wiedzieć, kiedy zmienić kurs, to jedna rzecz. Wiedzieć, NA CO zmienić kurs, to zupełnie inna sprawa. I tu właśnie wkracza doświadczenie.

    Doświadczony facylitator widział już dziesiątki, jeśli nie setki spotkań. Widział co działa, a co nie. Widział, jak grupy reagują na różne techniki i podejścia. Widział, jak ratować spotkanie, które zmierza ku katastrofie, i jak wykorzystać nieoczekiwane możliwości, które pojawiają się w trakcie.

    Ten rodzaj wiedzy nie da się łatwo przekazać w artykule czy książce – musisz go zdobyć w praktyce. Ale mogę ci powiedzieć, że każde prowadzone przeze mnie spotkanie, nawet to, które poszło nie tak, jak planowałem, było cenną lekcją, która wzbogaciła mój warsztat.

    Improwizacja – czyli jazz w świecie facylitacji

    Na koniec dochodzimy do umiejętności, która łączy wszystkie poprzednie – improwizacji. Doświadczeni facylitatorzy to wirtuozi improwizacji, którzy potrafią płynnie dostosowywać się do zmieniających się warunków, wykorzystując swój arsenał narzędzi i technik.

    Improwizacja w facylitacji to nie to samo, co brak przygotowania. Wręcz przeciwnie – to właśnie solidne przygotowanie i bogaty repertuar pozwalają na swobodną improwizację. Tak jak jazzowy muzyk musi znać teorię muzyki i opanować instrument, aby móc improwizować, tak facylitator musi doskonale rozumieć procesy grupowe i mieć opanowane różne techniki, aby móc płynnie je modyfikować i dostosowywać do potrzeb grupy.

    W praktyce improwizacja może oznaczać:

    • Zmianę kolejności punktów agendy, gdy grupa ma więcej energii do trudnego tematu niż zakładano
    • Modyfikację zaplanowanego ćwiczenia, gdy okazuje się, że nie pasuje ono do aktualnego składu grupy
    • Całkowitą zmianę podejścia, gdy pierwotny plan nie przynosi oczekiwanych rezultatów
    • Podchwycenie i rozwinięcie nieplanowanego wątku, który może prowadzić do wartościowych odkryć.

    Podsumowanie – elastyczna doskonałość

    Podsumowując, dobry facylitator to nie ten, który idealnie trzyma się planu, ale ten, który doskonale osiąga cel spotkania – nawet, jeśli droga do tego celu okazuje się zupełnie inna niż zakładał.

    Uważność i aktywne słuchanie pozwalają mu rozpoznać, kiedy należy zmienić kurs. Bogaty arsenał narzędzi i technik daje mu możliwość wyboru alternatywnej drogi. Doświadczenie pomaga mu wybrać najlepszą opcję. A umiejętność improwizacji pozwala mu płynnie przeprowadzić grupę przez tę nieplanowaną podróż[7].

    Czy to trudne? Owszem. Czy to możliwe do nauczenia? Absolutnie! W końcu nikt nie rodzi się facylitatorem – to rzemiosło, którego można się nauczyć i które można ciągle doskonalić.

    Jeśli więc jesteś gotowy, by wzbogacić swój warsztat facylitatora o elementy uważności, elastyczności i improwizacji, lub szukasz eksperta, który pomoże twojej organizacji w prowadzeniu skutecznych spotkań i warsztatów – daj znać. Z przyjemnością podzielę się swoim doświadczeniem i pomogę ci osiągnąć mistrzostwo w facylitacji bez sztywnego kołnierzyka.

  • „Doświadczenie mierzone w latach” == bzdura.

    „Doświadczenie mierzone w latach” == bzdura.

    „minimum 2 lata doświadczenia jako Scrum Master”

    „5+ doświadczeń jako Agile Coach”

    Czy doświadczenie powinno być mierzone w latach? Czy to ma sens?

    Wielokrotnie spotkałem się ze zjawiskiem Scrum Mastera z kilkuletnim doświadczeniem, który jest głupi jak wół. Pracuje schematycznie, nie rozumie tego, co robi, a jedyne, co potrafi, to wdrażać Zombie-Scrum, narzucając swoją wolę zespołowi jak Project Manager.

    Z drugiej strony, znam wiele przypadków, gdy ktoś z kilkumiesięcznym doświadczeniem jako Scrum Master ma naturalny talent do tej roli. Pracuje z wrażliwością i postawą coachingową, zmuszając zespół do refleksji nad swoim sposobem działania. Pracuje dla zespołu i z zespołem, aby usprawniać go w coraz efektywniejszej pracy dla produktu.

    Skoro jakość Scrum Mastera nie zależy od lat doświadczenia, dlaczego rekruterzy używają niedziałającej miary? Jeśli rekruter nie jest specjalistą w danej dziedzinie, taka miara jest dla niego jedynym sposobem porównania kandydatów. Czy to źle? Nie, jeśli porównanie dokonywane jest ze świadomością jego wad.

    Dlaczego doświadczenie nie powinno być mierzone latami? Przede wszystkim dlatego, że samo doświadczanie sytuacji nie przesądza o przyszłości. Skąd bierze się doświadczenie?

    1. undergo – jesteśmy w jakiejś sytuacji
    2. go thru – przechodzimy przez nią
    3. reflection – analizujemy ją i wyciągamy wnioski

    Refleksja buduje doświadczenie.

    Szybkość zdobywania doświadczenia zależy od możliwości przeprowadzenia świadomej analizy i refleksji nad wydarzeniami. Z tego punktu widzenia szybko dojdziemy do najciekawszego wniosku: warto przeprowadzić rozmowę ze Scrum Masterem z krótkim doświadczeniem. Jeśli jest rozwinięty pomimo ograniczonego stażu, oznacza to, że potrafi skutecznie reflektować nad tym, co robi. Czy nie jest to jakość, której najbardziej szukamy u Scrum Masterów, aby byli odpowiedni do pracy z zespołem?

    Co więcej: skoro refleksja daje nam doświadczenie, umiejętności analityczne pozwalają nam budować doświadczenie nawet na podstawie cudzych doświadczeń. Dlatego Scrum Masterzy prowadzą tak wiele dodatkowych działań poza pracą.

    Rekruterzy: Nie odrzucajcie ludzi z powodu krótkiego czasu pracy w ich CV. Porozmawiajcie z nimi. To się opłaca. Często są najlepsi.

  • „Czasami zespoły mają lepsze pomysły niż Scrum Masterzy”

    „Czasami zespoły mają lepsze pomysły niż Scrum Masterzy”

    Czasami? Wydaje się, że zawsze. Mam nawet wrażenie, że jako Scrum Masterzy jesteśmy jedynie zbieraczami cudzych pomysłów i rozwiązań. Czy jesteśmy wystarczająco kompetentni, aby wiedzieć lepiej niż specjaliści, jakie rozwiązanie jest dobre w ich obszarze ekspertyzy?

    Dzisiaj chciałbym pokazać Wam pomysł, który kiedyś podsunął Paweł Płoneczka, doświadczony programista (Paweł, jeszcze raz — dziękuję!).

    Częstym problemem Zespołu Scrumowego jest słaba informacja zwrotna i małe zaangażowanie interesariuszy podczas Sprint Review. Jest wiele powodów tego problemu, ale najczęstszym jest niemożność pokazania interesariuszom, jakie zmiany zaszły w produkcie. Jak mają docenić produkt, jeśli nawet zespół, który go tworzy, nie rozpoznaje tych zmian i nie jest w stanie ich pokazać?

    Zespół Scrumowy powinien starać się przedstawiać swój przyrost z Sprintu tak, jakby to była najlepsza praca, jaką kiedykolwiek wykonali:

    • z dumą
    • jako imponujący pokaz ich umiejętności i wysiłku
    • powinien odzwierciedlać głębokie zaangażowanie w produkt
    • powinien na długo pozostać w pamięci widzów
    • powinien być małym, ukierunkowanym pokazem.

    Jak to zrobić? Potrzebny jest reżyser.

    Podczas planowania zespół powinien zastanowić się, kto będzie reżyserem, kto będzie mistrzem ceremonii, kto przygotuje scenariusz. Taka osoba musi mieć na uwadze kontekst Review już na początku pracy nad daną funkcjonalnością. W trakcie Sprintu zbierane są treści (zrzuty ekranu, dane, pomysły, zdjęcia), które następnie służą do stworzenia prezentacji na Review. Można również dodać do Definition of Done coś w rodzaju „Zespół jest gotowy do przedstawienia efektów pracy w atrakcyjny sposób”.

    Takie przygotowanie pozwala zespołowi od początku myśleć o pracy w kontekście pokazania wyników interesariuszom, w tym najważniejszym — użytkownikom. Show powinien być przygotowany tak, aby widzowie chcieli korzystać z nowych funkcjonalności.

    Dodatkowo rozwiązuje to powtarzający się problem „Jak pokazywać błędy?”. To proste — pokazać produkt przed i po naprawie. Nie jest to nic kluczowego, gdyż nie przynosi nowej wartości, ale warto pokazać dla zachowania przejrzystości produktu.

    Jakie będą rezultaty? Sprawdziłem to już kilka razy:

    • Interesariusze, widząc zaangażowanie zespołu i pracę włożoną w prezentację produktu, niemal natychmiast angażują się w spotkanie.
    • Produkt zaczyna zmieniać się na lepsze.
    • Tworzy się dialog między zespołem a biznesem.
    • Z czasem zwiększa się zaufanie i zrozumienie.

    Proste? Warto!

  • Exposé Scrum Mastera, czyli jak nie zaczynać pracy z zespołem

    Exposé Scrum Mastera, czyli jak nie zaczynać pracy z zespołem

    Przypomnij sobie lub wyobraź następującą sytuację: jesteś członkiem zespołu, w którym pojawia się nowy szef, koordynator, manager lub konsultant — osoba, która będzie miała wpływ na Twoją codzienną pracę. Co chciałbyś/chciałabyś usłyszeć od niej na pierwszym spotkaniu? Co chciałbyś/chciałabyś czuć po jego zakończeniu? Czego obawiasz się jako członek zespołu w takiej sytuacji?

    Sam wielokrotnie przechodziłem przez ten proces i odbyłem na ten temat wiele dyskusji, a niemal we wszystkich przypadkach słyszałem jeden zestaw odpowiedzi:

    • Chciałbym usłyszeć, że nie będzie ingerować w sposób, w jaki pracuję.
    • Chciałbym mieć pewność, że nie będzie rewolucji.
    • Boję się, że będę oceniany za sposób, w jaki pracuję.

    Jeśli zgadzasz się z tymi stwierdzeniami, będąc po drugiej stronie, dlaczego zakładasz, że najlepszym rozwiązaniem jest pokazanie władzy, kontroli nad wszystkim lub podejście „Teraz ja tu rządzę i pokażę wam, jak to się robi”?

    „Wiem lepiej” — wejście do zespołu z takim podejściem może wywołać myśli „no, teraz on pewnie będzie próbował nam mówić, jak mamy pracować”. Zamiast tego proponuję, abyś powiedział zespołowi: „Jesteście specjalistami i wiecie, co robicie. Mam nadzieję, że będę mógł wam pomóc.”

    „Wszystko musi się zmienić” — to wywoła strach i panikę przed nadchodzącą rewolucją. Rewolucja to nagła i ogromna zmiana, a przecież mamy wprowadzać stabilizację i być agentem zmiany, ale poprzez ewolucję. Zmiana ewolucyjna jest powolna, przemyślana i mierzalna. Dlatego proponuję: „Macie swoje sposoby pracy i nie będę ingerować. Mam nadzieję, że będę mógł pomóc.”

    „Dla mnie ważne jest…” — wywołuje to obawę przed oceną według nowych kryteriów. Sprawia, że ludzie boją się, że nowy zestaw zasad i oczekiwań będzie trudny do spełnienia. Strach nie jest dobry, ponieważ zawsze prowadzi do destabilizacji. Ponownie proponuję zapewnić zespół słowami: „Chciałbym poznać zasady, które tu panują i nie zamierzam ich zmieniać. Jeśli coś nie działa tak, jak powinno, powoli to naprawimy. Mam nadzieję, że będę mógł pomóc.”

    Pamiętaj, że frazy typu „Ważne jest dla mnie…”, „Szczególnie docenię…” czy „Będę zwracał największą uwagę na…” są odczytywane jako ocena i mierniki. Takie mierniki wpływają na zachowanie i są użyteczne, ale nie przy dołączaniu do nowej organizacji czy zespołu. Nie wiemy, co się w nim dzieje i jest większa szansa na zepsucie czegoś niż naprawienie.

    Podsumowując, mam dla Ciebie 4 wskazówki:

    1. Dobre pierwsze wrażenie można zrobić tylko raz, więc nie lekceważ go i zrób exposé jako osobne spotkanie. To ważny moment.
    2. Przygotuj się! Napisz scenariusz, nagraj swoją przemowę, aby ją poprawić, przygotuj fiszki — cokolwiek działa. Bardzo ryzykowne jest podchodzenie do tej przemowy bez planu.
    3. Sprawdź, jak czułbyś się jako członek zespołu przed i po takim exposé. Spokojnie? To dobrze.
    4. Sama zmiana Scrum Mastera/lidera/managera/koordynatora jest wystarczająco stresująca. Exposé ma uspokoić zespół — będzie czas później na wprowadzanie zmian.
  • Dlaczego programiści lubią Scrum?

    Dlaczego programiści lubią Scrum?

    Dziś otrzymałem feedback do jednego z moich wcześniejszych artykułów o Scrumie: „Tekst pokazuje, że scrum jest świetny, bo programiści go lubią. Ale nie ma nic o tym, dlaczego go lubią, ta część jest brakująca (…)”. Napisałem ten tekst, aby wypełnić tę lukę.

    Muszę ostrzec! Nie wszyscy programiści lubią Scrum. Aby pracować w Scrumie i być z niego zadowolonym, trzeba mieć pewne cechy. Na szczęście większość deweloperów je posiada. Skupiam się dalej na tych cechach, bo zawsze mówię, że…

    programiści są inteligentni
    Nie wiedziałeś o tym? Są, po prostu są. Lubią się uczyć, lubią gry i zagadki. Są zadowoleni, gdy mogą się rozwijać. Lubią wyzwania. Doskonale rozumieją, do czego służy produkt i jakie potrzeby klienta ma spełniać. Efekt jest taki, że jeśli czują, że coś od nich zależy, angażują się w proces tworzenia produktu, ponieważ…

    programiści są kreatywni
    a przynajmniej większość z nich jest kreatywna. Transparentność między biznesem a Zespołem Scrumowym pozwala deweloperom proponować rozwiązania, które nie są oczywiste dla interesariuszy czy Product Ownera. Istnieje powiedzenie „co dwie głowy to nie jedna”, a my mamy cały zestaw głów w zespole – nie można tego zmarnować. W Scrumie cały zespół tworzy produkt, zbiera feedback i go omawia. Mikrozarządzanie procesem tworzenia niszczy tę kreatywność. Zespół może być samoorganizujący i chętnie to robi, ponieważ…

    programiści chcą, by im ufano
    Scrum buduje zaufanie. Podczas sesji planowania zespół zobowiązuje się do dostarczenia: „OK, zrobimy wybrane User Stories do końca sprintu. Będą gotowe, przetestowane i zintegrowane”. Więc PO musi okazać im wiarę, nie ingerować i pozwolić im pracować, dyskutować, wychodzić wcześniej czy siedzieć dłużej – to wybór zespołu. Odwdzięczają się PO zaangażowaniem, ponieważ ostatecznie…

    programiści lubią być doceniani
    Myślę, że każdy lubi być doceniany. Pieniądze na koncie na koniec miesiąca są wyrazem uznania, ale niewiele rzeczy może wywołać taki sam poziom satysfakcji jak pochwała produktu przez Product Ownera lub interesariusza podczas Sprint Review. W Scrumie może się to zdarzać w każdym Sprincie. Czasami jest to ważniejsze niż kolejna premia pieniężna.

    Scrum nagradza i rozwija wyżej wymienione cechy programistów. Dlatego deweloperzy, którzy nie stają się pasywnymi koderami, naprawdę lubią pracować w tym trybie. Zaufanie, jakim są obdarzani, i brak presji na szybsze dostarczanie, skutkują spokojną i stabilną atmosferą pracy. Wstawanie rano i spotykanie zespołu to coś, na co czekasz, a polecanie takiej firmy znajomemu to przyjemność.