Niedawno, wraz z grupą kilkunastu trenerów, Agile Coachy i liderów z różnych firm, mieliśmy przyjemność uczestniczyć w szkoleniu Scrum for Hardware. Naszym trenerem był Joe Justice, założyciel firmy Wikispeed i Prezydent Scrum@Hardware w Scrum.inc, firmie Jeffa Sutherlanda. Cały kurs był wypełniony ciekawymi obserwacjami, ale dzisiaj chciałbym się skupić na kilku najważniejszych aspektach używania Scruma do tworzenia fizycznych produktów.
Już tam byliśmy
„Zwinne tworzenie sprzętu już się dzieje” powiedział jeden z managerów odpowiedzialnych za rozwój myśliwca Saab Gripen. Mnie przypomina to trochę powrót do przeszłości, a dokładnie do miejsca, gdzie tworzenie oprogramowania było w latach dziewięćdziesiątych ubiegłego wieku. Z jednej strony istnieją firmy, które inwestują w zwinność dla tworzenia sprzętu (Agile for Hardware Product Development), i które nie wyobrażają sobie pracy w inny sposób. Z drugiej natomiast strony, większość pozostałych firm jeszcze nie słyszała o tym podejściu. Nawet gdy się o nim dowiedzą, reakcją zwykle jest niedowierzanie i stwierdzenie „to u nas nie zadziała”. Wygląda więc na to, że większość organizacji tworzących nowy sprzęt jest dokładnie tam, gdzie tworzenie oprogramowania było dwadzieścia lat temu.
Scrum w tworzeniu fizycznych produktów dzieje się tu i teraz
Mieliśmy szczęście zobaczyć konkretne przykłady szybkiego rozwoju sprzętu. Zespół Wikispeed, prowadzony przez Joe Justice, potrafi dostarczyć w ciągu zaledwie tygodnia nową wersję samochodu, dopuszczoną do jazdy po amerykańskich drogach. Pisząc ‘nową wersję’ nie mam na myśli kolejnego egzemplarzu tego samego samochodu, ale pojazd ze zmienionym zawieszeniem, silnikiem albo nadwoziem.
Kolejnym przykładem jest Dach Solarny stworzony przez 3M i Teslę. Od podjęcia decyzji, żeby pracować nad tym pomysłem, do chwili, gdy dachówki zbierające energię słoneczną były zamontowane na pierwszych domach minęły zaledwie trzy tygodnie. Co więcej, nowy produkt nie tylko pozwala generować prąd, ale jednocześnie jest bardziej wytrzymały i konkurencyjny cenowo w stosunku do standardowych rozwiązań. I świetnie wygląda.
Jednak produktem, który mi najbardziej zaimponował jest Saab Gripen. Myśliwiec tworzony przez cztery tysiące osób pracujące w szwedzkim kampusie jest zintegrowany, przetestowany i gotowy do lotu na koniec każdej trzytygodniowej iteracji. Dzięki temu jego koszty stanowią 18% ceny F-35 rozwijanego w tradycyjny sposób.
Pięć powodów, dla których Scrum w tworzeniu sprzętu jest trudny
Powyższe przykłady, wyraźnie pokazują, że można skutecznie wprowadzić idee Agile w tworzeniu fizycznych produktów. Jednak dla większości firm przejście na bardziej zwinne podejście nie będzie ani łatwe, ani szybkie. W trakcie rozmów z różnymi firmami zauważyłem pięć głównych przeszkód stojących na drodze do skutecznej transformacji firm. A jeżeli tworzyłeś oprogramowanie w latach 90-tych ubiegłego wieku i na początku tego wieku, to zobaczysz dokładnie te same wzorce, które wtedy mieliśmy.
1. Monolityczna Architektura
Większość sprzętu jest budowana z wykorzystaniem jednej, monolitycznej architektury. W konsekwencji, dowolna zmiana jednego elementu, wpływa na wszystkie inne części. W tworzeniu oprogramowania rozwiązaliśmy ten problem przez architekturę zorientowaną obiektowo (object-oriented architecture), stabilne interfejsy i enkapsulacje. Ta sama zasada dotyczy sprzętu. Pojedyńcze komponent muszą mieć zdefiniowane interfejsy, tak aby iteracyjna zmiana nie wpływała na pozostałe części produktu. Jednocześnie podobnie jak z bibliotekami softwarowymi, rośnie ilość ogólnie dostępnych, reużywalnych fizycznych komponentów, takich jak Raspberry PI, które mogą znacząco skrócić czas rozwoju produktu.
2. Praktyki i narzędzia stosowane do rozwoju i testowania produktu
W porównaniu do oprogramowania, tworzenie fizycznych produktów zajmuje wieczność. Testy są wykonywane na końcu cyklu rozwoju produktu, a znajdowane problemy powodują opóźnienia i wprowadzanie poprawek na ostatnią chwilę. Zwinne podejście wymaga szybkiego prototypowania przy użyciu prostych, dostępnych dla zespołu narzędzi, takich jak drukarki 3D. Niezbędna jest również automatyzacja testów poprzez symulacje CAD i programowalne narzędzia oraz roboty. Oczywiście stworzenie takiego środowiska pracy, wymaga to inwestycji czasu i pieniędzy, jednak na silnie konkurencyjnym rynku czas dostarczenia produktu może stanowić przewagę i zdecydować o sukcesie produktu.
3. Struktura i procesy firmy
W wielu firmach, nawet prosty zakup nowej części (jak Raspberry PI) może trwać miesiącami. Wewnętrzne procesy mogą skutecznie spowalniać już i tak dość złożony proces tworzenia nowych produktów i opóźniać czas wejścia na rynek. Czekanie na informacje, przekazywanie półproduktów między działami, wąskie specjalizacje, roczne budżetowanie, czy podejmowanie decyzji przez ludzi nie będących bezpośrednio przy rozwiązywanym problemie, to tylko przykłady marnotrawstwa w istniejących procesach tworzenia produktów. Jeżeli do tego doliczyć nadmierne raportowanie, rozbudowaną dokumentację, równoczesną pracę nad wieloma projektami i zmianę kontekstu to nie powinno dziwić, że nawet prosta zmiana może trwać lata. Na koniec wreszcie, praca zespołowa jest utrudniana przez funkcjonalną strukturę organizacji i indywidualne cele i oceny roczne.
Wszystkie te elementy stoją na przeszkodzie szybkiego dostarczania nowych produktów. Jednak żaden z nich nie ma natury technicznej, a jedynie stanowi optymalizację obecnych procesów w innym celu. Dlatego zwiększanie zwinności nie ogranicza się do wymiany narzędzi i praktyk, ale wiąże się ze zmianą sposobu funkcjonowania całej firmy.
4. Modele mentalne
Wszystkie trzy powyższe punkty są trudne do zmiany. Jednak dużo większe wyzwanie nie leży na zewnątrz, lecz w nas samych. Nasze założenia i modele mentalne kwestionują potrzebę zmiany. Tym samym słyszymy zdania w stylu „nie mamy czasu na eksperymentowanie”, „wiemy jak to zrobić prawidłowo za pierwszym razem”, „nie możemy pokazać niedokończonego produktu klientowi”. Modele mentalne mogą też dotyczyć tego jak pracujemy i prowadzić do „ja jestem moją rolą” (i nie mogę wykonywać niczego innego), lub „ludzie to zasoby” (więc trzeba nimi zarządzać). Te perspektywy są dużo trudniejsze do zmiany i skutecznie blokują transformację większości firm, nie tylko sprzętowych. Jedynie adresując te modele poprzez szkolenia i coaching, możemy liczyć na trwałą zmianę.
5. Strach przed nieznanym
Największą przeszkodę stanowi jednak strach przed nieznanym. Obecne metody pracy były stosowane przez dekady i ludzie po prostu boją się, gdy ktoś prosi ich, żeby zapomnieli wszystko czego nauczyli się do tej pory i „spróbowali” czegoś zupełnie innego. Lęk przed porażką, wykazaniem się niekompetencją i ośmieszeniem się jest ogromny. Jeżeli zmiana, zamiast przez wsparcie od managerów i coachów, będzie bazowała na indywidualnych, nierealnych celach, reakcją ludzi będzie strach, który uwidoczni się przez „to u nas nie zadziała, bo…”. Oczywiście, ten problem nie dotyczy jedynie tworzenia sprzętu, jednak w oprogramowaniu ryzyko nieznalezienia nowej pracy wydaje się być dużo mniejsze. Dlatego przy jakiejkolwiek transformacji bezpieczeństwo pracy (ale już nie roli) jest niezbędne.
Przed nami długa droga
„Agile przekroczyło przepaść” powiedziała mi niedawno Lyssa Adkins nawiązując do książki Geofreya Moore. Z pewnością jest to prawda dla tworzenia oprogramowania, ale w przypadku sprzętu, nie mamy jeszcze nawet do czynienia z prekursorami. A rynek fizycznych produktów jest co najmniej dziesięciokrotnie większy od softwarowego. Tak więc, rewolucja się zbliża, niezależnie od tego, czy Twoja firma jest na nią gotowa, czy nie.
Jeżeli chcesz dowiedzieć się więcej na temat Scruma w tworzeniu sprzętu, to sprawdź nadchodzące szkolenia Agile Hardware Development z Joe Justice, albo napisz do nas. Zobacz również na krótki Przewodnik po Scrumie dla Sprzętu oraz książkę Scrum Master autorstwa Joego, a także książkę Paolo Sammicheli Scrum for Hardware.
Jeżeli natomiast szukasz innych przykładów Scruma poza tworzeniem oprogramowania to zachęcam Cię do przeczytania Case Study naszych klientów z wprowadzenia Scruma w produkcji sprzętu, zespołach sprzedaży i wsparcia klienta.
