Opisana w książce o tym samym tytule metodyka pięciodniowego sprintu jest szczególnym przypadkiem. Nie nadaje się na prowadzenie projektów od początku do końca. Dedykowana jest jedynie to rozwiązywania wyjątkowo trudnych problemów takich, jak najważniejsze założenia nowego produktu, albo ograniczenia technologiczne.
Wyjątkowo duży problem to taki, nad którym musi skupić się cały zespół i który stanowi blokadę w dalszej realizacji projektu. Nie ma sensu stosować metodyki pięciodniowego sprintu do bieżących prac.
Rozwój LLM powoli zaczyna przynosić działające rozwiązania. Pierwsze, które pokazały wartość dwa lata temu były copiloty wspierające programowanie.
Copilot działa w ten sposób, że w trakcie pisania tekstu przez człowieka analizuje treść i co jakiś czas podpowiada, co jeszcze człowiek mógłby chcieć napisać. W przypadku programowania ich efektywność jest olbrzymia i sam korzystam z produktu oferowanego przez Github.
Pomyślałem, że mając bazę wiedzy z plikami firmowymi we Wroolo (wroolo.com), mając model RAG, czyli taki, który semantycznie wyszukuje treści i generuje z nich nowe teksty, mogę uzupełnić go o funkcję copilot. Testowałem copilot, stosując „goły” model GPT-4, ale podpowiedzi były bardzo słabe, oderwane od mojego kontekstu.
Wszystko uległo zmianie rewolucyjnej, gdy podstawą do generowania podpowiedzi były moje własne pliki.
Poniżej wrzuciłem przykład, w którym dokumentami wejściowymi były SIWZ z urzędu miasta. Zadanie natomiast polegało na napisaniu kolejnych fragmentów nowego SIWZ. Jak widać w przypadku formułek prawnych, adresów, typowych paragrafów działa to naprawdę nieźle.
Tutaj można sobie zobaczyć przykład dla generowania oferty na szkolenie. Na wejściu wrzuciłem trzy pliki z ofertami na Massawę i zacząłem chwilę później pisać ofertę. Jak widać w wielu fragmentach algorytm trafnie wybierał treści ze źródłowych dokumentów i mi je podpowiadał. Przyjrzyjcie się, jak komponuje akapit na temat mojej osoby i mojego wspólnika Pawła.
Niesamowite jest to, że wystarczyły mi 3-5 plików źródłowych, aby podpowiedzi stały się naprawdę wartościowe. Problemów jest kilka:
Wydajność – na każdą podpowiedź trzeba czekać około 2-5 sekund. Rozwiązanie tutaj może być postawienie LLM lokalnie, albo poczekanie aż GPT stanie się szybszy.
Koszt – to jest chyba największy problem. Za każdym razem, gdy generowana jest podpowiedź, do GPT wysyłany jest bardzo długi prompt. Przygotowanie powyższych tekstów kosztowało około 1 dolara. To dużo, gdyby chcieć to wykorzystywać na codzień. Ale… ceny LLM spadają drastycznie, albo może postawić go lokalnie i mieć za darmo.
Poufność – wpisywane treści, jak i dokumenty wysyłane są do GPT i do chmury Google. To niekiedy może być przeszkodą, jednak rozwiązaniem znowu może być postawienie takiego rozwiązania lokalnie.
Jakość – około 10-20% podpowiedzi jest bez sensu. Ewidentnie wydłużenie prompta poprawia jakość, ale wpływa to na koszty i wydajność. Rozwiązaniem może być tutaj poczekanie na lepsze modele lub postawienie LLM lokalnie.
Podsumowując, moim zdaniem, gdziekolwiek w pracy pojawia się potrzeba pisania tekstów podobnych do już kiedyś napisanych tekstów, copiloty zawojują rynek. Przy programowaniu przyśpiesza mi to pracę już dzisiaj o około 20%. A pomyślmy, jak może to pomóc przy pisaniu pism do klientów, umów, prezentacji, notatek ze spotkań, dokumentacji wymagań, specyfikacji stanowisk, instrukcji, odpowiedzi na reklamacje itd.
Mam też wizję stworzenia copilota do rysowania diagramów procesowych. Gdyby to dobrze działało, byłoby niesamowitym wsparcie dla analityków. Wyobraźcie sobie, że człowiek wgrywa dostępną dokumentację, zaczyna rysować i system sam proponuje mu co wstawić w kolejnym kroku, i robi to poprawnie na chociaż 80%.
Ps.
Ze względu na koszty copilot we Wroolo jest dostępny tylko dla niektórych użytkowników.
W systemie zarządzania projektami i wiedzą Wroolo zaimplementowaliśmy mnóstwo większych i mniejszych poprawek.
Do najważniejszych zmian można zaliczyć:
Poprawienie wyglądu i efektywności działania ustrukturalizowanego Kanban. Teraz rysują się strzałki pokazujące strukturę, można ją jednym kliknięciem zwijać i rozwijać. Można dodawać nowe zadania wprost z kanban, co znacznie przyśpiesza tworzenie zakresu. Jest też dużo bardziej przejrzyście.
Dużo usprawnień w bazie wiedzy. Teraz nowy dokument indeksuje się zwykle w ciągu 2-5 sekund, chyba, że jest bardzo długi, np. cała książka, wtedy nieco dłużej. Wroolo potrafi opisywać wczytane obrazki oraz podsumowywać zawartość załączonych linków. Jest też asystent AI, który potrafi tłumaczyć i podsumowywać treści. Obok możecie zobaczyć obrazek, który został automatycznie opisany, a potem opis przetłumaczony na polski.
Dodaliśmy też różne typy postów do bazy wiedzy: link, obrazek, pamiętnik. Testowo dodaliśmy też funkcję copilot do modelu RAG. Poświęcimy temu osobny wpis. Specjalnie dla studentów naszych studiów podyplomowych stworzyliśmy moduł wikipedi, w którym można przeczytać książki uporządkowane według zadanej z góry kolejności.
Poprawa procesu logowania na komórkach. System na niektórych telefonach wysypywał się w trakcie autentykacji, bo przeglądarki mobilne nie lubią popupów z autoryzacją. Teraz jest redirect z autoryzacją.
Rozpoczęła się rekrutacja na nasze studia podyplomowe na Akademii Koźmińskiego:
Zarządzanie projektami IT – program rozszerzyliśmy nie tylko o aspekty podejścia zwinnego i kaskadowego, ale i eksploracyjnego. Zwiększyliśmy proporcje agile kosztem waterfall. Poza tym dodaliśmy blok na temat projektów AI i zwiększyliśmy nieco blok na temat analizy wymagań w IT. To będzie już nasza 30 grupa, którą organizujemy w różnych miastach Polski.
Zarządzanie wymaganiami – analiza biznesowa – dodaliśmy blok na temat zastosowania technik LLM w analizie wymagań oraz zwiększyliśmy nacisk na zbieranie wymagań w projektach discovery/eksploracyjnych. Usunęliśmy natomiast bloki teoretyczne związane z architekturą korporacyjną.
W tym roku oferujemy jeszcze jedną nowość! Studia podyplomowe na Akademii Łazarskiego – Analityk AI w biznesie.
Studia traktujemy jako szansę na rozwinięcie kompetencji analityka biznesowego i systemowego, kierownika projektów, konsultanta w obszarze rozwiązań AI. Skupiamy się na technologiach LLM i uczeniu maszynowym. Na potrzeby Analityka AI w biznesie zmontowaliśmy mocny zespół trenerów z wieloletnim doświadczeniem w sztucznej inteligencji. W ich ramach poruszymy kwestie definiowania problemów do rozwiązania przez AI, planowania rozwiązań, doboru technologii, a nawet podstaw Python.
Serdecznie zapraszamy do zapisywania się. Linki do studiów w opisie.
Obok budowania motywacji wewnętrznej, skalowanie zwinnych projektów na całą organizację jest moim zdaniem Graalem, którego poszukują zarządy.
Tak, jak warto mieć zaangażowanych ludzi, którym chce się podważać status quo i wdrażać innowacje, to duże organizacje chciałyby sklonować ideę małego zwinnego projektu na całość firmy.
Przez nasz kraj, podobnie, jak przez całą zachodnią gospodarkę przelała się fala transformacji zwinnych. Dotknęła ona szczególnie sektor finansowy i telekomunikacyjny, czyli wszędzie tam, gdzie wymagana jest wysoka innowacyjność oraz większość projektów zależy od zmian w głównych systemach informatycznych. Co ciekawe ta fala transformacji agile nie dotknęła sektora produkcji, ani usług publicznych. Jednak tam, gdzie pojawiła się, pozostawiła ślad. W poniższym tekście zbiorę moje refleksje na temat tego, jak mogłaby a jak wygląda taka transformacja.
Kontrola vs. zwinność
Duże organizacje potrzebują kontroli i struktur. Struktur organizacyjnych: działów, pionów, sekcji, bo człowiek ma ograniczoną rozpiętość kierowania i komunikacji, struktur zakresu: WBS, epic/feature/story/task, bo długie listy zadań mają tendencję do zaśmiecania się, struktur kosztów: budżety działowe, projektowe, zadaniowe, bo tak jak łatwiej rozliczać i kontrolować wydatki, struktury czasu: plany strategiczne, mapy drogowe, kamienie milowe, daty wypuszczeń, Gantty, wersje, bo podobnie jak przy kosztach tak łatwiej jest kontrolować rzeczywistość.
Natomiast pojedynczy zespół dobrze, aby pozostawał zwinny, ze zbiorową odpowiedzialnością, płaską strukturą, krótką listą zadań, planem na najbliższy sprint i nie zwracaniem uwagi na budżet.
Według metodyk skalujących agile gdzieś po drodze powinna zajść transformacja z klasycznego zarządzania i waterfall na agile. I jeszcze powinna ona być niezauważona dla zespołów, aby nie psuć zaangażowania. Na górze mamy plany bazowe, procenty realizacji KPI, odchylenia od terminów mapy drogowej, a na dole autonomię i swobodę.
Toteż dochodzi do wypaczeń. Przykładowo wg SAFE nadal wyceniajmy zadania w storypointach, ale cichaczem umówmy się, że 1 storypoint = 1 dzień i porównujmy produktywność między zespołami oraz wprowadźmy analizę odchyleń.
To magiczne przejście od agile do waterfall zachodzi przez stopniowe dokładanie kolejnych wskaźników kontrolnych. To tak jakby gotować żabę, jak będziemy robili to powoli, to może nie zorientuje się, że już nie jest taka zwinna. Drugi sposób na przejście to zrzucenie odpowiedzialności na kierowników projektów. Od góry można ich rozliczać z celów i planów bazowych, a od dołu zmusić do współpracy z niezależnymi zespołami. Piszę to z dużą ironią, bo oba sposoby na przejście od agile do waterfall często generują serie konfliktów.
Ciekawy przykładem kontroli na górze a zwinności na dole jest model spiralny Barry’ego Boehma stosowany w DARPA. Projekt w nim przechodzi przez cykle inicjacji, produkcji i walidacji, które pozwalają na utrzymanie kontroli inwestycyjnej, ale na dole, na poziomie zespołu może być tak zwinny, jak tylko chce.
Jeden ze znajomych, poddany transformacji agile, przytoczył mi ciekawy argument. Na ogólne narzekanie na bałagan powstały po transformacji zapytałem go, a gdzie to dobrze działa. Odparł, że tam, gdzie jest dobry product owner z biznesu, który wie czego chce, rozumie naturę technologii i ma na wyłączność zwinny zespół technologów. Podoba mi się ten argument. Aby transformacja agile powiodła się musimy mieć wielu product ownerów o wysokich kompetencjach biznesowych i elementarnych technicznych, którzy wiedzą czego chcą i mają na wyłączność swoje zespoły. Wraca nam idea lidera transformacyjnego, ale w wydaniu nie dyrektora a product ownera.
Problemem tylko jest fakt, że zespoły częstokroć nie są dostępne na wyłączność. Ludzie migrują, zespoły migrują i generalnie mamy dużą macierzowość. Podejście kaskadowe za pomocą szczegółowego planowania radzi sobie z tym wyzwaniem, natomiast agile ma tu problem i ludzie często wpadają w multitasking.
Motywacja do innowacji
Dlaczego organizacje potrzebują przejścia od kontroli do zwinności na poziomie pojedynczego zespołu. Powodów jest kilka: moda, argumenty rekrutacyjne dla nowych kandydatów („my nie jesteśmy złą korporacją, żółty ptak z ulicy Sezamkowej też był wielki a jaki sympatyczny”). I wreszcie mamy najważniejszy argument, tj. pozostawienie autonomii, bo ta buduje motywację wewnętrzną, zaś motywacja wewnętrzna jest silnie skorelowana z innowacyjnością.
To nie jest niewykonalne. Mimo skomplikowanych metodyk można nie niszczyć zaangażowania. Wszystko zależy od stylu, tak stylu, który każe powstrzymywać się od przesadnej ingerencji i wysłuchać maluczkich, bowiem w nich tkwi potencjał.
Pozytywny wniosek jest taki, że styl zachowania się lidera, niezależnie od przyjętego frameworku pozwala zachować poczucie autonomii w zespole. Chodzi o to, aby ludzie rozumieli uzasadnienie decyzji i mogli wywrzeć na nią wpływ.
Inżynieria oprogramowania
SAFE fajnie uwzględnił to, że oprogramowanie buduje się w specyficzny sposób, inaczej niż domy, inaczej niż nowe produkty AGD i inaczej niż kampanie marketingowe dla przykładu. Znajdziemy tu architektury, infrastruktury, wydania, stabilizację jakości, specyficzne role, jak analitycy, programiści i testerzy. I moim zdaniem dobry framework powinien uwzględniać specyfikę produkcji w danym sektorze.
Stosowanie sztywnych wydań, gdy sednem projektów jest tworzenie hardware’ów i logistyka komponentów nie działa tak, jak pisanie kodu, nie ma sensu. A z takiej założenia wychodzi Scrum for Hardware, co z resztą było gwoździem do jego trumny.
Dzielenie się wiedzą
Innowacje potrzebują kilku rzeczy, wybrane z nich, które akurat sobie przypomniałem to: zasoby, autonomia, presja na kreatywność oraz wiedza. Bez wiedzy odkrywamy koło na nowo i rzucamy infantylne pomysły.
Zwinność niestety może powodować zamykanie się zespołów w swoich bąblach poznawczych. Owszem w Scrumie regularnie dochodzi do dzielenia się wiedzą: na standupach, w ciągu dnia na kawie, na Slacku, czy na retrospektywie, ale ten oddziaływanie jest ograniczone do zespołu. Wiedza nie paruje na całą organizację tak, jakby mogła.
Spotify proponuje odpowiedź na to w postaci idei gildii, SAFe wspólnoty praktyków, DAD proponuje wszystko, co się da, więc pewnie też coś na dzielenie się wiedzą. Jednak bariery siedzą w mentalności ludzi a nie w technikach. Ja muszę nie bać się zadać pytania, ja muszę być krytyczny wobec siebie, aby wiedzieć, kiedy stanąłem pod ścianą i dopiero wówczas poproszę o pomoc. Z drugiej strony mój światły kolega musi mieć czas na udzielenie mi pomocy. Tego nie zbuduje się technikami, tylko budowaniem motywacji oraz świadomości.
Wdrażanie
I tu dochodzimy do szalenie ważnego aspektu, który bywa pomijany przez takich gigantów zarządzania, jak IPMA, PMI, IIBA, natomiast całkiem ładnie obsłużył go SAFE. W jaki sposób wdrożyć daną metodykę? PMBOK Guide ma z dodatkami około 1000 stron, a wdrażaniu metodyki na nim opartej poświęcono może z dwie. Nie da się wziąć encyklopedii i jej zainstalować w organizacji, a o tym zapomnieli twórcy DAD.
Potrzebne jest opracowanie drogi wdrażania skali w agile, a niekoniecznie konkretnego frameworku. Z resztą sam Spotify oznajmił ustami jednego z technologów, że model nazwany imieniem firmy już dawno wygląda inaczej. Nie ma właściwie modelu Spotify, jest kultura organizacyjna, która prowokuje do ciągłej ewolucji w imię autonomii zespołów i skoordynowanego rozwoju strategicznego.
Warto wspomnieć, że tą rolę, przewodnika po drodze ku transformacji, starają się też wypełnić konsultanci oraz wewnętrzni liderzy zmian.
To, co ostatecznie przebije się po dzisiejszym kryzysie transformacji agile, to podejście indywidualne. Organizacje raczej będą konstruowały własne frameworki, nazywając je jedynie za pomocą znanych terminów jak SAFE czy Spotify. Zwinność jest raczej drogą niż celem. Takie podejście sprawdziło się w lean i waterfallu. Do doskonałości można dążyć, podejmując dziesiątki racjonalnych decyzji i wybierając własną ścieżkę. Ale doskonałości nigdy nie osiągniemy.
Organizacje krok po kroczku powinny wskazywać priorytety w uzwinnianiu i utrzymywaniu kontroli. Tutaj wyraźnie widoczna jest cykliczność, na przemian zarząd uelastycznia zespoły, dając im autonomię i usztywnia przywracając kontrolę. Wszystko po to, aby znaleźć właściwy balans.
Z każdą taką pętlą uzwinniania/usztywniania wdrażane są kolejne techniki i metody pracy. A to retrospektywa, a to zakres opisany od strategii do zadania, a to sprinty, a regulowane release’y, a to samoorganizujące się zespoły, a to monitorowanie pracy, aby wyłapać wąskie gardła. Nie ma jednej drogi. Jest odkrywani, co organizacji pasuje najlepiej w danej chwili, a co trzeba zmienić.
Dla uczciwości dodam, że DAD przywołuje koncepcję Choose Your WOW, czyli wybierz swój sposób pracy. Ale robi to na tak ogólnym poziomie i zasypuje tak dużą ilością technik od sasa do lasa, że DAD staje się niestrawny.
Podsumowanie
W tytule artykułu przytoczyłem wykres popularności wyszukiwania Google Trends dla SAFe i kilku innych frameworków/metodyk. Jak widać trakcję uzyskały dwa, a jej skalę widać w porównaniu do na przykład PMI DAD – Disciplined Agile Delivery – to ta czerwona niewidoczna linia na wykresie.
Dlaczego akurat SAFE i Spotify się przebiły? Mam dwa argumenty: właściwy czas, łatwość wdrażania, adresowanie właściwych problemów. Oba modele pojawiły się dość wcześnie, gdy zainteresowanie skalowaniem dopiero narastało. DAD dołączył dużo później, co IMHO wykluczyło go z rywalizacji. Oba modele też adresują istotne potrzeby. SAFE streściłbym do potrzeby przez zarząd kontroli wśród wielu „zwinnych” projektów. Celowo słowo „zwinny” oprawiłem w cudzysłów, bo często przy wdrażaniu SAFE gubiona jest filozofia i mindset agile. DAD natomiast stara się budować kulturę współpracy z pominięciem wielu „twardych” aspektów, jak inżynieria oprogramowania, czy struktury decyzyjne. Na swoje nieszczęście LESS i S@S znalazły się w rozkroku pomiędzy dwoma atraktorami. Jak zarząd chciał utrzymania kontroli w zwinności uwaga firm ściągana była przez SAFE, jak natomiast firma chciała zbudować zwinną kulturę, nie ingerując w operacje i projekty, to w kierunku Spotify.
Jednak jak widać nawet te dwa wiodące podejścia również szczyt mają już za sobą.
Rozwój LLM powoli zaczyna przynosić działające rozwiązania. Pierwsze, które pokazały wartość dwa lata temu były copiloty wspierające programowanie.
Dużo usprawnień w bazie wiedzy. Teraz nowy dokument indeksuje się zwykle w ciągu 2-5 sekund, chyba, że jest bardzo długi, np. cała książka, wtedy nieco dłużej. Wroolo potrafi opisywać wczytane obrazki oraz podsumowywać zawartość załączonych linków. Jest też asystent AI, który potrafi tłumaczyć i podsumowywać treści. Obok możecie zobaczyć obrazek, który został automatycznie opisany, a potem opis przetłumaczony na polski.
Rozpoczęła się rekrutacja na nasze studia podyplomowe na Akademii Koźmińskiego:
Obok budowania motywacji wewnętrznej, skalowanie zwinnych projektów na całą organizację jest moim zdaniem Graalem, którego poszukują zarządy.
