Autorzy Zapostowane przezAdam

Adam

5 WPISY 0 KOMENTARZE

0 27
agile man

Szał na Agile – tak, „szał” to słowo, które wydaje mi się w tym przypadku całkiem odpowiednie – trwa na świecie od kilku dobrych lat (jeśli nie od jakiejś dekady). Komu ten wyraz nic nie mówi, ten obowiązkowo musi zaktualizować swoją wiedzę na temat zarządzania. Agile jest modny. Agile jest trendy. Agile jest potrzebny. Agile dla firm innowacyjnych, które idą z duchem czasu to po prostu „must-have”. A mnie natomiast nowatorskość Agile wydaje się mocno przereklamowana. Hmmm, może powinnam ująć to inaczej: wydaje mi się, że Agile wcale nie jest tak unikatowy i wyjątkowy jakby się na pierwszy rzut oka wydawało. Aaaa, kij w mrowisko – checked. A niech się posypią i te sprzeczne komentarze. Tylko konstruktywnie, proszę! Już rozwijam temat:)

Na czym polega koncepcja Agile? Agile to w bezpośrednim tłumaczeniu „zwinny”. Innymi słowy elastyczny, zmienny, „łatwodostosowalny”. A jakie ma to bezpośrednie przełożenie na zarządzanie projektami? Wiodąca koncepcja Agile mówi, że na początku projektu nie powinniśmy na siłę planować całego jego przebiegu aż po produkt końcowy. Projekt powinniśmy wykonywać „w kawałkach”, tzw. iteracjach. W projektach zwinnych zakres nie jest ściśle określony, na początku projektu często nie wiemy jak ma wyglądać ostateczny wynik. Ustalamy razem z Klientem obszar produktu, nad którym popracujemy w pierwszej fazie (iteracji). Po ukończeniu fazy musimy koniecznie mieć namacalny produkt cząstkowy. Kawałek produktu, który da się zobaczyć, ocenić, by na jego podstawie móc ustalić co robimy dalej, w kolejnych iteracjach. I tak powtarzamy wielokrotnie aż do uzyskania upragnionego efektu końcowego. To co uwielbiam w Agile, to koncepcja zespołów „samoorganizujących się”. Zwinne zespoły to takie, które poniekąd same sobą zarządzają. Same ustalają kto jaką rolę będzie pełnił w danej iteracji, komu jakie zadania zostaną przypisane. Jak się domyślacie, rola lidera w projektach zwinnych jest mocno ograniczona. Zadaniem „przywódcy” jest tutaj ułatwianie pracy zespołowi, pokonywanie przeszkód jakie zespół projektowy napotyka w zderzeniu z otoczeniem pozaprojektowym, np. z ograniczeniami płynącymi z organizacji, w której zespół funkcjonuje. Zatem rolą lidera jest zazwyczaj również kontakt z Klientem. To jedynie zarys ogólnej koncepcji. Jest wiele metodyk, odłamów Agile. O nich może kiedyś w oddzielnych artykułach.

Agile a planowanie w stylu klasycznym

Jak to ma się do projektów zarządzanych klasycznie, stylem waterfall? Styl „wodospadowy” rzeczywiście skupia się na tym, by na początku projektu dobrze określić jego końcowy cel i kryteria sukcesu, by dokonać wszelkich dogłębnych analiz, by jak najwięcej czasu poświęcić na planowanie, bo ten czas podobno w fazie realizacji zwróci nam się z przysłowiową „nawiązką”. Ale ten styl również zakłada iteracje, czyli powtarzalność kroków wewnątrz poszczególnych faz projektowych. Ten styl również mówi o planowaniu kroczącym, które zakłada, że nie jesteśmy w stanie w szczegółach zaplanować całego projektu na samym początku. Co możemy, zrobić, to zaplanować fazy projektowe, podstawowe kroki, które musimy w projekcie wykonać i najbliższą fazę projektową zaplanować w szczegółach. Plany dla kolejnych faz projektowych będziemy doprecyzowywać zbliżając się do tych faz. Jeśli wiem, że pierwsza faza w moim projekcie to rekrutacja, a potem szkolenie, to dokładnie zaplanuję poszczególne kroki i scenariusze rozwiązania w fazie rekrutacji. Szkolenie prawdopodobnie zaplanuję na bardzo ogólnym poziomie, a plan ten doprecyzuję pod koniec rekrutacji. Wtedy dokładnie będę wiedziała ile osób weźmie udział w szkoleniu i jakie są potrzeby szkoleniowe. Czy czegoś Wam to nie przypomina? Jeśli chodzi o zarządzanie ludźmi, to „klasyka” nakazuje liderowi przypisywać zasoby do zadań. Czy znacie jednak teorię przywództwa, która mówi by robić to na siłę?

 Zmiany nieuchronne również w „klasyce”

Owszem, mogą zdarzyć się skrajne przypadki, w których rządzi klasyka. Wyobrażam sobie, że takich znajdzie się sporo w budownictwie, górnictwie, ogólnie w przemyśle. Jak przemyślę swoje doświadczenie, szybko jednak nasuwa się wniosek, że niejednokrotnie intuicyjnie działam w stylu Agile. Członkowie moich zespołów decydują na jakie zadania „rozbić” projekt i kto z nich będzie je wykonywał. Ja ich jedynie w tym zakresie wspieram. Nikt tego oficjalnie Agilem nie nazywa. Wszyscy niby myślą na nutę klasyczną. Tymczasem? Każdy wie, że określony cel projektowy będzie ewoluował w trakcie trwania projektu, że plany pewnie niejednokrotnie się zmienią, zmieni się otoczenie, zmienią się wymagania, zmieni się koncepcja. Tak! Bo rzeczywistość taka po prostu jest. W projektach ciągle się coś zmienia. Jeśli pracujemy dla organizacji, która chce być konkurencyjna, zmiana w projektach jest nieuchronna. Jeśli mogę pozwolić sobie na odrobinę szczerości, niejednokrotnie przysparzało mi to wiele frustracji. Jako świeżo upieczony kierownik projektu, denerwowałam się, że jeszcze wczoraj tak pięknie dopieszczony plan projektowy, dzisiaj już nie obowiązuje i trzeba go zmieniać. Przy dużych zmianach organizacyjnych zespołom tak trudno było doprecyzować finalną koncepcję struktury organizacyjnej i docelowego procesu, że wydawało mi się, iż z fazy planowania nigdy się nie wydostaniemy. I co? I trzeba było tworzyć jedynie zarysy nowej struktury, ramy nowego procesu, adresować obszary na daną chwilę bardziej oczywiste, ruszać z projektem i z czasem doprecyzowywać co dalej.

Agile a klasyczne koncepcje zarządzania ludźmi

Jeśli chodzi o zespoły, w klasycznym stylu zarządzania rzeczywiście może być różnie. Style zarządzania ludźmi i sposoby ich motywowania zależą od kierownika projektu, od kultury organizacyjnej. Jednak mój styl mocno wpasowuje się w Agile. Nie wyobrażam sobie zmusić kogoś do wykonywanej pracy. Wyznaję zasadę, że „z niewolnika nie zrobisz pracownika”. Sama jestem tego chodzącym przykładem. Za każdym razem, gdy moja praca ograniczała się do wykonywania zadań, za którymi nie przepadam, rozglądałam się za nowym zajęciem. Gdy moja nowa szefowa codziennie rozliczała mnie z pracy wykonanej w ciągu dnia, zaczęłam wysyłać CV. Na szczęście zdobyłam się na szczerą rozmowę i pozbyłyśmy się tego problemu w inny sposób. Staram się traktować ludzi tak samo, jak chciałabym być traktowana i w swoich projektach pozostawiam im dużą swobodę. Tak, nie zawsze ludzie wykorzystają tę swobodę w odpowiedni sposób. Z tym problemem jednak boryka się również Agile.

Dla kogo Agile?

Podsumowując, Agile jest świetną koncepcją dla każdej organizacji, niezależnie od branży. Jednocześnie Agile wcale nie jest czymś tak niesamowicie nowatorskim dla organizacji, które w metodzie klasycznej dawały swoim pracownikom dużo swobody i liczyły się z nieuchronnymi zmianami z projektach, czy też godziły się z faktem, że projektu nie da się na samym początku zaplanować od A do Z. Agile jest trudny do wdrożenia szczególnie dla kierownictwa wyższego szczebla przyzwyczajonego do tego, że zawsze widzi efekt końcowy, do którego zmierzamy, zna koszty całego projektu. Choć rzeczywistość dynamicznie rozwijających się organizacji jest taka, że zarówno kształt tego efektu końcowego, jak i koszty całego projektu zmieniają się w trakcie realizacji. I tego doświadczony management jest świadomy. W takich przypadkach organizacje wdrażają często Agile „na dole” struktury, a „góra” bądź Klient nadal dostaje raport w stylu klasycznym. Moim zdaniem to bardzo niekorzystne rozwiązanie i zaakceptowałabym je jedynie jako przejściowe. Owszem, mieszanie metodyk to świetne rozwiązanie. Nie ma jednej metodyki, która idealnie adresuje potrzeby organizacji. Każda organizacja powinna „uszyć sobie metodykę na miarę” swoich potrzeb. I takie rozwiązanie może mieć elementy Agile i waterfallowe. Nie ma w tym nic złego. Jeśli jednak wprowadzam elementy Agile do danego obszaru projektowego, to kompleksowo, w całe strukturze organizacyjnej. Nie ma sensu rozwiązanie, w którym „udaję”, że zakres jest nieokreślony i mogę sobie go doprecyzować w trakcie projektu, jeśli tak naprawdę za projektem jest już kontrakt podpisany z Klientem, w którym dokładnie sprecyzowaliśmy co otrzyma Klient, w jakim czasie i za ile.

To tyle gwoli zarysu fenomenu Agile. Polecam wnikać głębiej i wdrażać w swoich projektach. Osobiście uwielbiam swobodę i otwartość metodyk zwinnych.

0 34
skalowanie agile

Ci z Was, którzy znają mnie nie od wczoraj dobrze wiedzą, że nie jestem zwolennikiem żadnej z coraz popularniejszych „metod” skalowania Agile. Często wypowiadam się na ten temat i przeważnie negatywnie.

„Jeśli skalujesz Agile to robisz to źle.”

Wszystkie znane mi do tej pory metody i frameworki z SAFe (Scaled Agile Framework), Scrum of Scrums  i Agility Path na czele próbują narzucić rożne zasady i reguły, które maja być mniej lub bardziej uniwersalne dla każdej organizacji. To po prostu nie ma prawa działać.

Miałem okazję przez ostatnich kilka lat pracować z wieloma organizacjami, niektóre z nich były całkiem duże. Na tyle duże, że musiały zmierzyć się z problemem skalowania. Najczęstszym błędem który podczas takich prób zmierzenia się ze skalowaniem widziałem była próba zastosowania danej metody skalowania bez uprzedniego zastanowienia się nad problemami, które chce się rozwiązać.

Większość promowanych „metod” ze znajomości, których można sobie zrobić (kupić) różne certyfikaty których ładnie brzmiące nazwy możemy sobie później wpisać na linkedin według mnie nie rozwiązuje podstawowych problemów, lecz wręcz przeciwnie poprzez swoją pozorną prostotę i obietnicę naprawienia wszechświata generują więcej problemów niż rozwiązują. Nie – nie neguję wartości tych metod (nie wszystkich i nie całkowicie – tylko trochę) – niektóre z nich świetnie działają w pewnym kontekście. Niektóre pojedyncze elementy tych metod bazują przecież na prawdziwych wartości Agile i Lean jedyne co jest z nimi nie tak to próba zbudowania z nich zamkniętego narzędzia o uniwersalnym zastosowaniu.

Ktoś zarzucił mi nawet że jestem egoistą który twierdzi, że ludzie pracujący w dużych organizacjach nie zasługują na Agile. Hmm, niektórzy ludzie, w niektórych organizacjach – tacy, którzy nie chcą niczego zmienić, albo boją się zmian być może nie tyle nie zasługują na Agile  co Agile mógłby im zaszkodzić więc to raczej nie jest dla nich.

Powyższe nie oznacza, że nigdy z problemem skalowania się nie mierzyłem i nie mam w tym żadnego doświadczenia. Osobiście do tematu skalowania zawsze podchodziłem na kilku płaszczyznach i za każdym razem, w każdej organizacji wygląda to zupełnie inaczej, niemniej jednak często powtarzają się pewne tematy.

Po co skalować Agile?

Pierwsze zadawane przeze mnie pytanie tyczy się tego dlaczego dana organizacja jest na tyle duża, że potrzebuje jakiejś metody skalowania?

To pytanie może wydawać się proste, ale w większości przypadków próba zastanowienia się nad odpowiedzią prowadzi do źródeł wielu innych problemów, których rozwiązanie pozwala uniknąć potrzeby zastosowania metod skalowania. Czasem okazuje się, że wystarczy organizację podzielić na mniejsze, bardziej niezależne komórki skupione wokół poszczególnych produktów lub komponentów i okazuje się, że niczego nie trzeba skalować. Czasem dochodzimy do wniosku, że problemy, które chcemy rozwiązać są gdzieś indziej niż adresują to różne metody skalowania i wystarczy właśnie tam skupić swoją energię. To co niewątpliwie jest potrzebne w każdej organizacji bez względu na wielkość to określona metoda wspomagająca proces Continuous Improvements.

Co to znaczy skalować?

Drugie pytanie dotyczy tego co rozumiemy przez skalowanie?

Skalować możemy organizację zapewniając odpowiedni framework wymiany wiedzy oraz zapewniania transparentności i możliwości ciągłej inspekcji i adaptacji na wielu (wszystkich?) poziomach organizacji. Każda organizacja jest inna i narzucanie tutaj odgórnie struktury (tak jak próbuje to zrobić SAFe) jest raczej wątpliwie skuteczne. Czasem oczywiście (zwłaszcza gdy mamy do czynienia z chaotyczną organizacją o wątpliwej strukturze) narzucenie struktury jest świetnym posunięciem – tutaj SAFE z pewnością się sprawdza (przyznam, że jako konsultant poleciłem kilka razy SAFe właśnie w takich przypadkach).

Skalowanie to również skalowanie produktu. Jeśli mamy do czynienia z monolitycznym produktem, z dużym legacy i długiem technicznym to wartość wdrożenia jakiejkolwiek metody skalowania będzie raczej znikoma. Często do tego problemu docieramy zadając pierwsze pytanie powyżej – to taka architektura często jest przyczyną nadmiernego wzrostu organizacji.

Trzecie pytanie to w zasadzie obserwacja tego jak w tej chwili wygląda organizacja i w jaki sposób podejmowane są decyzje?

Wizualizacja tego procesu często jest już wystarczającym krokiem w kierunku poprawy i usprawnień. Value Stream Mapping i zaangażowanie odpowiednich osób w dyskusję może bardzo pomóc.

Następnie jest czas na pytania o to czy istnieje coś takiego jak wizja organizacji i wizja produktu? Jak ta wizja, misja i deklarowane wartości są reprezentowane przez realne, codzienne działania? Czy wizja jest klarowana i transparentna? Czy wszyscy w organizacji są jej świadomi? Czy mają na nią wpływ? Czy ludzie w organizacji utożsamiają się z wartościami deklarowanymi przez organizację.

Mając jasną wizję produktu możemy ją dekomponować na pracę dla poszczególnych zespołów produktowych. Mając jasną wizję organizacji możemy ją dekomponować i uskuteczniać w pętli Inspect & Adapt na poziomie każdego zespołu i całej organizacji.

W powyższy (opis mocno uproszczony) sposób staram się pracować z organizacjami już od dłuższego czasu dlatego też wczorajszego wieczoru zainteresowała mnie prezentacja mówiąca o „nowym” podejściu do skalowania: Scrum at Scale proponowana przez Scrum Inc. Tak jak w tytule jest to niewątpliwie światełko w tunelu dla osób poszukujących odpowiedzi na pytanie jak skalować organizację. Czy to światełko okaże się oczekiwanym rozwiązaniem wielu problemów czy może raczej nadjeżdżającym pociągiem? Myślę, że wszystko zależy od tego jak to dalej się potoczy i w którym kierunku popchną tą „metodę*” jej „twórcy**”. Na szczęście nie  ma (jeszcze) zmyślnej ścieżki certyfikacji co moim zdaniem daje nadzieję, na to, że ktoś faktycznie chce pomagać organizacjom a nie tylko i wyłącznie trzepać kasę kopiując model szkoleń i certyfikacji CSM i PSM z przed lat (za pierwszym razem to miało sens i wnosiło wartość – teraz certyfikatów na rynku zdaje się być kilkadziesiąt razy więcej niż możliwych do zastosowania w praktyce metod).

Z pewnością w najbliższym czasie będę chciał się bliżej przyjrzeć tej metodzie. Być może za jakiś czas przeczytacie o tym jak bardzo się myliłem i to tylko kolejny marketingowy BS, który ktoś próbuje wcisnąć ludziom z problemami zamiast pomóc im naprawdę te problemy zdiagnozować i rozwiązać…

 

*Scum at Scale cieżko jest mi nazwać metodą – to raczej zbiór kilku celów czy problemów które każda organizacja powinna zastosować. Ciekawą ideą jest wspomniana modułowość  proponowanego rozwiązania.

**Nie jest to też nic nowego bo podstawy są zbliżone chociażby do tego co można było znaleźć w początkowych wersjach SAFe, na pierwszy rzut oka widać też, że twórcy dużo inspiracji czerpią od takich autorów i myślicieli ze świata Lean i Agile jak chociażby Mary i Tom Poppendieck (Lean Software Development) czy Tom Gilb (Evo Method)

0 27
zarządzanie projektami

Od kilku lat wśród programistów dużą popularnością cieszy się Agile Software Development, czyli zwinne wytwarzanie oprogramowania. Popularność tego zjawiska sprawiła, że w nomenklaturze projektowej pojawiło się Agile Project Management, czyli zwinne zarządzanie projektami. O ile pierwsze można z pewnością z powodzeniem zastosować do wykonywania oprogramowania i innych procesów wytwórczych (z dużym powodzeniem można stosować w marketingu), o tyle zwinne zarządzanie projektami jest sprawą dosyć umowną. Metodyki zaliczane do Agile Project Management, wśród nich m.in. Scrum, są mimo wszystko tylko sposobami samej realizacji projektu.

Analizując główne założenia Scruma pod kątem zarządzania projektem, dochodzimy do wniosku, że brakuje w nich wytycznych dotyczących inicjacji oraz zakończenia projektu. I są to elementy, przez które Scruma tak naprawdę nie powinno się stosować dla całego projektu. Scrum bowiem zakłada wykonywanie kolejnych zadań pochodzących z określonego zbioru, w mniejszym lub większym stopniu zdefiniowanych i gotowych do realizacji, w stałych cyklach realizacyjnych. Zazwyczaj na początku realizacji projektu liczba cykli jest znana, dzięki czemu można powiedzieć, że znany jest także czas i budżet takiego projektu. Scrum zakłada także pracę w grupie, której liczba pracowników jest z góry narzucona, a kompetencje pozwalają wykonać cały projekt. Podstawowe założenia realizacyjne Scruma odnoszą się więc do czegoś wcześniej przygotowanego.

scrum zarządzanie prjektami

Pojawia się więc pytanie, czy zwinne zarządzanie projektem jest tak naprawdę zarządzaniem projektem. Tradycyjne metodyki wyróżniają, w zależności od metodyki, minimum trzy etapy w projekcie. Faza inicjacji, faza realizacji i faza zakończenia – zgodnie ze sztuką prowadzenia projektów takie etapy (fazy) w każdym projekcie muszą się znaleźć. Czy są one w Agile Project Management? Nie, i wątpliwe jest czy można byłoby je w nim zaimplementować. Został on bowiem stworzony z zupełnie innym zamysłem, zupełnie inna idea mu przyświecała. Miał skutecznie poprawić efektywność projektów, miał sprawić, że projekty będą kończone z sukcesem, nie zaś zarzucane w trakcie realizacji bądź planowania. Agile Software Development był, jak się później okazało, w miarę dobrym narzędziem poprawy wydajności projektowej. Agile Project Management nie zawsze musi być skuteczny, jeżeli chodzi o wykonanie projektu jako całości.

Dlaczego więc mówimy o zwinnym zarządzaniu projektami, dlaczego zyskuje ono coraz większe grono zwolenników, które powoli wykracza już poza sferę informatyki i programowania? Odpowiedź na to pytanie znajdziemy w sposobie działania wielu firm wykonujących na zlecenie pewne usługi. Niech przykładem będzie firma świadcząca szeroki zakres usług marketingowych. Przychodzi do niej klient, który zamawia kampanię reklamową swojego produktu/usługi, do wykonania w określonym budżecie i określonym czasie (na określony moment w czasie). A więc inicjacja projektu za nami. Jeżeli po zakończonej kampanii klient będzie chciał tylko faktury, naprawdę niewiele trzeba, by zainicjować i zamknąć projekt. Kwintesencja takiego projektu, czyli realizacja kampanii marketingowej, może być już wykonana przy pomocy Scruma czy innej metodyki zwinnej. Z takim czymś poradzą sobie one z nawiązką.

WŁĄCZENIE INICJACJI I ZAKOŃCZENIA W SCRUMOWE ITERACJE

Czy istnieje sposób „naciągnięcia” założeń Scruma do objęcia nim całego projektu? Chyba najlepszym sposobem jest włączenie fazy inicjacji w cykle „produkcyjne” Scruma. Od samego początku Scrum Master wraz z trzonem zespołu powinien przygotowywać projekt, a efektami kolejnych cykli jego pracy powinny być dokumenty inicjujące projekt (ich liczba i zakres mogą być zaczerpnięte z jednej z tradycyjnych metodyk zarządzania). Także faza zakończenia, wymagająca zazwyczaj testów odbiorczych, może być włączona pod postacią ostatniego cyklu realizacyjnego.

Czy takie rozwiązanie sprawdzi się w rzeczywistości, zależeć będzie od umocowania Scrum Mastera w hierarchii zarządczej firmy oraz dopuszczeniu go do negocjacji z potencjalnym klientem. Duża korporacja, podzielona na działy, wydziały i oddziały pewnie nie będzie w stanie zrobić niczego takiego. W małej firmie natomiast będzie obawa o to, że Scrum Master będzie miał zbyt dużą władzę decydując o danym projekcie. Dobrym przykładem rozwiązania danego problemu byłoby uczynienie Scrum Masterem lub Product Ownerem osoby związanej z negocjacjami projektu z klientem zewnętrznym lub wewnętrznym. Rola Scrum Mastera dałaby jej władzę, Product Ownera kontrolę nad realizacją projektu. Nie jest także złą sytuacją, gdy Scrum Master (jako kierownik przyszłego projektu) będzie pełnił rolę doradczą w negocjacjach z klientem.

We włączeniu fazy inicjacji w cykle scrumowe można zauważyć jeszcze jedno niebezpieczeństwo, ale także ratunek dla projektu. Pracując z projektem, którego zakres jest zmienny i ściśle nieokreślony, będziemy mogli swobodnie pracować między kolejnymi iteracjami. Taka praca będzie dla nas nawet bardziej komfortowa. Inaczej będzie się miała rzecz, gdy klient będzie wymagał dokumentacji podobnej do tej, jaką zna z metodyk tradycyjnych. W tym wypadku należałoby zrezygnować ze Scruma.

Jest jeszcze jeden aspekt, o którym warto pamiętać, chcąc inicjować projekt scrumowo. Praca w Scrumie nastawiona jest na współpracę z klientem i zaspokojenie jego potrzeb. Inicjowanie projektu często musi zostać wykonane poza wiedzą i świadomością klienta. Tutaj może pojawić się konflikt. Ciężko sobie wyobrazić bowiem wspólną pracę nad dokumentami takimi, jak rejestr ryzyk czy plan komunikacji, w których jako ryzyko będziemy traktowali np. duże ryzyko niewypłacalności klienta, albo założymy, że o problemach ze specjalistami nie będziemy informować klienta. Wybierając to rozwiązanie trzeba będzie się z tym zmierzyć.

WŁĄCZENIE SCRUMA W FAZĘ WYKONANIA PROJEKTU

Rozwiązaniem alternatywnym będzie przygotowanie „pod Scruma” całego projektu, czyli przeprowadzenie fazy inicjacji projektu i potem zakończenia projektu przez niezależnych ekspertów, związanych z tradycyjnymi metodykami. Będziemy pewni, że projekt będzie przygotowany zgodnie z prawami sztuki zarządzania projektami, wszystkie dokumenty będą prawidłowe, a scrumowcom pozostanie tylko odpowiednie wykonanie projektu.

No właśnie, czy będzie to przygotowane dobrze dla osoby korzystającej z metodyk tradycyjnych czy dla osoby posługującej się Scrumem? Trzeba bowiem pamiętać, że wykonanie produktu projektu przy pomocy Scruma będzie wymagała odpowiedniego zainicjowania projektu, jak i jego zakończenia. W fazie inicjowania projektu realizowanego przy pomocy Scruma będziemy musieli uwzględnić takie elementy, jak zaangażowanie klienta (przedstawiciela klienta) w bieżące prace, konieczność przygotowania rejestru produktowego zawierającego krótkie opowieści będące podstawą prac zespołu, tworzenie zamkniętego i w miarę samowystarczalnego zespołu realizacyjnego, czy na końcu cykliczność dostarczania produktów i oceniania postępów prac. W fazie zakończenia trzeba będzie zwrócić uwagę na to, że cykliczne oceny wartości produktu dla klienta powinny znacząco skrócić fazę testów odbiorczych, a zmienny w czasie zakres projektu nie będzie pozwalał na porównanie efektu z zamierzeniem. Wymienione wyżej elementy są jedynie tymi, które w sposób zasadniczy rzutują na sposób przygotowania projektu.

Dla osoby tworzącej tradycyjne dokumenty uwzględniające zwinne rozwiązania jest to nie lada wyczyn. Bo jak tutaj przygotować harmonogram, gdy tak do końca nie wiadomo, co będzie robione w danej iteracji? Bo jak określić odpowiedzialność za poszczególne zadania, gdy każdy z członków zespołu może sobie je „wziąć” z tablicy? Dla każdego dobrego planisty będą to tylko kolejne elementy do zaplanowania w sposób, aby dało się je zrealizować. Najlepszy nawet planista nie zaplanuje jednej rzeczy – Kierownika Projektu, który stanie się Scrum Masterem, aby ponownie powrócić do roli Kierownika Projektu. Trudno wyobrazić sobie jedną osobę, która będzie pełniła obie funkcje, jeszcze trudniej, że którejś z nich nie będzie w realizowanym projekcie. Pozostaje więc zrównoleglenie tych ról projektowych na czas wykonania produktów projektu, aby zoptymalizować proces włączenia Scruma w tradycyjne metodyki zarządzania projektami.

0 30
poziomy budynku

Jeśli mówimy o wymaganiach i specyfikacji i wprowadziliśmy już rozróżnienie tego czym są wymagania i czym jest specyfikacja, oraz że istnieje specyfikacja funkcjonalna oraz specyfikacja techniczna to teraz możemy swobodnie przemyśleć to jak skategoryzować poszczególne poziomy wymagań i specyfikacji.

Jak w tytule pozwoliłem sobie na wyróżnienie pięciu poziomów wymagań i specyfikacji, które można by przedstawić w postaci na przykład piramidy (Wygląda na to, że ludzie w IT lubią piramidy, nie wiem dlaczego…).

Na szczycie piramidy mamy pierwszy poziom: Jaki jest cel naszego przedsięwzięcia? 

Odpowiadając na pytanie po co nasza organizacja istnieje i po co tworzy produkty najprawdopodobniej dojdziemy do odpowiedzi, że oczywiście robi to dla pieniędzy. Tak, pieniądze i ich zarabianie są celem niemalże każdego biznesu (bezpośrednio lub pośrednio – np. zyski wizerunkowe, które później się monetaryzują). Warto o tym pamiętać bez względu na to gdzie w strukturach organizacji się znajdujemy bez względu na to czy tworzymy produkty dla naszej własnej organizacji czy jesteśmy jedynie dostawcami usług dla klientów/organizacji zewnętrznych. Aby osiągnąć cel (zarabianie pieniędzy) organizacja wytwarza pewne produkty – w IT mamy obecnie do czynienia raczej nie tyle z produktami w sensie wytwarzaniem pewnych dóbr materialnych co tworzeniem produktów będących narzędziami do świadczenia usług. Tworzymy produkty, które świadczą pewne usługi dla użytkowników końcowych za które są oni gotowi zapłacić.

Drugim poziomem jest odpowiedź na pytania: Kto jest interesariuszem naszego produktu i jakie problemy próbuje rozwiązać? 

Kto jest naszym odbiorcą i jest gotów zapłacić za „rozwiązanie” swoich problemów, spełnienie potrzeb? Jakich problemów i potrzeb? Warto pamiętać, że dla interesariuszy celem nadrzędnym też są raczej pieniądze więc myśląc nad produktami powinniśmy brać pod uwagę to w jaki sposób my możemy zarobić na tym, że zarabiają (oszczędzają) nasi klienci?

Mając problemy do rozwiązania i grupę odbiorców docelowych naszych rozwiązań mamy właściwie wysoko-poziomową definicję produktu.

Trzecie poziom to zdefiniowanie tego co będzie robił, czy też jakie funkcjonalności będzie zawierał nasz produkt by rozwiązać powyższe problemy interesariuszy?

Powyższe trzy poziomy to wymagania – co nasz produkt będzie robił by rozwiązać konkretne problemy, konkretnych interesariuszy. Na tym poziomie mamy zdefiniowane na pewnym poziomie abstrakcji ficzery naszego produktu. Możemy przystąpić do badania rynku i sprawdzania naszej hipotezy, że odbiorcy faktycznie potrzebują rozwiązać te problemy i są gotowi za nie zapłacić.

Czwarty poziom to  Specyfikacja Funkcjonalna – czyli odpowiedź na pytania w jaki sposób nasz produkt rozwiązuje problemy interesariuszy, jakie konkretne funkcjonalności dostarcza? 

Tutaj specyfikujemy jakie konkretnie funkcje naszego produktu użytkownicy będą mieli do dyspozycji. Możemy zbadać czy dane funkcjonalności są faktycznie przez użytkowników używane – czy są im potrzebne?

Piąty poziom to Specyfikacja Techniczna – w jaki sposób działają poszczególne funkcjonalności oraz jak są zaimplementowane?

Czwarty i piąty poziom to obszary w których możemy (a nawet powinniśmy) pokusić się o wykonywanie testów A/B i ciągłe usprawnianie dostarczanych przez nas funkcjonalności, tak by jeszcze lepiej spełniały oczekiwania użytkowników.

Na zakończenie jedna ważna uwaga: Nawet jeśli świetnie zdefiniujemy założenia co do wymagań i specyfikacji w naszym produkcie oraz poprawnie to zaimplementujemy to wcale nie znaczy, że nie mogą się one zmienić – to rynek zwaliduje czy mieliśmy rację. Dlatego też tak istotne jest testowanie naszych hipotez oraz wydawanie nowych wersji produktów – eksperymentowanie jak najczęściej, wprowadzając minimalne inkrementalne zmiany.

0 22
timebox
Podczas jednego z realizowanych przeze mnie projektów coachingowych (Agile Coaching) pojawił się problem z timeboxami. Poniżej kilka fragmentów maila jaki przysłała Scrum Master zespołu.
Z jednej strony fajnie, że się (developerzy) angażują i widzą pewne problemy w zespole (…) Nie chcę przerywać komuś kto odważył się włączyć do dyskusji w połowie zdania, bo wiem, że każdy tak naprawdę dojdzie do sedna tego co chciał powiedzieć. Ale z drugiej strony fakt, że nie jestem w stanie przewidzieć kto w kwestii danego problemu się odezwie i ile zajmie mu wypowiedź sprawia, że Retrospekcje strasznie się przeciągają – czasem nawet o półtorej godziny!
Tak, przedłużanie spotkania o półtorej godziny to faktycznie problem. Twórcy Scrum tworząc ten framework zadbali o to, by każdy artefakt i spotkanie miały określony cel, który jest ważniejszy od samego sposobu  przeprowadzania tego spotkania czy implementacji danego artefaktu. Wprowadzenie ram czasowych jest też nie bez znaczenia – w ten sposób jesteśmy w stanie w efektywnie zarządzać naszym czasem. Mając jasno określony cel – to co chcemy mieć po wyjściu ze spotkania i ramy czasowe pozostaje nam jedynie wymyślenie efektywnego sposobu osiągnięcia celu w zadanym czasie.
Jak sobie zatem radzić z problemem przedłużających się spotkań – oto co było w dalszej części maila:
Nie mamy pomysłu co można by jeszcze zmienić. Do tej pory staraliśmy się zoptymalizować:
– przygotowanie planu spotkania (w miarę możliwości)
– wybieranie najważniejszych problemów (które mają odpowiednią ilość głosów innych członków zespołów)
– moje przypominanie ile jeszcze zostało do końca spotkania (ile mamy czasu)
I o ile dochodzimy do postanowień i wszystkie cele tego spotkania są spełnione, to jednak nie jesteśmy w stanie zmieścić się w czasie.
Powyższe próby to z pewnością dobra droga. Jak widać w powyższej wypowiedzi cel spotkania jest osiągany a głównym problemem jest próba zamknięcia tematu w ramach czasowych.
Najważniejsze jest to, by z retrospekcji były jakieś postanowienia (konkretnie: zaplanowane akcje, które można wykonać a nie obietnice) i by te postanowienia były realizowane.
Zanim zasugeruję jakieś rozwiązanie tego typu problemu kilka pytań pomocniczych:
  • Czy czujecie/widzicie, że robicie postępy dzięki takim retrospekcjom? Czy wnoszą one wartość? Czy wartość retrospekcji przewyższa koszt czasu spędzonego na tym spotkaniu?
  • Czy oprócz tego, że „łamiecie reguły” Scrum przedłużając retrospekcje są jakieś negatywne efekty takich przedłużonych spotkań? Jakie?
  • Czy zespół widzi to jako problem?
  • Czy ktoś poza zespołem widzi to jako problem? (BTW: Jeśli tak to co mu do tego?)
  • Nieśmiertelne pytanie do Scrum Mastera – czy pytałaś zespół o to jak rozwiązać ten problem?
    • Czy według Was gdyby spotkanie było krótsze to mogło by być równie efektywne? Co musiało by się stać żeby tak było?

Moim zdaniem (wynika to z mojego doświadczenia) w pierwszej kolejności wdrażając tą czy inną praktykę powinniśmy nastawić się na osiągnięcie oczekiwanego efektu stosowania danej praktyki (w tym przypadku na osiągnięcie celu w postaci zaplanowanych konkretnych usprawnień). Jeśli mamy z tym problem to nie skupiajmy się na detalach takich jak przestrzeganie timeboxów – na to przyjdzie czas później. Byćmoże w Waszych zespołach nie ma takich problemów i wszystko udaje się zrobić przed czasem (a może jednak nie do końca i nie wszystko?) – w każdym razie, timebox nie zawsze jest Waszym największym problemem.

A jeśli faktycznie przedłużające się spotkania są (już) Waszym głównym problemem (prędzej czy później zapewne będą, ale może jeszcze nie teraz) to proponuję próbę wdrożenia poniższego eksperymentu.
To co teraz napiszę może wydać się Wam brutalne – niemniej jednak postarajcie się potraktować to jak eksperyment: Jednym z najlepszych sposobów na przestrzeganie timeboxów (czy to na retrospekcji, czy na planowaniu, czy na Daily Scrum) jest przestrzeganie timeboxów. Tutaj Scrum Master musi się wcielić w rolę managera, a nawet managera-tyrana i w momencie, gdy skończy się czas przewidziany na dane spotkanie brutalnie je zakończyć nawet jeśli cel nie został osiągnięty i efekty nie są zadowalające.
By coś osiągnąć w ramach określonego timeboxu warto podczas spotkania przypominać o tym, że czas się kończy, niemniej jednak, takie groźby muszą mieć pokrycie i gdy czas się skończy to spotkanie faktycznie musi się skończyć.
Z mojego doświadczenia przeważnie wystarczało jedno-dwa takie ucięte spotkania by za trzecim razem udało się osiągnąć cel. Warto zastosować tą zasadę nie tylko do retrospekcji, ale także do każdego innego wydarzenia w Scrum i nie tylko. To jest dobra praktyka, której stosowanie warto wypracować w zespole.
Oczywiście nie jest to rozwiązanie uniwersalne i może nie być wręcz wskazane dla zespołów, które dopiero zaczynają swoją przygodę z retrospekcjami i którym jeszcze nigdy nie udało się wnieść realnej wartości podczas takich spotkań. Także tak jak w opisanym przypadku radził bym najpierw nauczyć się osiągać cel takich spotkań a później pracować nad (istotnymi) szczegółami typu ramy czasowe.
Z pewnością takie rozwiązanie jest też raczej ostatecznością – warto wcześniej spróbować omówić ten problem w zespole i wspólnie znaleźć jego rozwiązanie (takie czy inne). Czasem wystarczy dobra moderacja spotkania – na przykład jeden z zespołów z którym pracowałem szybko przejął ode mnie powiedzonko: „no dobrze – ale do brzegu…”, które humorystycznie wykorzystywałem zawsze, gdy miałem poczucie, że rozmowa nie idzie w kierunku rozwiązania problemu tylko raczej jest na bardzo ogólnym poziomie i „pływamy” – a raczej dryfujemy bez celu zamiast skupić się na rozwiązaniu. „Do brzegu…” stało się zwrotem-wytrychem we wzajemnych relacjach zespołu.
Nie bez powodu użyłem słowa eksperyment powyżej. To nie jest tak, że macie od razu  wprowadzać powyższe zasady – sprawdźcie czy to u Was zadziała. A jeśli nie, to przeprowadźcie kolejny eksperyment – zmieńcie coś. Żeby eksperyment z brutalnym odmierzaniem czasu (czy jakikolwiek inny eksperyment) mógł się udać potrzebna jest przede wszystkim zgoda na jego przeprowadzenie wszystkich biorących w nim udział dlatego warto wytłumaczyć na czym ten eksperyment polega i jaki jest jego cel.