Jaki jest cel tego całego „agile’a”? Po co firmy stają się zwinne i zawracają głowę tymi wszystkimi spotkaniami i zmianami? Co chcemy przez to osiągnąć?
Po co nam agile?
Braliśmy udział w wielu transformacjach agile, a widzieliśmy jeszcze więcej. Niektóre firmy sugerują się pozytywnymi doświadczeniami współpracowników i konkurencji. Inne chcą po prostu wprowadzić Scrum, uznając go za rynkowy standard. Powodów jest wiele i trudno wytykać złą motywację, jeżeli kończy się to pozytywnym rezultatem.
Na pewno jednak warto zidentyfikować i jasno przekazać wszystkim oczekiwania płynące ze zmian. W większości przypadków, niestety, będą to aspekty finansowe. „Chcemy pracować wydajniej”, „chcemy zaoszczędzić pieniądze”, „chcemy szybciej zarabiać na naszych produktach” albo nawet „chcemy zwolnić część ludzi”.
Z jednej strony jest to zrozumiałe, ale z drugiej kłóci się z nadrzędną ideą agile’a. Nie taki jest przecież cel zwinności!
Cel zwinności
Nadrzędnym celem „bycia agile” jest zadowolenie klienta osiągane przez zwinne techniki, w szczególności iteracyjną pracę i wczesne oddawanie wartościowego produktu do użycia. Warto zajrzeć tutaj do 12 zasad zwinnego tworzenia oprogramowania. Na pierwszym miejscu zostało postawione poniższe zdanie, mówiące o tym samym, ale innymi słowami.
„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Zawsze ostrzegamy przed tym wszystkich, którzy decydują się na wdrożenie jakiejś metodyki agile ze złych powodów. Nie jest przecież napisane, że „Our highest priority is to cut costs and work faster with less people on board”. Jeżeli zabieramy się do agile’a z takim nastawieniem, to już na wstępie popełniamy błąd.
Bardziej wydajna praca często jest skutkiem ubocznym tego, że zamiast zajmować się setką nieistotnych wymagań, skupiamy się na dwudziestu najważniejszych dla odbiorcy. Szybszy zysk wiąże się z częstszym oddawaniem gotowych fragmentów produktu do klienta. Natomiast oszczędności pojawiają się z powodu lepszego dostosowywania się do pojawiających się wymagań, zamiast ślepego podążania za planem. I tak dalej, i tak dalej…
Celem samym w sobie nigdy nie powinny być oszczędności czy przyspieszenie pracy. Dążymy do satysfakcji klienta, czyli „poprawienia relacji biznesowych z naszymi odbiorcami”. Wiadomo, że bardziej zadowolony klient, to taki, który nie tylko sam wróci po więcej, ale i poleci nas innym. Jest to coś zupełnie odwrotnego niż typowa „polska szkoła managerska„.
Najważniejsza jest satysfakcja klienta
12 zasad zwinnego tworzenia oprogramowania podpowiada trzy sposoby na osiągnięcie celu zwinności, czyli satysfakcji naszego klienta. Dwa z nich są proste, bo wymagają tylko zmiany procesu wytwórczego (w czym jako #białko zawsze możemy pomóc w ramach wsparcia agile). Mowa oczywiście o „wczesnym i ciągłym dostarczaniu produktu”.
„Wczesnym”, czyli oddawajmy do użytkowania małe, gotowe fragmenty funkcjonalności. „Ciągłym”, czyli róbmy to w regularnych odstępach czasu. Im częściej, tym lepiej. Pamiętajmy też, że nie chodzi tu o żadne oddawanie do testów, ale o przekazanie gotowego produktu do użytkowania. A to zupełnie zmienia jakość wracających do nas informacji zwrotnych.
Trzeci czynnik mający wpływ na satysfakcję klienta to „wartościowy produkt” (w oryginale: oprogramowanie). Tu już pojawiają się schody, bo nie ma prostego przepisu na zapewnienie wysokiej wartości. Trudno nawet zdefiniować samą „wartość”.
Czym jest wartościowy produkt?
Łatwo jest powiedzieć, że „wartościowy produkt to taki, z którego nasz klient jest zadowolony”. Definicja ta chociaż słuszna, w praktyce jest bezużyteczna.
Według niej, o wartości dowiadujemy się dopiero po fakcie. Zanim klient nie zacznie używać naszego produktu, nie wiemy czy będzie zadowolony. A przecież wartość jest jedną z cech elementów Backlogu Produktu, która powinna być zdefiniowana dla wszystkich wymagań.
Trochę pomaga nam w tym wspomniana już wielokrotnie iteracyjność. Na nic się jednak ona nie przyda w kontekście planowania przyszłych wymagań i wydań. I tu wracamy do tego, jak krytyczna jest rola Product Ownera (bądź jego odpowiednika w metodykach innych niż Scrum).
Cel zwinności na głowie Product Ownera
To Product Owner powinien lepiej od klienta znać jego potrzeby i być w stanie ocenić wartość poszczególnych wymagań. Zamawiający bardzo często nie wie czego chce, zanim tego nie zobaczy. A jak już zobaczy, to często potrafi zmienić zdanie. Nic w tym dziwnego, sami przecież po wypożyczeniu naszego wymarzonego samochodu na tydzień zapewne wrócimy z listą nowych wymagań. W tym rola Product Ownera, żeby te zmiany przewidzieć.
Dlatego też nie możemy pozwolić sobie na „zostawienie programistów w spokoju„. Nie chodzi bowiem o to, żeby stworzyć cokolwiek, ale aby faktycznie spełnić potrzeby klienta. Nawet te, o których on sam jeszcze nie wie. Zupełnie inaczej pracujemy wiedząc, kto będzie używał naszego dzieła i do czego.
W oparciu o nasze doświadczenie i informacje zwrotne od odbiorcy, przy zapewnieniu odpowiednio krótkich iteracji, jesteśmy w stanie osiągnąć cel zwinności – zadowolenie klienta. Warunkiem koniecznym jest pełna świadomość tego, po co działamy w zwinny sposób. I dotyczy to każdego szczebla naszej organizacji.
Jeżeli zaś naszym celem jest zupełnie coś innego, zastanówmy się czy na pewno podążamy dobrą drogą. Nie jest przecież powiedziane, że każdy musi „być agile”.
