Scrum a kultura bylejakości

styczeń 27, 2010 autor: Andy Brandt
Kategoria: Artykuły 

Ostatnio miałem okazję obserwować jak w pewnym zespole (a właściwie dwóch) Scrum nie daje oczekiwanych rezultatów. Pomimo szkoleń, zatrudnienia Certyfikowanych Scrum Masterów nadal problemem jest niska jakość tworzonego oprogramowania, chaotyczność pracy, nieprzewidywalność rezultatów.

Jak się wydaje wynika to z jednego podstawowego problemu, który trudno określić inaczej niż “kultura bylejakości”. Jest to połączenie niemożności osiągnięcia zakładanego poziomu jakości tworzonego systemu z akceptacją tego stanu rzeczy przez otoczenie obu zespołów. Ta akceptacja jest pełna rezygnacji, by nie powiedzieć fatalizmu, zwłaszcza ze strony kluczowych odbiorców systemu (oba zespoły budują systemy wewnętrzne) – ale jest. Efektem jest funkcjonowanie całkiem poważnie nastawienia, które najlepiej oddał jeden ze Scrum Masterów mówiąc do zespołu “wydajmy to na produkcję  – juzerzy nam to przetestują”. Najbardziej niebywałe jest tu to, że nikt nie zaprostestował.

Przy takim podejściu katastrofa (w postaci spektakularnego padu krytycznego dla firmy systemu) tylko czeka aby się wydarzyć, a praca obu zespołów jest pasmem “marszów śmierci”, następujących po nich okresów letargu i stałego gaszenia pożarów.

Nie wchodząc zbytnio w szczegóły warto pochylić się nad tymi przypadkami, bo mają one – niestety – nie tylko szanse stać się przykładem, że Agile ogólnie a Scrum szczególnie “nie działa”, ale wydają się być dość typowe.

Jak mi się wydaje najistotniejszym wnioskiem jaki z nich wypływa jest taki, abyśmy zawsze pamiętali to, co wbijane jest do głów na każdym (porządnym) szkoleniu scrumowym – Scrum nie rozwiązuje sam ze siebie żadnych problemów, Scrum jedynie czyni je widocznymi. Scrum to nie panaceum, nie uczyni cudów.

Nie da się zatem przy pomocy Scruma i Agile przerobić grupy studentów bez solidnych podstaw informatycznych na sprawny zespół programistów. Zanim zacznie się stosować praktyki XP i pracować w krótkich sprintach w Scrumie trzeba na początek umieć dobrze obiektowo modelować i programować, trzeba umieć pisać czytelny kod (np. mieć nawyk stosowania sensownych nazw obiektów, metod i zmiennych czy pisania sensownych komentarzy), mieć pojęcie o wzorcach projektowych, umieć je stosować i tak dalej. Trzeba wreszcie posiadać wiedzę o stosowanej technologii, a więc o języku w którym się pisze i jego właściwościach, właściwościach stosowanych kompilatorów czy interpreterów i innych związanych z danym językiem narzędzi.

Trzeba też umieć korzystać z frameworków i bibliotek – a więc przede wszystkim mieć świadomość ich istnienia, a także wad i zalet by móc odpowiednio dobrać je do swojego projektu. Trzeba wreszcie umieć właściwie wykorzystać środowisko pracy, takie jak systemy kontroli wersji, błędów, automatycznych buildów itp. No i oczywiście cały szeroki świat testów – nie dość, że trzeba mieć nawyk ich pisania oraz wykonywania – trzeba także mieć umiejętności i narzędzia. To właśnie braki tej podstawowej wiedzy i związanych z nią praktyk decydują o wspomnianej wyżej niemożności jaka trapi oba zespoły.

Oczywiście, wszystkiego można się nauczyć – ale trzeba mieć od kogo. Jeśli w zespole wszyscy są mniej-więcej równie początkujący jego rozwój jest znacznie utrudniony jeśli nie niemożliwy. Zdecydowanie lepiej jest, jeśli w zespole przynajmniej część stanowią doświadczeni programiści i testerzy, którzy mogą pomóc “świeżym” kolegom w rozwoju. W przeciwnym razie praktyki takie jak przeglądy kodu czy programowanie w parach niewiele dają – przeciwnie, petryfikują wręcz niski poziom i jako “bezsensowne” są szybko zarzucane.

Równie toksyczna i prowadząca do utrwalania się dysfunkcji zespołu – który miast miejscem rozwoju staje się miejscem walki z problemami dawno już rozwiązanymi gdzie indziej – jest akceptacja marnych wyników przez odbiorców i kierownictwo.

I tu dotykamy innego problemu – otóż niezwykle często myli się u nas samoorganizację i inne cechy Scruma z brakiem zarządzania. Tymczasem samoorganizacja dokonuje się wokół celów, które to cele ktoś z zewnątrz musi postawić i wymagać ich osiągania. Jakość jest jednym z takich celów – jakość nie jest jakimś regulowalnym parametrem (niczym na linii produkcyjnej), przeciwnie – pewien ustalony poziom jakości tego co jest budowane (będący potem podstawą kryterium ukończenia) jest jednym z celów służących samoorganizacji zespołu.

Ale samoorganizacja wymaga nie tylko celów – wymaga również presji. Samoorganizacja nie nastąpi jeśli zobowiązanie zespołu do wykonania tego co wziął “do sprintu” nie jest traktowane poważnie. A poważne traktowanie oznacza nie tylko świętowanie osiągnięcia celu sprintu podczas przeglądu (sprint review) – oznacza także poważne traktowanie porażek. Wymaga to od zarządzających takimi zespołami subtelności, stanowczości  ale przede wszystkim konsekwencji – zespół musi dobrze rozumieć, że zawiódł; musi zdawać sobie sprawę z tego, że nie jest dobrze (no bo jeśli jest dobrze – to po co coś poprawiać?).

I tu dochodzimy do najistotniejszego – dobra firma czy dział tworzący oprogramowanie to taki, gdzie sprawy takie są dla wszystkich oczywiste. A więc jest dla każdego jasne, że fuszerka to fuszerka i trzeba się jej wstydzić (niezależnie od tego czy na wierzchu działa czy nie), że system krytyczny dla firmy ma działać zawsze a wszelkie zaburzenia tego stanu rzeczy są porażką dla zespołów i plamą na ich profesjonaliźmie. To jest właśnie kultura jakości, w której metody agile kwitną i pomagają. Bez niej – w kulturze bylejakości, a więc akceptacji marności rezultatów i mierności wysiłków – Scrum, Agile – czy w ogóle inne metodyki działające na innym poziomie abstrakcji nie przyniosą oczekiwanych efektów.

Dlatego zanim będziemy próbować wdrażać gdzieś Scruma upewnijmy się, że środowisko w ogóle się do tego nadaje – że sypiemy ziarno na żyzną glebę kultury jakości, a nie na uklepany nawykiem ugór bylejakości. I jeśli to konieczne lepiej zacząć pracę od postaw, od budowania kultury jakości, nawet jeśliby to była przysłowiowa “orka na ugorze”.

Andrzej K. Brandt
Code Sprinters

Tagi: , , ,

Komentarze

Dwa komentarze dla postu Scrum a kultura bylejakości

  1. Przemek ( N, 31 stycznia 2010 23:46 )

    2. Trafiłeś w sedno. Przynajmniej dwa razy miałem do czynienia z ludźmi, którzy byli bardzo krytycznie nastawieni wobec Agile, ponieważ ich doświadczenia dowodziły, że oznacza to po prostu brak zarządzania w ogóle…

  2. bartek ( So, 6 lutego 2010 11:55 )

    3. Ciekawy artykuł. Zgadzam się z tym, że tak jak w przypadku informatyzacji chaosu masz zinformatyzowany chaos, tak i przy wprowadzeniu zwinnych zasad SCRUMa w kulturze bylejakości efektem będzie jeszcze większa bylejakość. Ken Schwaber w googlu mówił że SCRUM działa ze wszystkimi (użył słowa idioci), tyle że za każdym razem na koniec sprintu masz bubel.

    Widziałem taki zespół. Ruszenie go z posad status quo było trudne i nie do końca się to udało. Zdecydowanie ziarno Scruma zaowocuje najlepiej tam, gdzie ludzie są otwarci na zmianę, chcą się uczyć i lubią to co robią.

    Wspomniałeś w artykule o czymś co mnie zainteresowało.Ostatnio byłem na wrocławskim spotkaniu Agilopolis gdzie dyskutowano o tym w jakich kategoriach nalezy traktować sprint, w którym zespołowi nie udało się wszystkiego zrobić. Było kilka zdecydowanych głosów, że nie można mówić o porażce zespołu czy rozpatrywać wynik w kategoriach winy. Mówiono raczej o sprincie w którym nie wykonano wszystkich zadań. Ja osobiście się z tym zgadzam – faktycznie może to działać demotywująco na zespół. Niemniej jednak granica między mówieniem o sprincie że się nie udał i był porażką a tym że zespół nie zrobił wszystkiego co zaplanował jest cienka i łatwo ją przekroczyć.
    Jak według Was powinno mówić się o sprincie który się nie udał? Ciekawy jestem jakie macie zdanie na ten temat.

  3. Andy Brandt ( Śr, 10 lutego 2010 18:17 )

    4. W/g mnie niedokończony sprint jest zawsze porażką. Należy oczywiście zastanowić się wspólnie czy jest to porażka planowania, wykonania czy wynik nieprzewidywalnych zdarzeń lub okoliczności (choćby większego skomplikowania zadania niż się wydawało). W każdym przypadku nie można przejść nad tym gładko do porządku jak gdyby nic się nie stało, a już napewno nie można robić tego konsekwentnie.

    Oczywiście, sprawa jest delikatna bo to zespół powinien sam jakby dojść do tego, sam czuć się źle z tym, że nie dotrzymał swoich zobowiązań w jakiś sposób. Dlatego najlepszym rozwiązaniem jest dobra retrospekcja – i dlatego jest taka ważna. Retrospekcje to jest w ogóle rzecz, której robii się zdecydowanie za mało – my sami robimy je zdecydowanie za rzadko.

Napisz co myślisz...
jeśli chcesz dodać Twoje zdjęcie do komentarza zdobądź gravatar!