Z serii 5S w IT – 4S czyli straszny wyraz standaryzacja

Czas na wpis poświęcony czwartemu S – standaryzacji – pojęciu, którego branża IT bardzo się boi. Czy strach ten ma rzeczowe podstawy, czy też wynika z niepełnego zrozumienia czym jest standard, ile trwa i jak z nim postępować?

Tam gdzie nie ma standardu, nie ma szans na doskonalenie (kaizen).

Produkcyjni leanowcy powtarzają powyższy cytat z Taichii Ohno jak swoją mantrę. Gdy tylko wspomni się o standardzie w IT, bledną twarze i zaczynają się historyjki o korporacyjnych absurdach i szalonych konsultantach wyklejających tablice cieni na biurkach.

Standard nie oznacza robienia wszystkiego i przez wszystkich w identyczny sposób.

Jedna z japońskich definicji kaizen – a więc podejścia ciągłego doskonalenia mówi, że musimy z pokorą uznać obecnie funkcjonujący system, lub proces (a więc obecnie wypracowany standard) za najgorszy z możliwych i zacząć szukać dalszej poprawy.

Praktycznie za każdym razem, gdy opowiadam o tym osobom, które nie słyszały tej definicji, reakcje są podobne – to takie negatywne! We znaki daje się tu różnica kulturowa. W świecie zachodnim lubimy przywiązywać się do osiągnięć, szczególnie jeśli są one naszym osobistym sukcesem. Funkcjonując w kulcie osiągnięć jednostki, brak nam pokory, by dać „swoje” łatwo krytykować. W kulturze Dalekiego Wschodu, kulturze kolektywnej, osiągnięcie częściej bywa „nasze” niż „moje”. Co za tym idzie, mniejszy jest opór przed krytyką i podważaniem, a w efekcie doskonaleniem.

Po co o tym piszę? Jak wspomniałem standaryzacja jest terminem, którego wiele osób, szczególnie w branży pracy intelektualnej się boi. Standard przywodzi nam na myśl korporacyjne polityki narzucania jednego słusznego systemu operacyjnego, jednej słusznej aplikacji do […], jednej biurokratycznej ścieżki postępowania. Już przy wpisie o sortowaniu i wyborze narzędzi zadaliśmy temu kłam.

Jeśli zrozumiemy prawdziwie leanowe podejście do standardu, zrozumiemy, że jest on właściwie tylko chwilową stabilizacją na długiej (niekończącej się?) drodze ewolucji.

Standard nie jest czymś, co nie ulega zmianie w czasie.

Może czas na mniej abstrakcji a więcej życiowych przykładów? OK. Jeśli zespół, który wypuszczał dotąd swój produkt całkowicie nieprzewidywalnie lub w najlepszym przypadku w odstępach miesięcy, osiąga sukces w postaci zdolności wypuszczania kodu na produkcję co dwa tygodnie i taką kadencję daje się przez pewien okres utrzymać, to możemy mówić o standardzie. Widzicie tu coś niebezpiecznego? Standaryzacja to inaczej normalizacja. Coś staje się normą postępowania, przewidywalną formą postępowania.

Gdy ten etap (niełatwy) mamy za sobą stajemy przed pytaniem – czy i jak powinniśmy teraz owego standardu bronić? To zależy, w która stronę miałyby iść zmiany. Pewnie zgodzicie się, że powrót do chaosu nie byłby preferowanym scenariuszem. Na pewno warto bronić dotychczasowych osiągnieć przed pogorszeniem. Ustanowienie standardowego procesu przygotowania do releasu, aktualne definicje ukończenia, checklisty, czy też automatyzacja testów i integracji powinny na jakiś czas uspokoić nasze myśli. Dzięki tak rozumianej standaryzacji powinniśmy mieć więcej czasu na istotne sprawy a mniej potrzeb gaszenia pożarów, czy ręcznych interwencji.

Czy to również koniec zmian na lepsze? Czy uznamy, że dwutygodniowa częstotliwość releasowania to maksimum naszych możliwości?

Stary standard może a nawet powinien okazać się wkrótce niewystarczający. Tu na myśl przychodzi jeden z mitów, w które obrósł swego czasu Scrum. Skoro sprint trwa dwa tygodnie i co dwa tygodnie mamy mieć potencjalnie dostarczalny produkt to.. wrzucajmy go na produkcję.. co dwa tygodnie. Amen. Serio?

Rozwój metod i narzędzi do continuous deployment i continuous delivery, czy praktyki DevOps podważyły sens takiego złego standardu w wielu organizacjach, co musiało w końcu znaleźć odzwierciedlenie w oficjalnej wykładni Scruma. Jeśli możemy wrzucać coś na produkcję częściej, to czemu tego nie robić? A przynajmniej warto zacząć od prób, których efekt wkrótce może stać się.. standardem. Warto dodać tu leanowe skupienie na jakości tego, co wrzucamy. Wrzucamy odpowiedzialnie, ze skupieniem na kliencie i jego potrzebach. Nie pozwólmy by częste releasy, szczególnie o wątpliwej jakości stały się celem samym w sobie.

Mam cichą nadzieję, że może zaczynasz myśleć, że te standardy nie są takie straszne. A co zrobić, żeby się takimi nie stały? Poddawajmy je regularnej ocenie. Bardzo pomaga w tym.. a jakże.. wizualizacja.

Zdrowej standaryzacji mogą podlegać:

  • narzędzia – tymczasowy oraz lokalny (zespołowy) standard w kwestii narzędzi, czy to do przechowywania informacji, czy pracy z kodem powstaje właściwie naturalnie po ukończeniu etapów sortowania i systematyki. „Narzędziownik” w postaci flipa i post-itów to świetny starter do uczenia się od innych zespołów, szukania inspiracji.
  • procesy – wspólne rozumienie z ilu i jakich etapów składa się jakiś proces. Mapa strumienia wartości (VSM), czy choćby wydruk procesu (workflow) z Jiry ułatwią zrozumienie gdzie jesteśmy, aby dalej pozwala upraszczać i aktualizować go.
  • czynności – takie jak regularne spotkania, czy przegląd kodu to również coś, co powinniśmy zestandaryzować i praktycznie natychmiast zaplanować ich przegląd by żadne nie stało się reliktem a wszystkie miały istotny cel i przynosiły wartość.

 

Z serii 5S w IT – 3S czyli sprzątanie

W pracy intelektualnej używamy narzędzi, które generują, przetwarzają i przechowują coraz większe ilości informacji. Nawet jeśli nasze biurka wyglądają na czyste, jak te z katalogu mebli biurowych, to zwykle zostawiamy po sobie bałagan w postaci rozproszonej informacji czy dokumentacji. Jeśli tego nie widać, to czy warto po sobie sprzątać? 

Read More »

Z serii 5S w IT: 1S czyli sortowanie

– Słuchaj, chciałem złapać kogoś od tego nowego projektu, ale nie widzę ich na Slacku..

– Nie, oni nie mają dostępu do Slacka. Zapytaj któregoś z PO o ich maile i podłącz się na Skypie. Aha, ale nie tym naszym biznesowym tylko publicznym.

Znasz takie przypadki? Ja niestety tak. Wielość narzędzi służących w zasadzie do tego samego, to najłatwiejszy ale nie jedyny cel przedstawienia w organizacji IT potencjalnych korzyści płynących z 1S a więc sortowania.

Gdzie działać z 1S?

Jeśli głębiej to przemyślimy, dotyczy to w równej mierze narzędzi do:

  • komunikacji (e-mail, Slack, Hipchat, Microsoft Teams, Skype, itd.)
  • przechowywania dokumentacji (wszelkiego rodzaju Wiki, dokumenty Google, Office Online, własne dyski sieciowe, Confluence, Sharepoint, itp.)
  • developerskich, testerskich
  • integracji i deploymentu
  • analizy (business intelligence) usług i produktów

Ale uwaga! Idę o zakład, że dotyczy to również spotkań, raportów, czy innych reliktów* występujących w Twojej organizacji.

Przyczyny?

Nim przejdziemy do akcji zastanówmy się czemu tak się dzieje? Czemu obrastamy w niepotrzebne narzędzia, czy wydarzenia? Bo jesteśmy ludźmi a miara nieuporządkowania we Wszechświecie rośnie. No dobrze, a po ludzku się nie da? Da.

Dajmy na to, że kilka lat temu, ktoś powodowany konkretną potrzebą i dobrą wolą wprowadził narzędzie X lub spotkanie Y, które rozwiązało (lub nie) ówczesny problem. Potem realia biznesu się zmieniają, pojawia następny problem, nowe narzędzie Z a w międzyczasie osoba odpowiedzialna za X odchodzi z firmy. Znów brzmi znajomo?

Narzędzie X i spotkanie Y mogą przetrwać w organizacji nawet lata stając się właśnie reliktami. Niczym wyrostek robaczkowy, który choć nie jest nam potrzebny i nawet jeśli na co dzień nie przeszkadza, to może kosztować nas w końcu niepotrzebną operację.

Gdyby narzędzia i metody, a wraz z nimi spotkania, nie mnożyły się tak szybko, byłoby może łatwiej. Mamy jednak coraz większy wybór i dodatkowy problem mody i fetyszu rzeczy nowych. Instalujemy Slacka bo jest był na niego „hajp”, ale dla tego jednego klienta, z którym nie ma kto porozmawiać, utrzymajmy jeszcze Hipchata. Może to on za niego płaci, więc co za strata?

W czasach gdy chmura jest tania, łącza szybkie, a licencje płatne za użytkownika wydaje się, że mnogość rozwiązań nie boli. W istocie boli. Boli w wymiarze organizacji pracy. Boli stratami czasu potrzebnego na wybór i przełączanie się między narzędziami i wyszukiwanie informacji. Boli doświadczonych członków zespołu, którzy muszą wyszukać coś (podkreślam) _za_ juniora, bo nikt nowy nie jest w stanie dokopać się do instrukcji deploymentu, itd.

Jak już napisałem, to samo tyczy się spotkań, raportów i pewnych ceremonii.

Pogrążeni w codziennej zajętości, nie mamy czasu ani energii na podważanie status quo. A szkoda, bo częściej niż myślimy są szanse na poprawę!

Do dzieła!

Na czym polega 1S w produkcji? W uproszczeniu na przeglądzie narzędzi, które pracownik ma na swoim stanowisku pracy. Czy są tam rzeczy, których nie potrzebuje? Jeśli tak, naklej na nie czerwoną etykietę i jeśli nie zostały użyte w przeciągu kilku dni, usuń je. Nie brakuje ich? Były niepotrzebne. Tak systematycznie odchudzamy warsztat, redukujemy straty w sprzęcie i czasie. Proste. A w IT?

Wcale nie musi być trudniej. Czasem wystarczy wspólny warsztat i uświadomienie istniejących strat. Wspólne uzgodnienie, którego narzędzia używamy do konkretnych zadań. Poszukajmy wspólnie rozwiązań by zmniejszyć ich ilość. Jeśli wymaga to dialogu z biznesem, zwykle pomaga niezbyt skomplikowana analiza ekonomiczna proponowanych zmian.

A spotkania? Przejrzyj swój kalendarz. Zadaj sobie pytanie, czy wiesz jaki jest cel każdego spotkania które organizujesz, czy wiedzą to Ci, których zapraszasz. To samo odnosi się do tych, na które jesteś zapraszany lub zapraszana.

To wymaga oczywiście odpowiedniego nastawiania, bo jeśli ważność ludzi w Twojej organizacji jest budowana w oparciu o to, ile prowadzą spotkań, to potrzebne tu będzie odpowiednie przygotowanie psychologiczne lub socjologiczne. Twarde zderzanie faktów z emocjami nie idzie zwykle jak po maśle.

Jak nie przesadzić?

No tak, ale my jesteśmy zwinni! Jesteśmy start-up’em i nie chcemy tu wielkiej korporacyjnej unifikacji. Świetnie. 1S nie ma na celu narzucenia jednego słusznego narzędzia czy eliminacji czegoś za wszelką cenę. Ma na celu wyeliminowanego narzędzi i czynności niepotrzebnych, nadmiarowych, które zmuszają nasze mózgi do ciągłego przełączania kontekstu, poszukiwania. Nie oznacza to również, że nie możemy poddać ewaluacji nowych narzędzi i dołączać ich, albo lepiej przełączyć się na nie.

Dzięki 1S (sortowaniu) możemy zaoszczędzić sobie i innym najcenniejszej waluty współczesnego świata – czasu.

5S w IT – bulls*it czy bingo?

Kiedy rozmawiam o leanie z kimś ze świata produkcji, 5S jest zwykle jednym z pierwszych wspominanych tematów. Gdy pytam o to w świecie pracy intelektualnej, najczęściej spotykam się ze zdziwieniem, lub ironią – Nie, nie wyklejamy cieni pod myszkę i klawiaturę. Świetnie, wygląda na to, że już nawet wiesz czego nie robić. Zapraszam do zgłębienia tematu i sięgnięcia po potencjalne korzyści z choćby kilku wybranych „S” wdrożonych do pracy przy produkcie lub usługach.

Read More »

Featureban? 100 % analogowo!

Dziś tylko krótki cross-posting. W ostatnich miesiącach dużo eksperymentuję z grą Featureban, którą w całości przeprowadzam w postaci analogowej. Działa to zarówno gdy skupiam się na wprowadzeniu w metodę Kanban jak i w skupieniu na metrykach lean. Opublikowałem o tym wpis na stronie poświęconej polskiemu tłumaczeniu gry, czyli grafeatureban.wordpress.com. Zapraszam do lektury! Po warsztacie na Agile Wrocław będzie jeszcze więcej!

2. Wrocław Lean Coffee – Mapowanie strumienia wartości

W ubiegłą środę Wrocławska Lean Coffee przełamała syndrom „artysty jednego albumu” i ma za sobą drugie spotkanie! W oparciu o wyniki ankiety interesujących tematów spotkanie było poświęcone mapowaniu strumienia wartości (VSM). Jak było i czego się nauczyliśmy?

Po pierwsze, znów dopisała frekwencja. Na 15 miejsc, zjawiło się.. 16 osób. Serce rośnie widząc, że uczestnicy z szacunkiem podchodzą do RSVP ma Meetupie i zwalniają miejsca oczekującym. Jeszcze większą radość powodują „stali bywalcy” a tym razem również silna reprezentacja Agile Wrocław!

Ale przejdźmy do meritum. Po krótkim wprowadzeniu teoretycznym, uczestnicy stanęli przed wyzwaniem zmapowania procesu.. przygotowywania kawy. W końcu musi być jakaś kawa na Lean Coffee, prawda?

Dzielny Rafał stawił czoła obiektywom kamer, licznym gapiom i nienajłatwiejszemu klientowi (dzięki Filip!). Potem 3 grupy rzuciły się w wir dyskusji o tym, jak ten proces wyglądał, na jakie aktywności można go podzielić i jaki przypisać im kolor. Wartość? Strata? A może konieczność?

Z punktu widzenia osoby, która obserwowała i wsłuchiwała się dyskusję wszystkich trzech grup mam kilka spostrzeżeń:

  1. W grupie, w której jednym z uczestników był również klient, zielonych karteczek, a więc tych oznaczających wartość dodaną dla klienta, było najmniej. Jak policzyliśmy stanowiło to około 4 procent czasu trwania całego łańcucha, co udało się ostatecznie podwoić. W grupach, które miały tylko możliwość własnej interpretacji tego, co dla klienta jest wartością, zieleni było znacznie więcej.
  2. We wszystkich grupach dało się zaobserwować skłonność do „uzasadniania konieczności strat” a więc nadużywania koloru pomarańczowego. To coś, co obserwuję przy każdym ćwiczeniu z VSM. Szczególnie kiedy omawiamy prawdziwy, bardziej złożony proces, mamy wszyscy skłonność do „obrony” stanu obecnego i może w zagrożeniu własnych ról i odpowiedzialności, dobudowujemy przyczyny konieczności jakichś aktywności.
  3. Ostatnie spostrzeżenie dotyczy tego, jak różnie grupy podeszły do modelowania przyszłego procesu. Było i pytanie o to, co można, jakie są granice, ale były też odważniejsze ruchy i zmiany mimo instrukcji „gramy z tym, co mamy”.

Ostatecznie wszystkim grupom udało się zaprojektować procesy conajmniej o połowę krótsze. Dwa z nich zweryfikowaliśmy (tym razem podziękowania również dla Ani!). Co ciekawe, patrząc z perspektywy gęstości wartości, może być jej procentowo mniej, ale w którszym procesie „i tak bedzie Pan zadowolony”.

W następującej po warsztacie dyskusji nie było zaskoczenia. Najgorętszym tematem była dyskusja o definicji wartości – tej dla klienta, tej dla biznesu, czy też tej dla organizacji np. postaci pozyskiwania wiedzy i umiejętności. Kolejno zajęliśmy się debatą jak VSM aplikować do pracy przy oprogramowaniu i tym na jakich przykładach uczyć tego narzędzia. Dobrym podsumowaniem była kartka z przemyśleniem.. że ważną podstawą jest zaproszenie do pracy nad mapą strumienia wszystkich interesariuszy analizowanego strumienia. Tematów znów więcej niż czasu..

Następne Lean Coffee pewnie jeszcze w lutym. Czy od razu rzucimy się na kolejny temat z ankiety jeszcze nie wiem, bo kusi mnie ekspryment ze spotkaniem, które nie musi mieć tematu przewodniego. Jak pokazuje dotychczasowe doświadczenie, uczestnicy sami są w stanie wygenerować sporo angażujących tematów i wiedzy.

Na koniec wielkie dzięki dla uczestników, bo bez nich by się nie udało, dla NetworkedAssets – za to, że było gdzie się spotkać i dla Kingi za pomoc w przygotowaniach!

Dzięki i do zobaczenia!