Dla kogo jest “Right to Left” – najnowsza książka Mike’a Burrowsa? Autor mówi, że dla liderów cyfrowej ery. Ja sądzę, że nie jeden Agile Coach może się z niej nauczyć patrzeć szerzej na organizację, narzędzia i metodyki.
Read More »
Dla kogo jest “Right to Left” – najnowsza książka Mike’a Burrowsa? Autor mówi, że dla liderów cyfrowej ery. Ja sądzę, że nie jeden Agile Coach może się z niej nauczyć patrzeć szerzej na organizację, narzędzia i metodyki.
Read More »Czyli o tym co stolik z IKEA, rejestracja w Mailchimpie i twój proces i produkt powinny mieć wspólnego?
Read More »W listopadzie będę miał okazję na pierwsze spotkanie ze społecznością Agile Poznań. To grupa, która osiągnęła ostatnio 1000 członków i działa bardzo prężnie. Na zaproszenie społeczności poprowadzę warsztat z leanowego narzędzia A3 z nowym scenariuszem.
Niech PDCA będzie z Wami!
W tym roku mam wielką przyjemność zawitać na AgileByExample w charakterze prelegenta. Pierwszego dnia (Dojos) poprowadzę warsztat dotyczący metryk Lean, które można z powodzeniem stosować w różnych środowiskach pracy.
Trzeciego dnia konferencji będę miał krótką prezentację dotyczącą Kadencji Kanbanu – tematu, który pozostaje nadal w cieniu kanbanowej “tablicy” a który dobrze zrozumiany może pomóc w komunikacji i synchronizacji organizacjom dużym i małym.
Do zobaczenia w Warszawie!
Serię wpisów o Kadencjach Kanbanu zaczynam od tego jak może wyglądać codzienne spotkanie zespołu skupionego na przepływie wartości i korzystającego z dobrodziejstw Kanbanu, Oto kilka wskazówek o tym jak “przechodzić przez tablicę”. Również dla scrumowców.. 😉
Za nami kolejne spotkanie. Lato w pełni więc zamiast biura na miejsce spotkania wybraliśmy jeden z wrocławskich beach barów. Dopisały pogoda, frekwencja i dyskusja. A o czym? O stratach i między innymi o tym, że błąd nie musi oznaczać winy oraz jak zrobić z błędu okazję do rozwoju.
Read More »
Wiesz, gdzie zrobiłem to zdjęcie? Tak, w Ikei. W sobotę. Co? W sobotę do Ikei? Samobójstwo! Było warto. Oto kilka przemyśleń o leanowej organizacji, wizualizacji i metrykach przepływu – czymś, co lubią klienci Ikei i Twoi też by polubili.
Nie przychodzi mi na myśl lepszy dowód na samodyscyplinę niż dokończenie serii wpisów na blogu na ten sam temat. Na koniec cyklu o 5S w IT, kilka przemyśleń o dwóch obliczach ostatniego S – samodyscyplinie i samodoskonaleniu.
W ubiegły piątek miałem zaszczyt i przyjemność poprowadzić warsztat w ramach zwinnej konferencji Agile on the Boat organizowanej przez społeczność Agile Wrocław. Oto kilka słów o tym jak poszło swoiste śledztwo sytuacji w zespole „Mściciele” z wykorzystaniem narzędzi lean – arkusza A3 i 5 x Dlaczego. Czy i jaką wartość widzą w nich uczestnicy?
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ć: