blog.testowka.pl

Kanban

Ilu Agile Coachów potrzeba by wymienić żarówkę? – Agile Coach Camp PL 2014

opublikowany przez 20, Paź, 2014, w kategoriach Agile, ALE, Coaching, Kanban, Scrum

20141017_171017

W ten weekend miało miejsce niezwykłe jak naszą krajową społeczność wydarzenie – Agile Coach Camp. Blisko 60 mniej lub bardziej doświadczonych Agile Coachów, Scrum Masterów, Product Ownerów i Developerów przyjechało do Srebrnej Góry by przez 2 dni wymieniać się swoją wiedzą i doświadczeniami.

Nie było agendy, nie było prelegentów, nie było nawet ŻADNYCH slajdów! 60 osób z potężnym bagażem doświadczeń i wiedzy pracujących razem nad rozwiązaniem wielu problemów i uspójnieniem wiedzy. Duch ALE  był tam razem z nami, nowe znajomości, nowi przyjaciele, nowe perspektywy.

Pierwszy Agile Coach Camp odbył się pod hasłem „Prepare to be suprised”. Co zatem zaskoczyło mnie najbardziej?

Przede wszystkim zaskoczyłem się tym, jak wielu świetnych, doświadczonych Agile Coachów z Polski nie miałem okazji wcześniej poznać. Zaskoczył mnie niezwykle wysoki poziom wiedzy uczestników. Przyznam szczerze, że nie miałem oczekiwań przed tym wydarzeniem a mimo to bardzo wiele z niego wyciągnąłem.

To niesamowite jak nasza Agileowa społeczność wyewoluowała i dorosła na przestrzeni ostatnich kilku lat. Podczas podsumowania ACCPL nawiązałem do tego, że jeszcze 6-7 lat temu, kiedy dopiero zaczynała się moja przygoda z Agila nikt nie przypuszczał, że dojdziemy tak daleko. Wtedy ze świecą szukać można było tych którzy o Agile w ogóle słyszeli, a źródeł wiedzy na ten temat było bardzo niewiele. Dzisiaj nie tylko możemy wymieniać się wiedzą ogólnie dostępną ale nasze doświadczenia pozwalają nam na wspólne opracowywanie coraz to lepszych metod pracy. Równie ważne było to, że pomimo obecności wielu trenerów i konsultantów (ja też się w to wpisuje) udało się nam chyba uniknąć wszelkich prób indoktrynacji nowymi „modnymi” metodykami i frameworkami. Chyba nawet Scrum przestał już być „ideologią” i stał się (całkiem niezłym) narzędziem – jednym z wielu, które w dzisiejszych czasach wręcz wypada poznać i spróbować. 20141017_204216

Agile nie jest już niszowym, mało znanym i niesprawdzonym podejście do wytwarzania produktów. Dzisiaj coraz więcej osób wierzy (w oparciu o swoje doświadczenia), że Agile jest w tej chwili w większości przypadków najlepszą z dostępnych opcji.

Super było usłyszeć historie wielu udanych transformacji Agile prosto z naszego podwórka! Tak! W Polsce jest wiele firm, małych i dużych, które dzięki wielkim wysiłkom i pasji wielu ludzi udało się zmienić.

Poza wiedzą było też dużo zabawy – wieczorne dyskusje przy piwie, śpiewy z gitarą, karaoke z laptopa, nocne włóczenie się po lochach w twierdzy, coachowanie pejczem (ci co nie byli niech nawet nie próbują się domyślać ;-)), gry i zabawy typu jakiej wymówki używa zespół gdy nie dowiezie? („Bo pies pożarł mi backlog” okazuje się być niezwykle częste)… Nie mogę doczekać się kolejnej edycji oraz z chęcią pomogę przy organizacji!

Tych co byli serdecznie pozdrawiam, a tych co nie byli serdecznie zapraszam na kolejne edycje. Miejmy nadzieję, że częściej niż raz do roku – bo Agile to w końcu krótkie iteracje i szybki feedback, nie?

To ilu Agile Coachów potrzeba by wymienić żarówkę???

5 komentarzy więcej...

Szanse na zmianę organizacji

opublikowany przez 18, Lut, 2014, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

change1

Upłynęło już sporo wody w Wiśle od momentu, gdy po długiej, motywującej do działania dyskusji Mike Sutton powiedział mi:

If you can’t change organisation probably you need to change organisation…

Te słowa były powodem jednego z myślę, że kluczowych zwrotów w moim życiu. Ale te słowa wymagają również głębszego zastanowienia nad tym co tak naprawdę sprawia, że niektóre organizacje potrafią się zmienić, a inne nie?

Dzięki doświadczeniu jak by nie było w zmienianiu organizacji właśnie, które zbierałem przez ostatnich kilka lat udało mi się zaobserwować kilka czynników, które moim zdaniem w pewnym, znaczącym stopniu determinują czy dana organizacja ma szanse na zmianę.

Z moich obserwacji organizacje dzielą się na trzy typy.

  1. Success Story – Takie które radzą sobie w miarę dobrze. Dla takich organizacji nie ma przeważnie realnych zagrożeń które by zagroziły ich egzystencji (a przynajmniej zagrożenia te nie występują w sposób nagły i nieprzewidywalny). Przeważnie to że te firmy radzą sobie lepiej od innych wynika z tego, że wyrobiły sobie odpowiednie metody szybkiego wprowadzania zmian i reagowania na zmiany w otoczeniu. W takich organizacjach przeważnie wszyscy widzą potrzebę wprowadzania ciągłych zmian i usprawnień jako coś naturalnego, co może sprawić że będzie jeszcze lepiej.
  2. Standard – Organizacje w których nie wszyscy wyrażają chęć zmian czegokolwiek. Organizacje te radzą sobie zazwyczaj przeciętnie, ale nie widzą na horyzoncie (przynajmniej na razie) realnych zagrożeń, które mogły by wymusić jakiekolwiek realne zmiany. W takich organizacjach są oczywiście pojedyncze osoby, które chciały by sprawić by praca była bardziej efektywna i by organizacja wyrosła ponad przeciętną. Osoby te zazwyczaj dostrzegają zmiany na rynku, zmiany w konkurencyjnych firmach i nowe trendy w stosowanych na świecie metodach zapewniające wzrost efektywności.
  3. Tarapaty – Organizacje które są już w poważnych tarapatach. Dla nich zmiana często jest jedynym ratunkiem, a przynajmniej próbą ratunku przed mniej lub bardziej spektakularną porażką. „Poważne tarapaty” nie oznaczają, że organizacja z dnia na dzień przestanie istnieć jeśli nic nie zrobi – to raczej proces długotrwały, niemniej jednak widoczny. W takich organizacjach potrzeby zmian dostrzegane są przez wiele osób bardzo często również na samym szczycie struktury organizacyjnej.

Największe szanse na wprowadzenie realnych zmian mają organizacje z grupy pierwszej i trzeciej. Rozważając dlaczego właśnie tak się często dzieje warto zastanowić się nad tym co wywołuje opór przed zmianą. Prawdę powiedziawszy ludzie po prostu z natury boją się jakichkolwiek zmian, gdyż zmiana zawsze niesie z sobą niepewność, że to co po niej nastąpi będzie gorsze od tego co jest teraz. Oczywiście obawa ta nie jest nieuzasadniona, ale wystarczy w pełni otworzyć się nie tylko na najbliższe zmiany ale także na możliwe (albo raczej pewne) kolejne i strach zaczyna być irracjonalny. Jeśli coś pójdzie nie tak jak powinno to przecież zawsze można znowu coś zmienić.

W organizacjach typu drugiego nie ma realnej potrzeby wprowadzania zmian. Nie ma aspiracji do tego by stać się wybitnie lepszym i obecnie oraz nie ma realnych zagrożeń – przynajmniej chwilowo. Pracownicy takich organizacji, którzy często po prostu chcieli by się rozwijać i poprawiać efektywność swoją jak i swojego otoczenia często cierpią katusze z powodu słabo widocznych efektów ich działań oraz braku docenienia ich starań w kwestii poprawienia stanu obecnego.

Organizacje pierwszej kategorii nie mają problemu ze zmianami. Od pracowników tutaj wręcz wymaga się ciągłego kwestionowania status quo oraz eksperymentowania z różnymi metodami. Nie jest to oczywiście odpowiednie środowisko dla każdego niemniej jednak, ci którzy już się tam znajdą przeważnie nie narzekają na brak motywacji.

Organizacje w tarapatach również czują realną potrzebę wprowadzenia zmian. Jest to dużo trudniejsze niż w przypadku typu nr jeden, lecz opór jest znacznie niższy niż przypadku typu drugiego. Dużo łatwiej jest każdemu zracjonalizować potrzebę wprowadzenia zmian. Ponadto zazwyczaj ludzie i tak w takiej organizacji czują się zagrożeni więc zmiana rzadko kiedy może jeszcze bardziej pogorszyć sytuacje.

Reasumując, aby wprowadzić realne zmiany w organizacji potrzebna jest odpowiednia presja i dobre powody by takowe zmiany wprowadzić. Obecnie za każdym razem, gdy ktoś próbuje mnie zatrudnić do pomocy w transformacji zawsze pytam o konkretne powody wprowadzania zmian. Czasami takie dyskusje wymagają dużej ilości czasu, zastosowania metod coachingowych oraz innych narzędzi by dotrzeć do głównych potrzeb organizacji. Często okazuje się że znając powody potrzeby wprowadzania zmian jesteśmy w stanie dużo lepiej je zaadresować niż w przypadku, gdy klient przychodzi do nas z gotową propozycją rozwiązania swoich problemów i potrzebą zatrudnienia wykonawcy, który takie rozwiązanie wdroży. Zdarzyło mi się już kilkukrotnie odmówić pomocy, gdy widziałem, że jedynym powodem wprowadzania zmian w organizacji była moda lub irracjonalna chęć wykorzystania budżetu szkoleniowego w „jakiś” sposób.

Powyższe to oczywiście tylko moje luźne, subiektywne obserwacje dotyczące kilku organizacji. Nie są to sztywne reguły, które łatwo można dopasować do każdej organizacji. Są to raczej wskazówki pomagające mi i moim kolegom oraz koleżankom z Code Sprinters efektywniej pracować z naszymi klientami od samego początku – w zasadzie współpracować zanim jeszcze rozpoczniemy współpracę.

2 komentarze więcej...

Code i Coach Retreat

opublikowany przez 28, Lis, 2013, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

duck
Wielkimi krokami zbliża się Światowy Dzień Code Retreat pora więc napisać o tym wydarzeniu kilka zdań. Od kilku lat programiści na całym świecie spotykają się jak co roku w grudniu by wspólnie programować. Podczas Code Retreat nie powstaje żaden projekt czy produkt. Chodzi o wspólną pracę nad własnymi umiejętnościami a nie nad produktem.

Code Retreat to kilka sesji programistycznych trwających około godziny podczas których za każdym razem podchodzimy do rozwiązania tego samego problemu na różne sposoby. Za każdym razem zaczynamy od zera. Programujemy oczywiście w parach – gdyż w ten sposób najlepiej jest się uczyć od siebie na wzajem. Każda sesja rządzi się swoimi zasadami i w każdej pracujemy nad konkretną techniką. Po każdej sesji następuje krótka retrospekcja i omówienie tego co się nauczyliśmy.

Zabawa jest przednia i zachęcam wszystkich do udziału w tym wydarzeniu. Tak – do udziału, gdyż Code Retreat 14 Grudnia będzie organizowane również w wielu miastach w Polsce. Wystarczy pogooglować.

Ale to nie wszystko! Dla tych z Was którzy nie tylko programują mam zaproszenie na jeszcze jedno ciekawe wydarzenie (na mniejszą skalę). 05.12.2013 w Krakowie organizuję Coach Retreat. Udało mi się zaprosić jedną z pomysłodawców Coach RetreatOanę Juncu, która pomoże nam w facylitacji tego wydarzenia.

Format Coach Retreat jest zbliżony do Code Retreat:

  • najpierw wybieramy jeden z kilku przygotowanych wcześniej problemów,
  • dobieramy się w grupy max 6 osobowe,
  • jedna osoba wciela się w rolę Coacha a druga w Coachowanego
  • pozostałe osoby w grupie są obserwatorami i udzielają feedbacku w trakcie i po sesji
  • mamy 5-6 sesji coachingowych podczas których próbujemy rozwiązać problem za każdym razem przy użyciu innych metod
  • po każdej sesji retrospekcja i zmiana grup/ról w grupach

Wydarzenie jest całodniowe i raczej darmowe (możliwe jednak, że wymagana będzie drobna opłata rzędu 50zł od osoby jeśli okaże się, że będziemy potrzebować bardzo dużej sali – okaże się wkrótce). Jeśli jesteście zainteresowani udziałem piszcie na adres szkolenia@codesprinters.com lub wiktor.zolnowski@gmail.com. Ilość miejsc ograniczona!

Oana poprowadzi dla nas również warsztaty 06.12.2013 w Krakowie o interesującym tytule Test Driven Business for Lean Startup (powołajcie się na mnie przy rejestracji a czeka Was niespodzianka).

Warsztaty te to kolejny z moich „projektów”. Tym razem nie jest za darmo, ale i tak w bardzo przystępnej cenie. „Projekt” ten polega na sprowadzeniu do Polski trenerów, na których szkolenia sam bym chętnie poszedł. Wynika to z tego, ze na Polskim rynku dość już jest podstawowych szkoleń z Agile i Lean, a na szkoleniu ze Scrum to już chyba każdy był. Ostatnia konferencja Agile By Example potwierdziła moją tezę, że praktycy w naszym kraju wyszli już na wyższy level. Teraz potrzebujemy czegoś więcej niż podstawowe szkolenia na oklepane tematy – potrzebujemy rozwoju. Ja też go potrzebuję dlatego z pewnością w warsztatach Oany wezmę udział jako uczestnik. W przyszłym roku pojawią się kolejne ciekawe szkolenia prowadzone przez niesamowitych trenerów z całego świata.

2 komentarze więcej...

Agile dla „dużych projektów” nie działa

opublikowany przez 19, Wrz, 2013, w kategoriach Agile, Kanban, Scrum, Testowanie, XP, Zarządzanie

5665717830_dfe3ea51c2_o

Po raz kolejny ktoś próbował mi udowodnić, że Agile dla „dużych projektów” się nie sprawdzi. I… Generalnie zgadzam się z tym stwierdzeniem. Zgadzam się, tak! Agile dla „dużych projektów” nie działa!

Agile z pewnością nie zadziała jeśli za miarę wielkości „dużego projektu” przyjmiemy ilość ludzi nad tym projektem pracujących. Jeśli duże projekty dla Was to takie nad którymi pracuje 200 lub więcej osób to macie znacznie większe problemy niż, to czy Agile zadziała, czy nie.

„Duże projekty” to dysfunkcja sama w sobie.

Programowanie jest rozwiązywaniem problemów – nie potrafię sobie wyobrazić problemu, który potrzebował by więcej niż kilkadziesiąt osób do jego rozwiązania. Owszem, niektóre problemy są bardziej złożone od innych – w takim przypadku jedyne rozsądne rozwiązanie to rozbicie ich na mniejsze – być może mniej złożone problemy i stworzenie mniejszych zespołów rozwiązujących je.

Waterfall powstał właśnie po to, by radzić sobie z „dużymi projektami”. Waterfall jest cool. Waterfall działa… dopóki nie zaczniesz się nad tym zastanawiać…

Cała pseudonauka o tym w jaki sposób powinniśmy testować (oczywiście manualnie) skomplikowane projekty, zarządzać milionami przypadków testowych, poprawnie zgłaszać miliony bugów, następnie zarządzać tymi zgłoszeniami, mierzyć ilość tych zgłoszeń i co gorsza tworzyć z tego metryki mające na celu określenie jakości pracy testerów [BLAH!], to wszystko powstało w odpowiedzi na realne problemy. Problemy, które sami sobie stworzyliśmy budując niewłaściwe oprogramowanie w niewłaściwy sposób.

Skalowanie Agile to kolejny urojony problem.

Coraz więcej na około słyszy się o nowych, pięknych i kompleksowych metodach skalowania Agile. Niektóre z nich nawet zapewne działają. Ba, nawet widziałem je w działaniu. Niestety nadal są to narzędzia służące do rozwiązywania problemów, które ktoś, gdzieś sam sobie stworzył.

Agile nie trzeba skalować, jeśli jesteśmy w stanie przeskalować nasz produkt. Tak jak na przykład zrobili to w Spotify. Kluczem do sukcesu nie jest stworzenie squad’ów, tribe’ów, chapter’ów czy guild’ów… To wszystko powstało tylko po to by wokół wielu, względnie niezależnych komponentów produktu, rozwijanych przez interdyscyplinarne i kros-funkcjonalne zespoły stworzyć platformę służącą do synchronizacji pracy i wymiany wiedzy. Agile jest gdzieś indziej – w każdym zespole z osobna. Nie ma tutaj żadnego skalowania.

Więc tak, Agile nie działa w „dużych projektach”! Duże projekty są problemem samym w sobie. Nie chcę tutaj rozwodzić się nad potencjalnymi i faktycznymi przyczynami tego dlaczego nadal mamy do czynienia z tak wieloma „dużymi projektami”. To nie jest czas na to – niech ten post będzie dla Was przestrogą, by Wasze małe jeszcze projekty nigdy nie stały się „dużymi projektami”.

8 komentarzy więcej...

Czy potrzebujesz Agile Coacha?

opublikowany przez 10, Wrz, 2013, w kategoriach Agile, Coaching, Kanban, Praca, Scrum, XP, Zarządzanie

2536358399_88e6544fa9_o
Po raz kolejny utwierdziłem się w przekonaniu, że ludzie nie czytają, nie tylko moich książek, czy mojego bloga… Ludzie nie czytają w ogóle, albo czytają bardzo mało rzeczy związanych z ich pracą. Utwierdziłem się w sposób najprostszy – pytając około 35 osób czy czytają… Ludzie nie czytają i nie jeżdżą na konferencje bo najzwyczajniej nie mają na to czasu przez pracę. Często przez to, że ich praca jest nieefektywna muszą pracować więcej, by osiągnąć oczekiwane rezultaty. Pracując więcej nie mają czasu na to, by poczytać o tym jak pracować efektywniej…

I w sumie bardzo dobrze… Bo ja czytam… Bo ja piszę książki… Bo ja jeżdżę na konferencje i czasem tam coś opowiadam… Publikuję czasem coś na blogu ale przede wszystkim czytam blogi innych… Poświęcam dużo czasu na naukę nowych rzeczy, ale też na przemyślenia związane z praktycznym zastosowaniem tego co już umiem… Eksperymentuje z nabytą wiedzą stosując ją w praktyce… Ciągle nabywam coraz więcej doświadczenia związanego z tymi tematami… Bardzo różnorodnego doświadczenia dzięki pracy dla bardzo różnych klientów… Klientów w różnym kontekście, w różnym środowisku, w różnych technologiach i w różnych branżach… Rozmawiam z ludźmi, dzielę się swoim doświadczeniem ale też korzystam z doświadczeń innych…

Właśnie to wszytko, właśnie to, że ja MAM na to czas i że swój czas na to właśnie poświęcam jest głównym powodem tego, że bardziej opłaca Ci się zatrudnić mnie jako Agile Coacha, jako Mentora, jako Trenera, jako Doradce, niż samemu poświęcać nieskończoną ilość godzin na wyszukiwanie i zdobywanie tej wiedzy i doświadczenia. Jest to również bardziej opłacalne niż samodzielne popełnianie błędów – zwłaszcza tych kosztownych i tych, które ja już wcześniej miałem okazję popełnić, lub zaobserwować gdzieś indziej.

Poza tym ja lubię to robić. Robię to z pasją. Nie traktuję tego nawet jak pracę – jest to bardziej moje hobby…

Dość tej autopromocji! Generalnie chodzi o to, że zdobywanie wiedzy to również ciężka praca wymagające wielu poświęceń, a już na pewno dużej ilości poświęconego czasu. Czasem można jednak zdać się na kogoś, kto już tą wiedzę posiada, albo ma czas na to, by zdobyciu tej konkretnej wiedzy się poświęcić…

8 komentarzy więcej...

Kolejny post o diecie

opublikowany przez 21, Sie, 2013, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

Dieta

I po raz kolejny będę pisał o diecie. O diecie dla organizacji. Tym razem zainspirował mnie artykuł, który Dion Almaer opublikował na portalu medium.com (swoją drogą sporo fajnych tekstów na tym portalu, sam też powoli zaczynam tam publikować – polecam).

Wróćmy na chwilę do poprzedniego wpisu w tym temacie oraz odpowiedzi nadesłanej przez Michała Gozderę. Ciekawą dyskusję wywołały powody przejścia na dietę. W przypadku diety mojej własnej może to być na przykład chęć lepszego samopoczucia czy też uzyskanie możliwości patrzenia w lustro bez odrazy do samego siebie. Może to być idea zdrowego i długiego życia, na które szans nie mamy, gdy mamy nadwagę i źle się odżywiamy. A może po prostu chcieli byśmy uzyskać lepszą sprawność fizyczną i wypracować lepszą kondycję by nie umierać po przebiegnięciu kilkunastu metrów w pogoni za odjeżdżającym autobusem.

Podobnie jeśli chcemy zmienić (odchudzić) naszą organizację również musimy mieć do tego dobry powód. Na tyle dobry byśmy sami byli do niego wystarczająco przekonani i byśmy mogli przekonać innych. Często będzie to już niepokojący stan obecny naszej firmy (nie możemy spokojnie spoglądać w lustro).

Dion w swoim artykule napisał coś bardzo istotnego – należy zacząć od restrykcyjnej diety, gdyż uprawianie sportu przy dużej nadwadze wcale nie sprawia przyjemności. Podobnie w przypadku organizacji, gdy cierpi ona na „nadwagę” nie sposób wdrożyć w niej pewnych metod takich jak na przykład TDD czy chociażby automatyzacja testów. A już na pewno nie będzie to przyjemne i łatwe.

Jak już wcześniej pisałem metody takie jak Kanban czy Scrum są swego rodzaju dietą dla naszej organizacji. Same w sobie nie wystarczą do tego, by już na zawsze być zwinnym. Do tego potrzeba długotrwałych zmian nawyków żywieniowych czyli w naszym przypadku zmiany kultury organizacyjnej.

Czy to znaczy, że z pewnymi praktykami i metodami musimy poczekać? Nie, czekać nie musimy, a nawet nie powinniśmy – wspomniane praktyki dodatkowo wzmacniają dyscyplinę i poprawiają efekty naszej „diety”. Niemniej jednak należy pamiętać o tym, że w pewnych sytuacjach będzie to bolesne i może nawet prowadzić do „uszczerbku na zdrowiu”. Bieganie przy dużej nadwadze może skończyć się problemami z kręgosłupem i/lub stawami u nóg, dlatego taki trening musi być dobrze dopasowany do naszych możliwości.

Zasada numer jeden: „mniej jeść” – a w zasadzie jeść rozsądniej i bardziej świadomie. Czy nie na tym właśnie bazuje Scrum czy Kanban? Mamy jeden backlog i ograniczone możliwości realizacji zadań więc musimy wybrać to co jest na tym backlogu najbardziej wartościowe.

Wyobraźmy sobie, że nasze codzienne menu jest zapisane w postaci backlogu – dodajmy limit kalorii (czyli nasze velocity) i teraz możemy uporządkować backlog tak by osiągnąć największą wartość (wartość odżywczą i jednocześnie przyjemność z jedzenia). Nie, nie próbowałem tego – to tylko taki eksperyment myślowy (ale w sumie kto wie…).

Jeszcze jedno wartościowe przesłanie z wspomnianego artykułu – bardzo ważne są widoczne efekty. To właśnie one wzmacniają naszą motywację do dalszego działania. Dlatego też warto zwłaszcza na początku obrać strategię małych zmian dających widoczne efekty.

1 komentarz więcej...

W odpowiedzi na: Organizacja na diecie

opublikowany przez 14, Maj, 2013, w kategoriach Agile, Kanban, Scrum, Zarządzanie

W odpowiedzi na ostatni wpis dostałem świetny feedback od Michała Gozdery, który zwrócił uwagę na szczegóły, które mi umknęły. Poniżej mail od Michała wraz z moimi komentarzami.
Dzięki za ostatni wpis na blogu. Trafiłeś w sedno bo akurat w firmie walczymy z wdrożeniem Scruma, a prywatnie walczę z kolejnym podejściem do diety. Dzięki temu że zwróciłeś moją uwagę na tą analogię mam sporo nowych przemyśleń dotyczących i jednego i drugiego.
Jedno z pierwszych przemyśleń dotyczyło tego że zrobiłeś w tym rozumowaniu jeden krok za mało. Zupełnie nie kupuję tego że celem diety jest zmiana nawyków żywieniowych albo celem wdrożenia np scrum w firmie jest zmiana myślenia czy uczynienie jej zwinną. Po kolei jak ja to widzę:
Dieta u mnie:
1. Trzymam się diety którą sobie ustalam bo…
2. chcę zmienić swoje nawyki żywieniowe bo…
3. chce schudnąć i dodatkowo utrzymać tą wagę bo…
4 dzięki temu chcę osiągnąć to co jest dla mnie ważne: być zdrowym żeby móc się cieszyć życiem – bawić się z córką, móc pograć w kosza z kumplami i nie zdychać po 10 minutach biegania itd.
Zgadzam się! Faktycznie o jeden krok za mało! Jak to mówią szefc bez butów chodzi – cały czas powtarzam swoim zespołom żeby zawsze mieli świadomość celu, dla którego coś robią. Ale takiego prawdziwego. By zawsze zwracali uwagę na to, co ich na prawdę motywuje i co jest dla nich ważne – nie tylko w pracy ale i w całym życiu. Żeby wiedzieli DLACZEGO coś robią. Zmiana nawyków żywieniowych nie jest celem samym w sobie.
Pkt 2 to też nie cel tylko środek, to najlepszy kolejny krok który w tym momencie widzę żeby osiągnąć 4, ale są większe szanse osiągnąć 4 inną ścieżką to zmienię to bez sentymentu. Jeśli patrzymy na 2 jako na cel a nie widzimy 4 to wiążemy sobie ręce. Zmienić cel jest zdecydowanie trudniej niż ścieżkę do niego.
To jest chyba kwestia nie tyle środków – co świadomości tego, po co dane środki są i jak je stosować. Co moga nam dać etc. Ale tak jak napisalem powyżej – faktycznie 2. nie jest celem samo w sobie. To jest raczej świadomość tego jak działają narzędzia które chcemy stosować. Dzięki tej wiedzy możemy z tych narzędzi korzystać lepiej i mamy szanse na to, by faktycznie zadziałały i pomogły nam osiagnąć cel.
Zmiana w organizacji:
1. Wdrażamy scruma bo …
2. chcemy zmienić swój mindset i być jako organizacja zwinni bo…
3. chcemy regularnie dostarczać działający soft bo…
4. chcemy dawać klientom to czego potrzebują i dzięki temu zarabiać kasę
4 to chcąc nie chcąc cel ostateczny w biznesie. Masz rację że 1 to środek ale 2 i 3 również. Jeśli firma zarabialaby bez bycia agile to byłoby ok, jeśli bez dostarczania sotfu zarabiałaby coraz większą kasę to też byłoby ok. Sytuacja z różnicą w spojrzeniu na 2 jako cel i jako środek do osiągnięcia celu jest analogiczna jak przy diecie.
Zgodzam się. Zwłaszcza z tym, że nawet jeśli organizacja nie jest Agile i nie dostarcza softu ale zarabia pieniądze to nie ma sensu przejmować się tym jak to robi. Tak jak jeśli jesteśmy w dobrej kondycji fizycznej i psychicznej oraz cieszymy się zdrowiem to nie ma sensu stosować żadnych diet na siłę.
Pokazanie 2 jako cel może mieć dobre strony bo jesteśmy bardziej zmotywowaniu żeby go osiągnąć. Mniejsze są pokusy że damy sobie spokój przy pierwszych niepowodzeniach. Można to wykorzystać ale to śliskie. To byłoby oszukiwanie samego siebie albo ludzi których przekonujemy do scruma.
Chyba faktycznie coś istotnego mi w tym wpisie umknęło. Celem jest to co napisałeś w 4. – zarabianie kasy. Zarabianie kasy poprzez dostarczanie działającego oprogramowania klientom. Oprogramowaia, którego potrzebują. Oczywiście to przeważnie jest jeszcze za mało by osiagnąć cel (kasa) – potrzebujemy jeszcze na przykład sprzedaży. Oprócz tego ważne jest to, by robić to wszystko nie tylko dla pieniędzy ale dla jakiejś większej idei – w ten sposób powstawały najwieksze i najlepsze firmy.
Zupełny bonus który przyszedł mi do głowy to kwestia transparentnosci. Przekonuję developerów czy Scrum Masterów, że nawet jeśli nie dowieźli sprintu to i tak warto zaprosić jak najwięcej ludzi na review, przyznać się że ten jeden kroczek się nie udał i powinniśmy o tym pamiętać i nie wypierać żeby nie zapomnieć nauki jaką możemy z tego wynieść a… ważąc się codziennie zapisywałem wyniki w aplikacji do tego (wykresiki i inne bajery;)) i jak okazywało się że jest gorzej niż dzień wcześniej to zawsze znalazłem wymówkę żeby tego nie wpisać żeby nie psuło mi statystyk. Dziś sam dałem sobie za to w pysk 😉
Tak! To jest istotne także dlatego, że wiele osób jest zależnych od tego jak my jako zespół pracujemy i co dostarczamy. Większosć z tych osób potrzebuje informacji – jak najwcześniej – by podejmować decyzje. Wiele razy widziałem sytuacje, w których na przykład obok zespołów pracująćych w Scrum był tradycyjny product management, gdzie na Wykresach Ganta ktoś w genialny sposób zarządzał całościową produkcja skomplikowanych produktów. Jedyncze czego potrzebował to wartościowe informacje, by zasilić swoje algorytmy optymalizacji szeregów produkcyjnych. Im wcześniej i im więcej informacji otrzymywał tym lepiej mógł zareagować.
Jeszcze raz dziękuję za feedback. I oczywiście będę wdzięczny za kolejne komentarze!
Dodaj komentarz więcej...