W 2015 roku Dział Oprogramowania i Informatyki Agilent miał kłopoty. Podczas prac nad dużym wydaniem nowego produktu wyglądało na to, że zespół nie dotrzyma terminu. Nie byłby to pierwszy raz: dział realizował terminowo tylko około 20 procent swoich wydań.
Nieterminowe wydania spowodowały, że zespoły programistyczne znalazły się pod ogromną presją. „Pracując pod presją, zespoły podejmują złe decyzje”, powiedział John Sadler, wiceprezes i kierownik generalny Wydziału Oprogramowania i Informatyki Agilent. „Poświęcają jakość produktu końcowego. Ogólnie rzecz biorąc, zespół był dość zdemoralizowany i miał trudności z wykonaniem jakichkolwiek zadań na czas”.
Problemem było także to, że Dział Oprogramowania i Informatyki Agilent zatrudniał 150 pracowników na dwóch kontynentach, którzy współpracowali z podwykonawcami w jeszcze innej lokalizacji geograficznej. Rozległy dział obejmował inżynierię, marketing, zapewnianie jakości, wsparcie techniczne i sprzedawców. Firma musiała ustanowić nowe praktyki dla zespołu, aby pomóc mu szybciej dostarczać wartość, z wyższą jakością i przewidywalnością, oraz lepiej reagować na zmiany. Krótko mówiąc, potrzebowała transformacji Agile.
Rozpoczynanie transformacji Agile
W 2015 roku Agilent nakreśliła kierunki transformacji Agile obejmujące następujące cele:
- Koncentracja na przewidywalności
- Stworzenie realistycznych terminów wydawania
- Stworzenie powtarzalnego cyklu dostarczania
- Wspieranie ciągłego doskonalenia
Podejście Agile stawia na pierwszym miejscu jakość, potem plasują się powtarzalne terminy, a następnie zakres prac. „Kiedy zespoły nie działają według tych priorytetów, często stawiają zakres na pierwszym miejscu, harmonogram zostaje narzucony w formie terminu, a jakość w ogóle przestaje być priorytetem”, powiedział Sadler.
Firma Agilent chciała ustanowić procesy Agile wspierające priorytety tworzenia oprogramowania. Ustanowienie ciągłego doskonalenia jako jednej z głównych wartości pociągało za sobą zmianę kulturową, która stworzyła kontekst transformacji. Postawienie jakości na pierwszym miejscu oznaczało poprawę satysfakcji zarówno klientów zewnętrznych, jak i wewnętrznych. Agilent postanowiło poświęcić zakres, aby sprostać oczekiwaniom klientów w tym obszarze.
Drugim priorytetem było stworzenie przez dział przewidywalnego cyklu wydawania, który z czasem można było dopracować. Dzięki krótszemu i bardziej niezawodnemu cyklowi programowania zespół mógł uniknąć problemów i wcześnie ograniczyć ryzyko, aby zapewnić odpowiedni czas reakcji.
Transformacja Agile: krok po kroku
W sierpniu 2015 roku Agilent nawiązało współpracę z CPrime, firmą konsultingową z doświadczeniem w pomaganiu organizacjom w transformacji Agile, a później z TCGen, wiodącą firmą zajmującą się doradztwem w zakresie rozwoju produktów.
Pierwszym krokiem było wdrożenie narzędzia Agile do zarządzania produktem — Jira. Jira zapewnia teraz jeden system rejestracji wszystkich prac programistycznych Agilent w rozproszonych zespołach globalnych. Zapewnia przejrzystość dzięki jednej wersji prawdziwej informacji, która ujawnia funkcje programu, kiedy są oczekiwane, i co zostało osiągnięte przez zespoły.
Dostosowane za zgodą CPrime, Inc.
Kolejnym priorytetem było szkolenie w zakresie metodyki Agile, którego celem było zaznajomienie pracowników z zasadami i koncepcjami Agile oraz ustalenie wspólnej terminologii. Firma cPrime przedstawiła swój model RAGE (recipes for Agile Governance in the Enterprise), który określa kluczowe procedury, w tym spotkania dotyczące planowania wydania, spotkania zespołu Scrum of Scrums, spotkania Scrum of Scrums właścicieli produktów, spotkania dotyczące przygotowania dziennika wydania, spotkania dotyczące przeglądu wydania oraz spotkania retrospektywne dotyczące wydania.
Agilent określiło także role właściciela produktu obszarowego i role menedżera programu oraz wykorzystało do mierzenia postępów wykresy wypalania. W Agilent wdrożono lekkie techniki podejmowania decyzji, wykonywane procedury, artefakty Scrum Agile i inne praktyki Agile.
Agile w praktyce
W listopadzie 2015 roku Dział Oprogramowania i Informatyki Agilent zorganizował Sprint Zero, dwutygodniową sesję planowania Agile z czternastoma szkolonymi zespołami. Opracowano plan wydania produktu obejmujący osiem miesięcy dla systemu danych chromatografii OpenLab.
Sprint Zero obejmowało trzy kategorie działań:
- Szkolenie zespołów w zakresie celów biznesowych i technicznych, czynników stymulujących oraz ogólnych wymagań dla OpenLAB poprzez prezentacje i plakaty.
- Wykorzystanie nowo poznanych technik do opracowywania wymagań i szacowania historyjek, epików i defektów.
- Rozmieszczenie historyjek, epików i defektów na tablicy planowania wydania oraz zaznaczenie wszystkich zależności między zespołami.
Agilent wkrótce odkryło, że wprowadzone ulepszenia Agile wykraczają poza pilotażowy projekt. Jeden z pierwszych sygnałów wskazujących na sukces miał wymiar wewnętrzny. „Ponieważ musieliśmy współpracować z innymi oddziałami Agilent, niezwykle ważne było wywiązywanie się ze zobowiązań”, powiedział Sadler.
W Agilent zaobserwowano także ulepszenia w współpracy zewnętrznej. Informacje zwrotne od klientów odegrały kluczową rolę w usprawnieniu reakcji zespołów Agilent na zmiany zachodzące na rynku. Włączając klientów na wczesnym etapie procesu programistycznego, Agilent podniosło jakość oprogramowania, jednocześnie zmniejszając ryzyko rynkowe i integracyjne.
Jednym ze wniosków Agilent było wpisanie do definicji ukończenia zasady, że historyjki uaktualnienia powinny być uwzględnione w każdym epiku Agile. Babita Jain, dyrektor ds. jakości oprogramowania, i Stefan Weiss, kierownik ds. integracji oprogramowania w Agilent, kierował wdrożeniem transformacji i pomógł zespołom zrozumieć ogólny zakres projektu. „Epik nie powinien zostać uznany za ukończony, jeśli nie zawiera uaktualnienia”, powiedział Jain.
Transformacja Agile poprawiła nie tylko jakość, ale także niezawodność. W 2016 roku system danych chromatografii OpenLab został ukończony terminowo. Od czasu transformacji Agile Agilent dostarcza oprogramowanie w regularnych okresach, a liczba zgłoszonych defektów spadła.
Mierzenie skali sukcesu
Agilent definiuje i mierzy sukces swojej inicjatywy Agile za pomocą „niskich wskaźników awaryjności w terenie i wysokiej lojalności klientów”, jak powiedział Sadler. Kluczowe znaczenie ma również utrzymanie klientów. Na dojrzałym, wysoce konkurencyjnym rynku w branży nauk przyrodniczych, ryzykiem jest utrata klientów. Niezbędna jest zdolność do sprzedawania nowych systemów dotychczasowym klientom.
Poniżej przedstawiono cztery krytyczne wskaźniki mierzone przy pomocy modelu wydajności Agilent opartego na Jira:
Wykresy Burndown/Burnup
W Agilent mierzono wcześniej skuteczność prac w godzinach pracy inżynierskiej, osobodniach lub punktach historyjki. Teraz wszyscy pracownicy używają wykresów Burnup do śledzenia ukończonych zadań i całkowitej ilości pracy. Wykresy Burnup pokazują ilość pozostałej pracy.
Procent mocy produkcyjnej dostarczonej na rynek (ładunek)
Umiejętność modelowania i śledzenia wydajności odgrywa istotną rolę w sposobie pomiaru sukcesu przez Agilent. System Jira umożliwił Agilent zbudowanie szczegółowego modelu wydajności. „Model ten pozwolił nam w fazie planowania poinformować dział marketingu, z iloma punktami historyjki muszą pracować w ramach danego wydania. Dział marketingu może uszeregować backlog, aby dopasować go do tej wydajności” — powiedział Sadler.
Liczba i mediana czasu wprowadzania poprawek
Model wydajności zapewniał bardziej szczegółowy widok, dzięki któremu firma Agilent mogła zobaczyć, jaka część wydajności była przeznaczona na usuwanie krytycznych lub poważnych defektów zgłaszanych przez pracowników, a jaka na usuwanie defektów wykrytych i zgłoszonych przez zespół ds. jakości.
Procent czasu poświęcanego na naprawianie defektów odkrytych podczas ręcznego testowania
Model wydajności pomaga firmie Agilent mierzyć czas poświęcony na tworzenie funkcji cenionych przez klientów w porównaniu z czasem poświęconym na utrzymanie lub konserwację istniejących produktów.
W ciągu nieco ponad trzech lat oddział ponad dwukrotnie zwiększył udział mocy produkcyjnych skoncentrowanych na pracach o wartości dodanej, zwiększając je z 30% do 65%. Wraz z poprawą jakości oprogramowania, wynikającą z nowego podejścia Agile, zmniejszyła się także liczba defektów, które trzeba było później usuwać.
Rok po rozpoczęciu procesu transformacji Agile członkowie zespołu Agilent opisują różne scenariusze „przed” i „po”:
 | Przed: wydajność mierzono w godzinach inżynierskich, osobodniach lub punktach historyjki. |
|---|---|
 | Przed: zespoły o różnych poziomach przeszkolenia Agile stosowały różne definicje epików, historyjek i zadań podrzędnych. |
 | Przed: mistrzowie Scrum pisali kod, prowadził spotkania zespołu i analizowali priorytety funkcji. |
 | Przed: funkcje zawierające błędy mogły zostać zatwierdzone, przenosząc wady w kolejnych fazach prac. |
 | Przed: często znajdowano problemy w ostatniej chwili, co powodowało panikę i znaczne opóźnienia. |
 | Przed: brakowało instrumentu do pomiaru zdolności zespołu do wykonywania pracy. |
Przyszłość Agilent oparta na Agile
Jak w przypadku każdej kultury, która ceni sobie ciągłe doskonalenie, transformacja Agilent w kierunku Agile nie jest bynajmniej ukończona. Kolejne kroki obejmują dalsze skracanie czas cyklu i doskonalenie możliwości wczesnego wglądu w informacje zwrotne z rynku, będące kluczowymi elementami wskaźników DevOps.
Agilent udało się już radykalnie skrócić czas cyklu, dzieląc roczne wydania na dwa półroczne cykle — mimo że firma komercjalizuje wydania corocznie. Firma planuje dodatkowo skrócić czas cyklu o połowę, wprowadzając kwartalny okres wydawania.
Przedmiotem ciągłego doskonalenia jest także wczesne i częste angażowanie klientów w proces tworzenia produktu. Jak twierdzi Sadler, jego grupa odnotowuje mniejszą rozbieżność interesów w dyskusjach na temat zakresu produktów, jeśli istnieją wyraźne dowody w postaci informacji zwrotnych z rynku. Utrzymanie jakości i użyteczności dla klientów w terenie jest stałym priorytetem, a ciągła współpraca z użytkownikami pomaga w utrzymaniu priorytetów firmy: najpierw jakość, potem terminy i zakres wydań.
Wyciągnięte wnioski
Sadler przypisuje sukces swojemu zespołowi, w tym liderom Jainowi i Weissowi, którzy przyjęli tworzenie oprogramowania zgodne z Agile jako sposób na szybkie i ciągłe doskonalenie. Odpowiednie narzędzia, takie jak Jira i Confluence, pozwoliły zespołowi skupić pracę w jednym miejscu i mierzyć postępy.
Agilent uznało, że transformacja Agile wymaga sponsora, który będzie nadzorował badania i rozwój, marketing przychodzący oraz jakość. „Jeśli nie możesz objąć transformacją wszystkich tych trzech obszarów, nie odniesiesz sukcesu”, powiedział Sadler. „Nie sposób osiągnąć transformacji Agile w oparciu o same badania i rozwój”. Najważniejsza jest nie praca wykonywana w ramach funkcji, ale sposób, w jaki one ze sobą współpracują.
Agilent odkryło też, że konieczne jest zrezygnowanie z założenia, że doskonałe zrozumienie potrzeb klienta jest kwestią wyłącznie wewnętrzną. Podejście agile polega na wydawaniu produktów zgodnie z ustalonym harmonogramem, a następnie otrzymywaniu informacji zwrotnych bezpośrednio od klientów. Takie podejście wymaga założenia, że daty wydania są świętością, a kiedy nadejdzie termin, zespół dostarcza produkt w takim stanie, w jakim aktualnie się on znajduje.
Jak mówi Sadler, model Agile sprawia też, że problemy są widoczne. Na przykład metodyka Agile pozwala dostrzec luki w wydajności. Ujawnia części procesu, które nie są wartością dodaną, które powodują opóźnienia i unaoczniają błędy jakościowe. Przejście z podejścia kaskadowego na metodę Agile wymaga nie tylko zmian w sposobie pracy zespołów, ale także zmian kulturowych. Agile stymuluje kulturę ciągłego doskonalenia, która jest wręcz zaraźliwa.
