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ść.