Kiedy wybrać Scrum, a kiedy Kanban?

Wszystkie metody, praktyki i techniki należące do rodziny Agile opierają się o te same pryncypia: mechanizm empiryczny, Manifest Agile oraz 12 Zasad Zwinnego Tworzenia Oprogramowania.

Najważniejszym jest tu istnienie mechanizmu empirycznego – wszystko, co zostało w 2001 roku zawarte w Manifeście i Zasadach wywodzi się właśnie z niego (a wiele metod bazujących na empiryzmie, jak Scrum, XP, Crystal czy Kanban istniało wiele lat wcześniej, nim ukuto termin Agile).

Mechanizm empiryczny składa się z trzech elementów: inspekcji (sprawdzamy jaki jest stan faktyczny), adaptacji (dostosowujemy się, żeby lepiej osiągać cel), przejrzystości-transparencji (zapewnienia, że działamy na prawdziwych danych). Często opisuję go jak termostat – wyobrażamy sobie mechanizm z pokrętłem, który mierzy temperaturę w pomieszczeniu (inspekcja), dostosowuje ją do temperatury zadanej (podnosi, obniża – adaptacja) oraz działa w przejrzystych warunkach (np. nie kładziemy na nim mokrego ręcznika zaburzającego odczyty).

Potrzebujemy empirii przy budowaniu produktów, ponieważ dziedzina produkcji oprogramowania jest złożona – trudno przewidzieć wiele rzeczy, zmiany następują szybko, wymaga dużej wiedzy, często też znamy postawione cele, ale istnieje wiele dróg ich osiągnięcia (technologicznie, biznesowo itd.), a my chcemy je eksplorować, by wybierać te efektywne i maksymalizujące wartość. Nie możemy usztywniać się na realizacji planów rozpisanych na zbyt daleko do przodu, bo wiele czynników zmieni się, a wiele innych nie umiemy nawet dziś przewidzieć.

Dlatego każda metoda czy technika agile’owa jest: empiryczna, inkrementalna (przyrostowo dodaje wartość w produkcie), i iteracyjna (ma stałe cykle pracy). Dzięki tym trzem cechom, produkty budowane w sposób zwinny, mogą być zmieniane i dostosowywane w częsty, acz przemyślany i umotywowany biznesowo sposób.

Czym się charakteryzuje Scrum?

Obecnie istnieje ponad sto różnych metod i narzędzi pod wspólną etykietką Agile. Najpopularniejszym wg badań VersionOne jest Scrum (lub Scrum łączony z innymi metodami, jak np. ScrumXP), z którego korzysta ponad 60% badanych organizacji. Scrum jest metodą ramową, która porządkuje nieco proces budowania złożonych produktów. Nie wdając się szczegółowo w opis, Scrum ma pięć zdarzeń (punktów inspekcji i adaptacji w konkretnym czasie), trzy role oraz trzy artefakty (przedmioty poddawane tej inspekcji) i jako opisany koncept pochodzi z lat 90. Jest „ramowy”, ponieważ jedynie nakłada pewną formę postępowania, ale nie wyjaśnia żadnej „treści” wewnątrz owej „formy” – ten kontekst zależy tylko od zespołu/organizacji używającej Scruma.

Scrum używany jest do budowania złożonych produktów, głównie oprogramowania. Pozwala na eksplorację nowych pomysłów biznesowych lub technologicznych, minimalizuje ryzyko eksperymentowania dzięki stałym iteracjom, oraz na koniec każdej iteracji oddaje nam do rąk używalny przyrost produktu. Dzięki temu świetnie się sprawdza, kiedy chcemy utrzymać stałe tempo rozwoju produktu, którego nie możemy szczegółowo zaplanować na starcie.

Czym się charakteryzuje Kanban?

Kanban jest nie tyle metodą, co pewną strategią optymalizacji przepływu pracy zapożyczoną z japońskiego przemysłu samochodowego (Toyota). Chociaż korzeniami sięga lat 50. i świata Lean, to w Agile jego odmiana Kanban Software Development stawiana jest w rankingu popularności na drugim miejscu. Kanban pomaga zwiększyć efektywność danego procesu, i niekonieczne będzie to proces produkcji oprogramowania. Z Kanbana dobrze też korzysta się w świecie HRu, marketingu, call center czy dziale prawnym – wszędzie tam, gdzie kolejność pracy nie tyle zależy od wartości w produkcie (jak w Scrum), co jest po prostu kolejką tematów do zajęcia się.

Cztery zasady Kanbana to:

  1. Wizualizacja przepływu pracy (często kojarzona z kanbanem w japońskim znaczeniu, czyli tablicą, na której różne kolumny i karteczki oznaczają postęp prac).
  2. Ograniczanie ilości pracy w toku.
  3. Aktywne zarządzanie obecną pracą w toku.
  4. Poddawanie przepływu pracy inspekcji i adaptacji.

Jak widać, Kanban nie wymusza na starcie żadnych zmian w już istniejącym procesie. Pomaga go tylko zwizualizować, zacząć mierzyć podstawowe metryki i dzięki temu usprawniać. Kanban nie zakłada planowania pracy, lecz obsługę kolejki incydentów.

Owszem, mogą istnieć dwie dodatkowe role (Service Request Manager odpowiedzialny za rozwijanie produktu i potrzeby klientów oraz Service Delivery Manager odpowiedzialny za flow procesu), nie ma żadnych stałych zdarzeń, jedynie kadencje – czyli pętle informacji zwrotnej (może ich być aż siedem). Najważniejsze metryki kanbanowe to:

  1. lead time – pełen czas od zgłoszenia incydentu przez klienta do otrzymania gotowego rozwiązania. Chcemy, by malał.
  2. cycle time – czas, który zespół spędza nad aktualną pracą nad rozwiązaniem. Chcemy, by malał.
  3. throughput – przepustowość, czyli ile jednostek pracy (zadań, karteczek, story pointów itd.) zostaje wykonanych w jednostce czasu (w ciągu dnia, tygodnia itd.). Będzie dobrze, jeśli wzrasta.

Którą z nich wybrać i do jakich zastosowań?

Pomocne w wyborze między Scrumem a Kanbanem są trzy pytania:

  1. Jaki rodzaj pracy będzie wykonywać zespół?
  2. Czy będzie istniała wspólnota pracy, praca zespołowa, czy też każdy członek zespołu swoje zadania może wykonywać samodzielnie i niezależnie?
  3. Czy jest ważne utrzymanie stałego tempa pracy i rozwoju produktu?

Rodzaj pracy

Jeśli można przewidzieć, zaplanować i ustabilizować pracę na bliski horyzont czasu (między 1 a 4 tygodniami), prawdopodobnie powinniśmy stosować Scrum. Dzięki temu ryzyko, że nawet „przestrzelimy” z efektami naszej pracy lub utkniemy nad trudnościami kosztuje nas tylko tę jedną iterację. Praca eksploracyjna, eksperyment, odkrywanie niepewnego lub poszukiwanie najlepszego rozwiązania (znamy cel, nie znamy ścieżki dojścia) – to domena Scruma.

Natomiast, jeśli nie liczy się planowanie, bo i tak obsługujemy kolejkę pracy zgodnie z jakąś regułą, to warto rozważyć Kanban. Ostatecznie służy on procesom, więc jego efektem w przeciwieństwie do Scruma może nie być produkt (np. trudno wskazać, co byłoby produktem konsultantów call center lub zespołu prawników sprawdzających zgodność naszych usług z obowiązującymi przepisami). Prace administracyjne, utrzymanie, kolejka do wykonania, spływające zapytania – jeśli cokolwiek jest trudne do zaplanowania lub wręcz niemożliwe do przewidzenia (np. nie wiemy, ilu klientów i z jak trudnymi pytaniami zadzwonią do konsultantów), a może być obsługiwane tablicą z kolejką incydentów – oto dobre pole dla Kanbana.

Wspólnota pracy

Scrum wymaga wspólnoty pracy w zespole. Ma opisane role Developerów, Product Ownera i Scrum Mastera, którzy wspólnymi siłami przekładają potrzeby biznesowe na używalny produkt. Ma limit wielkości zespołu. Zespół powinien pracować razem, uzupełnia swoje zdolności (jest wszechstronny – ma wszystkie kompetencje potrzebne do zbudowania produktu), a wszystkie role po równo odpowiadają za przyrost produktu.

W Kanbanie może nawet nie istnieć zespół – w sensie grupy mającej wspólny cel i współdziałającej ze sobą – bo każdy może swoją pracę wykonywać sam (wróćmy znowu do przykładu z call center). Kanban jedynie obrazuje przepływ pracy, może wykazać pewne ograniczenia (np. tylko niektóre osoby mogą wykonać jakąś czynność, ktoś czeka aż ktoś inny skończy swoje zadanie itd.). Dobrze jednak wprowadzić rolę Service Delivery Managera, jako osoby dbającej o flow, uczącej i przypominającej o inspekcji, adaptacji i przejrzystości.

Stałe tempo pracy

W Scrumie istnieje coś w rodzaju dżentelmeńskiej umowy: Product Owner zamraża część wymagań, obiecując że w danej iteracji ich nie zmieni, żeby Developerzy mogli je przekuć w przyrost produktu, a Developerzy dają Product Ownerowi wolną rękę w pracy nad pozostałymi, niezamrożonymi wymaganiami. Ten cykl pracy, zwany Sprintem, ma stałą długość i pozwala nadać rytm pracy. Na koniec każdej iteracji powstaje coś gotowego i potencjalnie wydawalnego (tzn. Product Owner zawsze może to wydać przynajmniej na koniec iteracji, ale jest to jego biznesowa decyzja). Wymagania są segregowane względem wartości w produkcie, przez Product Ownera, na liście zwanej Product Backlogiem.

Kanban zakłada, że zmiana może się zadziać w każdym momencie. Dlatego nie da się ani przewidzieć ile pracy wpadnie do kolejki, ani nie trzeba czekać na rytm iteracji – po prostu ile razy coś jest skończone, może być wydane. Kanban jest też systemem pull – wciąganie pracy do wykonania następuje od razu, gdy poprzednia jest ukończona. Nakłada się jednak tzw. kadencje (pętle inspekcji i adaptacji), żeby utrzymać empiryzm.

Oczywiście – jak wszystko w świecie Agile – wybór między Scrum i Kanban jest bardzo kontekstowy. Zależy od wielu czynników, a ten artykuł ma poddać pod rozwagę te najczęściej spotykane. Jeśli nadal nie ma pewności co do zasadności jednej lub drugiej metody, proponuję… podejście empiryczne. Warto wypróbować obie i zobaczyć, która przynosi lepsze efekty (czyli zapewnia lepszą przejrzystość, pozwala usprawniać proces i podnosi wartość biznesową).


Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/kiedy-wybrac-scrum-a-kiedy-kanban/

Eksperymenty i porażki

W ciągu swojej kariery w latach 1984-2003 koszykarz Michael Jordan przegrał (jak sam twierdzi) 300 spotkań, a 9000 razy oddał niecelny rzut, w tym 26 razy gdy od tego właśnie zależało zwycięstwo. Statystyka robi wrażenie, szczególnie gdy wiadomo, że chodzi o sportowca światowego formatu, legendę parkietu, powszechnie rozpoznawaną i kojarzoną z koszykówką przez każdego, kto nie spędził ostatnich 30 lat na bezludnej wyspie lub w sercu dżungli. Jaka jest więc wartość w liczeniu tych wpadek, skoro ostatecznie nikt nie podważa jego statusu gwiazdy?

Wszystko zależy od naszego podejścia do sukcesów i porażek. Jeśli traktujemy porażki jako kroki do ostatecznego sukcesu, to warto im się przyglądać bliżej i wyciągać z nich wnioski. Może nawet je świętować?

Celebruj uczenie się, nie same sukcesy

Celebrowanie sukcesów jest naturalne, celebrowanie porażek brzmi jednak nieco masochistycznie – mógłby wymyślić je jakiś internetowy guru od dziwnego lajfstajlu, ale w realnym życiu trudno spotkać kogoś, kto cieszy się z niepowodzeń. No, przynajmniej ze swoich…

Chyba, że wprowadzimy trzecią kategorię zdarzeń – eksperymenty, a to pozwoli nam przedefiniować zarówno pojęcie sukcesu, jak i porażki.

Powtarzalne czynności, co do których jesteśmy praktycznie pewni efektu, przynoszą korzyści najczęściej dlatego, że używamy do nich dobrych, sprawdzonych praktyk. Często te praktyki są wręcz automatyczne, jak nawyk częstego mycia rąk albo lista kontrolna dla pilotów przed startem. Odsetek chorób i wypadków lotniczych jest dzięki temu drastycznie obniżony (a jeszcze 150 lat temu dezynfekcja rąk czy narzędzi chirurgicznych była uznawana za fanaberię…). Mamy tutaj wysokie prawdopodobieństwo, że używając dobrych praktyk osiągniemy dobre efekty, ale wciąż jest to prawdopodobieństwo, a nie pewność. Czasami mamy po prostu pecha i nawet sprawdzone wzorce wiodą nas na manowce. Ot, choćby z mojego doświadczenia – częste aktualizacje w dziurawym WordPressie podnoszą bezpieczeństwo strony, to polecana praktyka. No, chyba, że zakodowałeś tam sobie wiele dodatków i pluginów „na sztywno”, a aktualizację wykonałeś dopiero po długim czasie – gdy większość z nich nie była już wspierana. Mnie opłacało się bardziej zaprojektować ładną stronę od nowa niż przywracać z kopii…

A co z błędami? Niektórzy popełniają w kółko te same, gdyż nawet nie są ich świadomi! Wtedy nie można wyciągnąć z nich żadnych wniosków na przyszłość, co w dłuższym okresie staje się nawet bardziej dewastujące, niż sama świadomość potknięcia. W ekstremalnie rzadkich wypadkach pomyłki mogą jednak skutkować wielkimi sukcesami. Pamiętacie, że odkrywca penicyliny Alexander Fleming po prostu nie domknął naczyń laboratoryjnych i zdziwił się, gdy pleśń zabiła jego hodowlę bakterii?
Tim Harford, autor książki Adapt, proponuje więc takie podejście:

Jeśli mamy oswoić porażki, Potrzebujemy więc metodycznego podejścia do sukcesów i porażek, dzięki któremu będziemy w stanie uczyć się w krótkiej pętli.

Jak działa Celebration Grid?

W Management 3.0 kładzie się duży nacisk na zdolność zwinnych organizacji do szybkiego uczenia się i eksperymentowania. Nie dziwi więc obecność przydatnego narzędzia: Celebration Grid, które pomaga celebrować eksperymenty, a nie tylko bezsens porażek ani zachwyt nad sukcesami. Ostatecznie chcemy cieszyć się z efektywnego wykorzystania naszej wiedzy, a nie tylko karać za pomyłki! Przy eksperymentach jest bowiem największa szansa na nauczenie się czegoś nowego – niezależnie czy potwierdzamy, czy obalamy pierwotnie postawioną hipotezę, zasilamy naszą organizację nową, użyteczną wiedzą.

Celebration Grid może być z powodzeniem użyty w czasie Retrospektywy. Znajdźmy najpierw wszystkie zachowania, praktyki, zdarzenia i przykłady z ostatniego sprrintu, które przychodzą nam do głowy. Następnie postarajmy się przyporządkować je do któregoś z obszarów:

  • błędy, z których jednak wyszło coś dobrego (górny lewy róg),
  • błędy i porażki (dolny lewy róg, czerwone pole),
  • eksperymenty zakończone sukcesem (środkowa zielona kolumna, góra) – tu potwierdziliśmy założenia,
  • eksperymenty niezakończone sukcesem (środkowa zielona kolumna, dół) – tu obaliliśmy założenia lub odkryliśmy coś niespodziewanego,
  • dobre praktyki, które się opłaciły (górny prawy róg, zielone pole),
  • te rzadkie przypadki, kiedy nawet dobra praktyka zawiodła (dolny prawy róg).
www.management30.com

Przejrzymy jak ułożyły się karteczki i odpowiedzmy w ten sposób na dwa pytania:

  1. Co zrobiliśmy dobrze? (Posiłkując się dobrymi praktykami)
  2. Czego się nauczyliśmy? (Prowadząc eksperymenty)

Każda karteczka zawieszona na zielonych polach to okazja do celebracji!
Dobre praktyki kontynuujemy, błędów nie powtarzamy, a staramy się znaleźć jeszcze więcej okazji na eksperymentowanie.
Jeśli chcesz dowiedzieć się więcej o eksperymentach w podejściu Management 3.0, zapraszam do kontaktu oraz udziału w szkoleniu.

Zobacz, jak uczestnicy mojego warsztatu przygotowali Celebration Grid:

Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/eksperymenty-i-porazki/

Jak znaleźć lukę kompetencyjną?

Kompetencje

Kompetencja to wg. Słownika języka polskiego PWN „zakres czyjejś wiedzy, umiejętności i doświadczenia”, rozumiany też jako zdolność do zajmowania się określoną sprawą. Potocznie rozumiemy je jako wykształcenie, ukończone szkolenie lub warsztat, pojęcie o temacie. Oczywiście do zdobycia kompetencji w niektórych dziedzinach wystarczy przeczytać odpowiednią książkę lub zobaczyć instruktażowy film, inne jednak wymagają lat żmudnych ćwiczeń. Generalnie można wyodrębnić cztery aktywności, które pozwalają zwiększać kompetencje pracowników:

1. Sam się nauczę – przeczytam, obejrzę, wysłucham podcastu itp., wykorzystam dedykowany czas w pracy na pogłębianie wiedzy.
2. Ktoś mnie nauczy – wezmę udział w szkoleniach, odwiedzę wewnętrzne warsztaty czy meetup.
3. Sam się nauczę, a ktoś mnie wesprze w rozwoju i podpowie – mentoring i coaching.
4. Wezmę udział w przygotowanym eksperymencie – np. firmowy hackathon, mający szybko przetestować nowe pomysły lub stworzyć rozwiązanie dla istniejących problemów.

Po co i jak rozwijać kompetencje nas i naszych zespołów? Oczywiście pierwsza odpowiedź jest oczywista: im wyższe kompetencje, tym naszą pracę wykonujemy sprawniej, a tym samym efektywniej osiągamy cele i zbliżamy organizację do rynkowego sukcesu. Druga odpowiedź wymaga nieco więcej namysłu: budujemy środowisko, w którym rozwijamy nas samych jako ludzi, szkolimy się w nowych umiejętnościach i powodujemy wymianę wiedzy – a to także służy wzmacnianiu motywacji pracowników, którzy dzięki temu uzyskują większą autonomię.

Autonomia i kompetencje to kluczowe składniki modelu samodeterminacji Ryana i Deciego. Dzięki nim (i dobrym relacjom w miejscu pracy) pracownicy czują się bardziej zmotywowani i związani z firmą.

Shu-Ha-Ri

Wschodnie sztuki walki mogą nam posłużyć za inspirację dla modelu rozwoju kompetencji. Gdy uczeń trafiał do szkoły uczącej danego stylu, musiał najpierw nauczyć się podstawowych kroków, ataków, bloków i uników – dokładnie tak, jak przekazywał to instruktor (Shu oznacza zachowanie niezmienionej formy). Kiedy poznał już ruchy, zaczynał zgłębiać logikę za nimi stojącą, a z czasem mógł łączyć je w nowe kombinacje i inkorporować do swojego stylu walki (Ha to odłączenie elementów z utartych schematów). Gdy uczeń poznał już wszystko, co mogli mu przekazać mistrzowie, sam zostawał mistrzem. Nieustanna praktyka w różnych sytuacjach stawała się jego jedynym nauczycielem (Ri to opuszczenie świata ustalonych zasad, by tworzyć własne).

Matryca Kompetencji

Skoro zgodnie z opinią Stephena Hawkinga żyjemy w „stuleciu złożoności”, to i problem zbudowania kompetentnego zespołu jest złożony; nie wystarczy z jednej strony po prostu wybrać ludzi z daną wiedzą, bo może się okazać, że nie najlepiej ze sobą współpracują. Z drugiej strony silne braki kompetencyjne to spory narzut czasu na ich wyrównanie – nawet przy zdolnych i ambitnych pracownikach to może nie być wykonalne w krótkim okresie. Przecież gdy brakuje jakiejś zdolności, żadna motywacja nie będzie pomocna żeby dobrze wykonać pracę, nim się po prostu nie nauczymy jak coś zrobić. Dlatego w praktykach Management 3.0 cennym ćwiczeniem jest zbudowanie Matrycy Kompetencji (ang. Competency Matrix), dzięki której można szybko identyfikować luki kompetencyjne – i to z zaangażowaniem całego zespołu, zarazem budując przejrzyste zrozumienie silnych i słabych stron. Model Shu-Ha-Ri będzie tu o tyle przydatny, że wyróżnia trzy proste etapy posiadania wiedzy: ucznia (nie wiem jak to zrobić), praktyującego (wiem jak to zrobić), mistrza (wiem, jak nauczyć tego innych).

Matryca będzie więc wypadkową odpowiednich obszarów kompetencyjnych (zidentyfikowanych wspólnie) i zdolności poszczególnych członków zespołu w tych obszarach (zidentyfikowanych przez nich samodzielnie):

  • Potrafię coś fajnego zrobić w tym temacie i rozwiązać większość typowych problemów z danego zagadnienia? Oznaczę się żółtą kropką!
  • Jestem kompletnym nowicjuszem? Nie mam pojęcia o czym mowa? Kropka czerwona.
  • Jestem guru, mam to w małym palcu albo napisałem o tym książkę? Kolor zielony!

Zobaczmy, co widać na przykładzie z jednego z moich szkoleń:

Zespół składający się z Oli, Ewy, Adama i Patryka planuje otwarcie małego baru. Przygotowali listę podstawowych kompetencji, potrzebnych w prowadzeniu takiego lokalu. Policzyli także, ile osób i na jakim poziomie potrzebują z daną umiejętnością (np. obsługa kuchni wymaga, żeby przynajmniej 1 osoba znała się na tym doskonale – mistrz na zielono, oraz przynajmniej 2 potrafiły to robić na zadowalającym poziomie – praktykujący na żółto). Ta kompetencja jest pokryta, gdyż Ewa określa swój poziom jako mistrzyni, podczas gdy pozostali członkowie zespołu potrafią to zrobić wystarczająco dobrze. Od razu też wiadomo do kogo się zwrócić, gdy w danym obszarze mamy jakieś szczegółowe pytanie, widać też gdzie jako zespół musimy się czegoś nauczyć (lub zatrudnić do naszego zespołu kogoś, kto się na tym zna).

Dzięki temu powstaje przejrzysta tablica, pozwalająca na szybkie identyfikowanie luk kompetencyjnych – wiemy, że do Patryka raczej nie idziemy z pytaniami z zakresu księgowości, gdyż dla niego to absolutna terra incognita (chociaż Adam może go nauczyć), ale za to do Oli i Ewy uderzamy jak w dym, gdy chcemy się dowiedzieć o pracy na barze.

Czy widzicie zastosowanie takiej matrycy komperencji w swojej firmie/zespole? Jeśli tak, z chęcią poczytam o Waszych doświadczeniach. Możecie to łatwo zrobić – wystarczy napisać do mnie lub odwiedzić warsztaty Management 3.0.

Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/znalezc-luke-kompetencyjna/ 

Czy „zwinna organizacja” oznacza Scrum w każdym dziale?

Transformacja Agile

Powszechne zainteresowanie metodami z rodziny Agile 17 lat po publikacji Manifestu Agile i po ponad 20 latach wyraźnej obecności tych praktyk (Scruma, Kanbana, XP i in.) w naszej branży, nikogo nie powinno dziwić. Jednak wiele organizacji, które spotykam na swojej zawodowej ścieżce, dopiero rozpoczyna „zwinną transformację” – czyli próbuje agile’owe podejście uczynić standardem swojej organizacji pracy i rozwijania produktów. Najczęściej w firmie zaczyna się od przeorientowania istniejącego działu IT budującego te produkty, następnie przeszkolenia „biznesu” – a więc osób odpowiedzialnych za dostarczanie wymagań i dbanie o wartość rynkową tworzonych rozwiązań, potem (rzadziej na starcie) menedżerów i zarządu, a najrzadziej – samych klientów/odbiorców/użytkowników danego rozwiązania.

Często takie transformacje nie osiągają efektów, czemu się nie dziwię. Na przeszkodzie stoi:

1. zastana kultura organizacyjna (sztywne struktury i hierarchie, rozbuchane procesy, wewnętrzne rozgrywki „polityczne”),
2. powszechna „projektoza”, czyli brak poczucia wspólnoty pracy i obecność „zasobów ludzkich” w czterech projektach na raz, w każdym oczywiście na 100% czasu,
3. brak wyraźnej presji do zmian (firmie nie grozi upadek, nawet gdy nie będzie szybciej tworzyła wartościowych produktów),
4. a jako crème de la crème – brak spójnej wizji, po co taka transformacja w ogóle ma się odbywać!

I nie chodzi jedynie o wyjaśnienie programistom czy project managerom, dlaczego od jutra będą pracować inaczej. Grzechami głównymi źle przygotowanych transformacji są:

1. brak jasnego celu na poziomie wysokich warstw kierowniczych (po co cokolwiek zmieniać),
2. brak porywającej wizji dla całej organizacji (gdzie ta zmiana zaprowadzi naszą firmę),
3. brak przyzwolenia na realną zmianę – zamiast tego tylko naklejanie nowych etykietek na niezmienione role i procesy,
4. brak wiedzy jak mierzyć postępy (jakie metryki i gdzie), skąd będziemy wiedzieć, że osiągnęliśmy cele transformacji,
5. traktowanie zmian nie jako inwestycję, ale jako „zło konieczne” lub „modę na Agile”.

Unifikacja – Scrum dobry w każdym dziale

Jeśli jednak uda się te wymienione grzechy przezwyciężyć lub chwilowo odsunąć w czasie, pojawia się jeszcze jeden – będący owocem burzliwego związku Niewiedzy z Entuzjazmem. Tym grzechem jest potrzeba powszechnej unifikacji.
Kiedy organizacja uczy się metod zwinnych, to najpewniej na starcie zetknie się ze Scrumem, który jest świetnym sposobem na budowanie złożonych produktów wysiłkiem małego, samoorganizującego się zespołu. Największą zaletą Scruma jest bardzo szybka pętla informacji zwrotnej – także o tym wszystkim, czego się wstydzimy: nieznajomości domeny, technologii, potrzeb użytkownika, słabej komunikacji wewnątrz zespołu, niedociągnięć kompetencyjnych, niewystarczającego poziomu jakości itd.

Scrum jednak nie jest uniwersalną odpowiedzią na Największe Pytanie Wszechświata, ma bowiem szereg ograniczeń – wymaga pewnego *setupu* organizacyjnego, poznania nowego sposobu pracy, zrozumienia jego wartości, słabo służy powtarzalnym czynnościom lub obsłudze incydentów itd.

Oczywiście, pewne jego elementy, jak planowanie czy codzienne spotkania, mogą być używane niezależnie od samego Scruma, ale często widzę pełne wątpliwości spojrzenia przedstawicieli działów innych niż IT: „A jak my mamy tak pracować?”. Ambitne plany managementu, działu HR lub komórki odpowiedzialnej za transformację przydzieliły już bowiem pracowników do nowej struktury, nowych zespołów i produktów, a także wysłały ich na nowe szkolenia (ze Scruma najpewniej). Entuzjazm związany ze zmianą i przekształceniami spotyka niewiedzę (Scrum nie jest jedynym narzędziem z rodziny Agile i ma konkretne zastosowania produkcyjne). Jak mają się w tym odnaleźć administratorzy systemów, marketingowcy, prawnicy czy pierwsza linia obsługi klienta? Wszyscy ci, których praca niekoniecznie daje się planować na iteracje i nie zawsze dostarczają produkt jako efekt swojej pracy?
Bez obecności Agile Coacha lub kogoś z doświadczeniami z innych transformacji, może się tu wkraść słuszny lęk i opór przed zmianą, której część zespołu lub załogi nie rozumie i nie widzi w niej swojego miejsca.

Rozwiązanie

Istnieje tylko jedna odpowiedź: oni nie będą pracować w Scrumie, co nie oznacza, że nie mogą pracować zwinnie. Scrum jako taki w działach marketingu, prawnym czy obsłudze call center nie ma wielkiego sensu (co wyjaśniałem kiedyś we wpisie o Scrum vs Kanban). Ale podstawy zwinności: możliwość inspekcji pracy, jej adaptacji oraz utrzymanie przejrzystości wciąż mogą, a nawet powinny być nadal filarami pracy członków zwinnej organizacji. Dlatego z każdym działem trzeba ustalić, jakie praktyki i mechanizmy bedą u nich działać, by wzmacniać samoorganizację, zapewniać przejrzystość procesów oraz gdzie da się „zamontować” mechanizm empiryczny i jak często będzie on używany (jak długa będzie pętla informacji zwrotnej). Dlatego zastosowania różnych technik i praktyk z rodziny Agile będą się pewnie różniły między poszczególnymi częściami organizacji. Nie ma w tym nic złego, ale pod pewnymi warunkami:

1. Istnieje wspólne słownictwo, dzięki czemu zachowana jest przejrzystość. Wiadomo, na jakim etapie znajduje się praca poszczególnych jednostek, kiedy jest ukończona, co znaczą konkretne terminy.
2. Wszyscy w organizacji rozumieją, dlaczego stosuje się mechanizm empiryczny i że oznacza on konieczność *stałego* dostosowywania pracy. Jako taka transformacja jest więc ciągłym procesem, a nie określonym punktem w czasie.
3. Istnieją metryki pozwalające śledzić osiąganie celów całej organizacji bez lokalnych suboptymalizacji. To ważne w kontekście zagrożenia powrotem do pracy w silosach: dział IT znów pracuje na swoje cele, dział sprzedaży na swoje itd.

Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/scrum-w-kazdym-dziale/

Trzy kroki do zarządzania Millenialsami

Ach, ci źli „Millenialsi”

Żadne słowo od czasu „start-upu” nie zrobiło chyba w naszej branży tak zawrotnej kariery, jak Millenialsi, czyli określenie (generacji urodzonych między 1980 a 1995 rokiem). Podobno żądają wysokich wypłat przy jednoczesnym małym doświadczeniu, nie chcą pracować na darmowych stażach ani brać nadgodzin, najchętniej siedzieliby cały dzień nad laptopem ze znakiem nadgryzionego jabłka, sącząc sojowe latte i rozpraszając uwagę między nieustanne powiadomienia z social mediów. Taki obraz Millenialsów wyłania się z wielu firmowych opowieści, budując im czarną legendę. Skoro o sojowym latte mowa, to Scott Pitasky (wiceprezes sieci kawiarni Starbucks), uważa jednak temat Millenialsów za najważniejszy dla rynku pracy za 10 lat. Firmy albo przygotują się już dziś na nadejście Millenialsa-pracownika, albo w końcu znikną, gdy zabraknie im rąk do pracy. Dekonstruując mity i uprzedzenia, niechęć do pracy za niskie stawki czy poświęcania życia prywatnego na rzecz firmy powinna być raczej wyrzutem względem pracodawców, niż Millenialsów broniących stanowiska, że harmonia między życiem zawodowym i prywatnym nie może być przywilejem nielicznych. Co jednak z pretensjami, że Millenialsi często zmieniają pracę, nie czują się zmotywowani, nie utożsamiają się w pełni z celami organizacji? Czy one wzięły się znikąd?

Czego potrzebują Millenialsi w miejscu pracy?

Przyglądając się opinii o Millenialsach trudno nie odnieść wrażenia, że są oni postrzegani jako problem do usunięcia (lub nagięcia do oczekiwań), a nie pokoleniowa zmiana, którą organizacje po prostu muszą przejść. Nowa generacja przynosi ze sobą wiele dobra, z którego firmy mogą czerpać pełnymi garściami, jeśli tylko nauczą się wzmacniać naturalne obszary zdolności Millenialsów. Przede wszystkim Millenialsi są mocno  zorientowani na pracę zespołową i niestandardowe rozwiązywanie problemów (głównie dzięki swojemu zaawansowaniu technologicznemu, pozwalającemu bardzo szybko zdobywać i porównywać wiedzę z wielu źródeł). Oprócz tego, cenią sobie jasne zasady, przejrzystą komunikację i regularny feedback. Ponieważ są pewni siebie, nie obawiają się zmian i są mobilni w zakresie kompetencji – chętnie testują swoje umiejętności w nowych obszarach, nie traktują niepowodzenia jako porażkę, ale jak eksperyment. Mogą też efektywnie pracować zdalnie tak długo, jak znają jasne cele, ale nie są ograniczani narzuconym sposobem ich osiągania. Jeśli nie są zmotywowani, to prawdopodobnie nie rozumieją jasno celów firmy, albo nie współgrają one z ich przekonaniami. Jeśli zmieniają pracę, może to być podyktowane potrzebą sprawdzenia się na nowym polu. Jeśli nie zostają regularnie po godzinach, to dlatego że cenią swoje rodziny i przyjaciół, a nie że są niezaangażowani w firmowe obowiązki.

Jak praktyki Management 3.0 pomagają wspierać Millenialsów?

Odłóżmy więc „zarządzanie Millenialsami” w stylu „jak zmusić ich do cięższej pracy na rzecz firmy” do zasłużonego lamusa. Spójrzmy za to na zagadnienie jako na pytanie „Jak możemy im stworzyć takie warunki, by rozwijali się i oni i nasza firma?”. Odpowiedź zdaje się zawierać w trzech krokach:

  1. Praca według agile’owych wartości: współpracy, przejrzystości, z szybką pętlą informacji zwrotnej – Millenialsi czują się w takim środowisku swobodnie.
  2. Wzmacnianie poczucie przynależności i wspólnego celu, większego niż my sami.
  3. Szacunek – dla wartości i różnorodności, ale także dla bardziej przyziemnych spraw, jak czas pracy.

Oczywiście istnieje wiele sposobów rozwiązania tych trzech punktów, ale istnieją też praktyki w duchu Management 3.0, których możemy tu użyć:

  1. Feedback wraps – kiedy słyszymy o dawaniu informacji zwrotnej, niektórzy używają porównania do kanapki: zacznij czymś przyjemnym, do środka włóż krytyczne uwagi, a na spód znowu coś miłego. Dobry, konstruktywny feedback ma jednak wiele przekładanych warstw, niczym wrap do tortilli.
    Oto one:
    – Opisz kontekst sytuacji
    – Wynotuj obserwacje
    – Wyraź emocje
    – Uszereguj je względem wartości
    – Zakończ sugestiami udoskonaleń
    – Trzymaj to na piśmie, pamięć jest ulotna. Jeśli będziesz się ich trzymać, masz pewność że informacja dotrze w poprawnej formie i posłuży usprawnieniom działań i procesów, a nie zostanie odebrana jako atak i krytyka.
  2. Wartości organizacji – nie da się zaplanować kultury, można jedynie pokazać które najlepsze zachowania się wspiera i które najgorsze toleruje. Dlatego tak ważne staje się wspólne zrozumienie rdzennych wartości firmy – czemu nie zacząć dyskusji o nich już dziś? Wybierzcie wspólnie te, co do których zgadzacie się, że stanowią esencję Waszej organizacji (ta lista może pomóc), a następnie spróbujcie przedstawić je w praktyce – niech będzie to krótki filmik, książka, albo plakat wiszący w Waszej firmie na eksponowanym miejscu. Ustalcie z jaką regularnością będziecie wspólnie poddawać te wartości inspekcji i adaptacji – czy nadal są aktualne? Czy naprawdę je stosujecie? Co możecie w nich zmienić? Każdy w firmie ma głos!
  3. Rolą menedżera jest pomóc ustalić tyle zasad, ile jest niezbędne i zapewnić w ich granicach tyle samoorganizacji, ile to możliwe. Millenialsi lubią samoorganizację, bo pozwala im osiągać ustalone cele nowymi sposobami i niestandardowymi narzędziami. W Management 3.0 nie chcemy mieć ani dyktatury, ani anarchii, dlatego dobrze ustalić ze swoim zespołem obszary odpowiedzialności i poziomy delegacji. Jak to dobrze zrobić? Skorzystajcie z Delegation Pokera. Zwizualizujecie w łatwy sposób kto i kiedy może podjąć którą decyzję.

Artykuł oryginalnie ukazał się na blogu Code Sprinters http://agileszkolenia.pl/blog/kroki-zarzadzania-millenialsami/