Dlaczego trudno być dużym i zwinnym

W 2012 roku Henrik Kniberg opublikował krótki film, w którym wyjaśnia ideę „Agile Product Ownership in a Nutshell”. Filmik zdecydowanie warto obejrzeć – a ja dzisiaj chciałbym wykorzystać obrazek z tego filmu do zastanawienia się, dlaczego dużym organizacjom IT trudno jest zwinnie rozwijać produkty.

Naszkicowany przez Kniberga obraz zwinnego wytwarzania produktu wygląda tak:

Mamy tutaj trzy kluczowe przepływy:

  • Przepływ pomysłów na zmiany (lewa niebieska strzałka) – interesariusze (Stakeholders) definiują funkcjonalności, Właściciel Produktu priorytetyzuje je i umieszcza w kolejce do wykonania,
  • Przepływ zmian w aplikacji (prawa niebieska strzałka) – zespół deweloperski często dostarcza system z nowymi funkcjonalnościami do interesariuszy,
  • Przepływ informacji (zielone strzałki pośrodku) – interesariusze, zespół deweloperski oraz Właściciel Produktu komunikują się ze sobą.

Sensem zwinności nie są sprinty, planowania i backlog-i. Chodzi o to, żeby zapewnić te powyższe przepływy: szybki przepływ idei, szybką priorytetyzację tych idei, częste dostarczanie systemu oraz sprawną komunikację. Chodzi o to, że w przypadku pojawienia się pomysłu na funkcjonalność aplikacji, która przyniesie nam milion mieszków złota – możemy bardzo szybko ten pomysł omówić, wycenić, spiorytetyzować, zaimplementować i wdrożyć na środowisko produkcyjne. Ta-dam!

Kiedy małe firmy zaczęły stosować ten sposób działania, okazało się, że przynosi on znacznie lepsze rezultaty niż praca w trybie realizacji długoterminowych projektów. Stąd wzięła się „moda na agile”, która dotarła również do dużych organizacji. Ale próbując zastosować ten sposób działania w dużej organizacji IT, która pracuje nad rozwojem dużego systemu, natychmiast napotykamy na…

Ogromne problemy przy skalowaniu

Przedstawiając ideę zwinnego wytwarzania produktu ludziom pracującym w dużych firmach możemy usłyszeć: „ale to nie zadziała u nas”, „my jesteśmy inni”, „to działa tylko w małej skali”.

Spróbujmy więc zaznaczyć na rysunku te elementy zwinnego świata, które są trudne dla rozwoju dużych systemów oraz dużych dla organiacji:

Rozpoczynając od samej góry. Zwykle w takim projekcie interesariusze lub użytkownicy systemu są bardzo oddaleni od zespołów deweloperskich. Nie możemy wprowadzić żadnej zmiany w systemie bez zleceń „podpisanych w trzech egzemplarzach, wysłanych, odesłanych, zakwestionowanych, zgubionych, odnalezionych, przedstawionych opinii publicznej, znów zgubionych, porzuconych ostatecznie na trzy miesiące na kupie kompostu i zużytych jako surowiec wtórny do rozpalania ognia”.

Wymagania. Jeżeli projektujemy internetowy system wymiany książek, łatwo jest zapisać wymagania jako historyjki użytkownika. Ale w dużym systemie wymagania mogą być bardzo złożone. Może być tak, że jakiś zespół deweloperski przez rok pracuje nad interfejsem do eksportu danych – mamy jedną historię („jako użytkownik systemu chciałbym wyeksportować dane ubezpieczeń klientów”) i przez długi, długi czas rozgryzamy, skąd wziąć te dane, w jaki sposób je przetworzyć i w jaki sposób je wyeksportować.

Często jest tak, że nie mamy w organizacji jednej osoby, która może pełnić rolę Właściciela Produktu – obszar do priorytetyzacji jest po prostu za duży. Musimy więc podzielić Backlog Produktu na obszary i w jakiś sposób określić zależności między tymi obszarami oraz ich właścicielami. Często również Backlog przestaje być listą i wprowadzamy w nim jakąś hierarchię w stylu: Theme / Epic / Story / Task. Utrzymanie tego Backlogu zaczyna być pracochłonne.

Wiele zespołów deweloperskich oznacza wiele problemów. Przede wszystkim pojawia się problem z tym, co opisuje Scrum Guide w zdaniu „Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment”. W dużych organizacjach często pojawia się specjalizacja, silosy kompetencyjne oraz masa zależności. Żeby wprowadzić zmianę w systemie potrzeba jest kooperacja wielu zespołów. A dodatkowo często zespoły te są rozproszone.

Wiele zespołów to również konieczność integracji ich pracy. Problemy przy integracji systemów są normą – zawsze trafia się coś, czego nie przewidzieliśmy. Nie znam programisty, który by nie doświadczył historii „działa, działa, działa, integrujemy, OMG!”.

Żeby zachować stabilne tempo rozwoju systemu, musimy tworzyć testy regresji. Dodając do systemu nowe funkcjonalności nie chcemy za każdym razem pracochłonnie sprawdzać, czy wszystkie poprzednie funkcje działają poprawnie. Tymczasem w dużych systemach IT najczęściej albo nie mamy testów regresji, albo wykorzystujemy plaftormę technologiczną na której pisanie testów regresji jest trudne, albo mamy coś, co tylko udaje testy regresji (gorąco polecam artykuł opisujący „teatrzyk CI”).

I na koniec mamy wydanie systemu. Duże organizacje mają wiele ważnych powodów, którymi tłumaczą wydawanie systemów w dużych odstępach czasowych: nasz system musi przejść kosztowne testy end-to-end; nasz system musi być certyfikowany przed wydaniem; nasz system jest zintegrowany i klienci muszą dopasować się do naszych zmian; nasz system jest instalowany lokalnie u klientów i nowe wydanie oznacza duży koszt. W rezultacie wdrożenie nowej wersji systemu jest wykonywane raz na rok albo raz na kwartał – nie jesteśmy z tego powodu szczęśliwi, ale już się do tego przyzwyczailiśmy i jakoś z tym żyjemy.

Ale to jeszcze nie wszystko…

Mamy jeszcze kilka dodatkowych problemów, które często pojawiają się w dużych organizacjach – nie są one bezpośrednio związane z naszym rysunkiem, ale mają na niego duży wpływ.

Pierwszym czynnikiem może być nastawienie członków zespołów. Tworzenie obszarów funkcjonalnych i silosów kompetencyjnych bardzo często skutkuje nastawieniem na realizację celów właśnego zespołu. Żeby osiągnąć sukces w zespole Scrum trzeba zmienić swoje podejście z „czekam na przydzielenie mi zadania do realizacji” na „aktywnie szukam sposobu żeby wspólnie ze zespołem zrealizować cel sprintu”. Trzeba zmienić nastawienie „w analizie, którą dostałem, znowu jest pełno dziur” na „usiądźmy z analitykiem i spróbujmy zrobić razem lepszą analizę”. Trzeba zmienić „napisałem swoją część i ona działa – a jak całość nie działa, to problem jest po drugiej stronie”.

Nasza organizacja może być przyzwyczajona do pracy w trybie projektowym – tj. przyzwyczajona do rozbijania pracy na projekty z jasno określonym celem, zakresem oraz budżetem. Trudno jest wtedy mówić o rozwoju produktu. Trudno wtedy również przekazać władzę nad rozwojem produktu z rąk menedżerów projektów w ręce właścicieli.

Nasza organizacja może być przyzwyczajona do pracy, w której wie (lub wydaje jej się, że wie!), co trzeba dostarczyć – więc nie widzimy sensu w reprioretyzacji wymagań. Skoro dobrze wiemy, co trzeba zrobić – dlaczego mamy tworzyć mechanizmy ułatwiające zmiany w tych wymaganiach?

Może występować również brak zaufania między dostawcą oprogramowania a klientem – zwłaszcza w przypadku, kiedy pracujemy w oparciu o kontrakt, który z góry określa zakres i koszt prac. Trudno mówić o zaangażowaniu i dobrej współpracy w przypadku, w którym klient traktuje dostawcę IT jak dostawcę pizzy – dostawca ma zrobić co trzeba, bo za to mu płacimy.

I ostatnim elementem, na którym chciałbym zwrócić uwagę, są menedżerzy w organizacji. Po pierwsze mogą oni być skupieni na realizacji celów własnego zespołu, departamentu czy sekcji. Dyrektor do spraw finansowych będzie skupiony na tym, żeby nie przekroczyć planu finansowego. Kierownik działu testów będzie miał do spełniania SLA dotyczące czasu rozwiązywania błędów. Bardzo łatwo jest zgubić sens pracy organizacji w gąszczu lokalnych optymalizacji.

Menedżerzy mogą również czuć się zagrożeni wprowadzaniem metod zwinnych utożsamiając je z zagrożeniem swojego miejsca pracy lub z zagrożeniem funkcji, które są realizowane przez ich zespół.

Water-Scrum-fall nie jest rozwiązaniem!

Często efekt próby wprowadzania zwinności przy wszystkich opisanych ograniczeniach kończy się takim efektem (tym razem autorem obrazka jest Jez Humble):

Zespoły pracują w sprintach – ale zanim zabiorą się do pracy przechodzimy przez długi i kosztowny proces planowania inicjatyw. A po zakończeniu pracy zespołu deweloperskiego czeka nas bolesny proces integracji i wdrożenia zmian. Małe kółko sprintowe, które obraca się raz na dwa tygodnie, wpisane jest w wielke koło projektowo-wdrożeniowe obracające się raz na pół roku. Nawet jeżeli zespół jest w stanie szybko zaimplementować jakąś zmianę – to i tak od momentu wymyślenia zmiany do momentu jej wdrożenia na środowisko produkcyjne mijają długie, długie miesiące…

Szukamy rozwiązania we framework’ach

Jeżeli mamy jakiś problem, to często szukamy podpowiedzi w jakiś framework’ach. Mamy ich trochę do wyboru – jest Scaled Agile Framework, LeSS, Nexus… I faktycznie, znajdziemy tam pewne podpowiedzi.

Zarówno SAFe, jak i LeSS podpowiedzą nam, jak można skalować backlog. Wszystkie frameworki mówią o konieczności redukcji zależności pomiędzy zespołami. Wszystkie mówią o budowaniu „feature teams”. Nexus podkreśla ważność ciągłej integracji.

Ale w żadnym framework’u nie znajdziemy gotowego przepisu, które powie nam jak zbliżyć zespoły deweloperskie do klienta. Nie znajdziemy gotowej metody tworzenia testy regresji w dużych systemach. Nie znajdziemy porad, jak radzić sobie z różnymi wyzwaniami dotyczącymi release’ów. Nie znajdziemy ich z bardzo prostego powodu – problemy dużych organizacji są tak różne, że nie ma jednej, wspólnej recepty na sukces…

Dlatego we framework’ach nie znajdziemy zbyt wielu gotowych rozwiązań. Ken Schwaber, współtwórca Nexusa, mówi tak: „Scaled Professional Scrum is not a solution. It is a framework, within which you can think and apply principles to scale Scrum and to be as productive as possible”.

Rozpędzamy koło zamachowe…

Wróćmy jeszcze raz do naszego pierwszego obrazka:

Idea zwinnego wytwarzania oprogramowania jest prosta: pomysł na zmianę, który wychodzi od interesariuszy, może bardzo szybko wrócić do nich w formie gotowej zmiany w aplikacji. Przypomina to koło zamachowe, która obraca się raz na kilka-kilkanaście dni i za każdym obrotem przynosi coraz to nowe zmiany w działającej aplikacji.

Wszystkie opisane wyżej problemy powodują, że w dużych organizacjach to koło obraca się niezmiernie powoli.

W bólach i trudach osiągamy jeden obrót na kwartał, pół roku, rok… W konsekwencji trudno jest docenić zalety zwinnego podejścia. Jeżeli rezultaty priorytetyzacji backlogu widzimy dopiero po kilku miesiącach – to trudno jest zobaczyć powody, dla których warto ten backlog pielęgnować.

Wdrażanie zwinności w dużych organizacjach przypomina żmudne oliwienie tego koła, aby mogło obracać się coraz szybciej. Jest to trudne, ponieważ każda z wymienionych wyżej trudności jest potencjalnym hamulcem. Jest to trudne również dlatego, że dopóki nasze koło nie nabierze prędkości, nie widać korzyści z naszych wysiłków.

Dopiero kiedy nasze koło zaczyna się obracać coraz szybciej i szybciej, dopiero kiedy zaczynamy widzieć, że dostarczamy zmiany w coraz krótszych interwałach czasowych – zaczynamy dostrzegać prawdziwe korzyści wynikające ze zwinnego tworzenia oprogramowania.

A co w Twojej organizacji najbardziej spowalnia koło dostarczania zmian?

One thought on “Dlaczego trudno być dużym i zwinnym

  • 14 lipca 2017 at 00:40
    Permalink

    Życie tak wygląda.

    Detale są pomijane na początku.

    Na końcu są najważniejsze detale.

    Brawo.

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *