Temat: Dlaczego managerowie nie mówia o Agile?

Krótki i świetny artykuł odpowiadajacy na to pytanie [ENG]
http://www.forbes.com/sites/stevedenning/2012/04/09/th...

Temat: Dlaczego managerowie nie mówia o Agile?

Chciałbym jedynie zauważyć, że jest to opis/reklama/wprowadzenie do książki Marka Addlesona "Beyond Management: Taking Charge at Work". Zgrabne, choć tendencyjne. Agile (Agile PM) nie jest niczym odkrywczym, jest jedynie - o czym pisał sam Jim Highsmith - kreatywną adaptacją zasad Lean Manufacturing (nawet nie Lean Product Development).
Napisałem o tendencyjności tekstu, ponieważ w "łańcuszku" metod Lean wymieniono na końcu, podczas gdy z tego podejścia wywodzą się Agile i SCRUM. Kanban jest tam błędnie umieszczony, ponieważ to inna kategoria - nie metoda, a jedno z narzędzi Leanowych.

Poza tym OK - reklama jak reklama :o)

Pozdrawiam

Temat: Dlaczego managerowie nie mówia o Agile?

Myślę że to nie był łańcuszek, tylko losowo poukładane hasła. I zgadzam się że agile nie jest niczym odkrywczym. Podobnie jak znakomita większość nowoczesnych metod zarządzania, tylko tak jak autor artykułu fajnie pokazał - nie ta osoba która powinna to wymyśliła, więc nie zostało to zaadoptowane w prawidłowy sposób. Zasady Jacka Welcha bardzo szybko wpisały się w kanon, bo stał na czele wielkiej organizacji. 100 lat temu było wiele fantastycznie zarządzanych organizacji, tylko nikt o nich nie usłyszał bo były to biblioteki, piekarnie i farmy, a nie coś o ogólnoświatowym rozgłosie.

Kolejny kłopot to Product Development. Przez lata IT źle odczytywało czym jest Agile/Scrum - panowało przekonanie, że jest to metoda dla zespołów, dla programistów, a nie dla biznesu. Product Ownerzy byli sprowadzani do roli analityków biznesowych, a nie kogoś, kto rzeczywiście powinien zajmować się rozwojem produktów. Punktem przełomowym dla mnie był artykuł w HBR 10/2011 "Lean Knowledge Work" w którym było powiedziane że nie istnieje framework lean dla pracy kreatywnej, takiej jak produkcja oprogramowania. Teraz się to zmienia, ale bardzo powoli i trochę wody w Odrze upłynie zanim zostanie to zrozumiane.

Do tego pojawia się problem z kanbanem, który staje się czymś w stylu agile bez wysiłku. Pojawił się ruch, który twierdzi że jeśli wprowadzisz Kanban, masz Agile. Poza tym Kanban jest ograniczany tylko do uwidocznienia procesu ... Stanowi to bardzo duży problem i rośnie, bo przez o podejście gromy spadają na "niedziałający Agile".

Więc może i artykuł jest tendencyjny, jednak jest naprawdę homeopatyczny dodatek osób które to rozumieją. Szczególnie w Polsce, gdzie Agile, czyli metody które mają blisko 20 lat, dopiero powoli zaczynają kiełkować.

pozdrawiam,
Kasia/Kate

Temat: Dlaczego managerowie nie mówia o Agile?

Product Development, a właściwie Lean Product Development (LPD), to "druga noga" sukcesu Toyoty oraz innych firm wdrażających zaawansowane technologicznie produkty.
W IT pojawiło się rozwiązanie zwane Lean Software Development, promowane przez Mary i Toma Poppendieck'ów. Tak, jak Agile PM, są to podejścia wzorowane na Lean Manufacturing, które dość istotnie różni się od LPD.
Jedyna (jak dotąd) książka, która przybliża metodę LPD stosowaną w Toyocie jest "The Toyota Product Development System - Integrating People, process, and Technology" Jamesa M. Morgana i jeffreya K. Likera (Productivity Press, New York, 2006).
Również i ja postanowiłem nieco przybliżyć temat LPD w zastosowaniach projektowo-wdrożeniowych w swoim artykule, który ukazał się w kwartalniku THINKTANK, w numerze "Wiosna2012" (aktualny numer), a którego reprint dostępny jest w tym miejscu.

Pozdrawiam

Temat: Dlaczego managerowie nie mówia o Agile?

Z tego co rozumiem to LPD to rozszerzenie i uszczegółowienie idei przedstawionej prez panów Takeuchiego i Nonakę w słynnym "The New New Product Development Game" z HBR 1-2/1986. Zgodzę się, że Agile PM i LSD tak jak zostało to przedstawione przez państwa Poppendiecków nosi znamiona LM. Mary i Tom odwalili kawał dobrej roboty próbując przetłumaczyć na czym może polegać wprowadzanie Lean w IT i pokrewnych i bardzo ich za to szanuję. Jednak uważam że ich podejście spycha produkt na drugą pozycję, koncentrując się na optymalizacji procesu. To produkt powinien być w centrum uwagi, właśnie tak jak to jest w LPD.
Właśnie w taki sposób do tego problemu podchodzi Scrum. Intencją jego twórców było właśnie to - optymalizacja wartości dla klienta, jednak z powodu tego, że Scruma wymyśliło dwóch byłych wojskowych - żołnierz piechoty morskiej i pilot myśliwców - którzy zabrali się za programowanie zostało całkowicie odrzucone przez osoby zajmujące się zarządzaniem. Scrum dotychczas zimował w dziale IT, a nie tam gdzie powinien, czyli w biznesie, u klientów, zamawiających i odpowiedzialnych za sukces finansowy. Inzynierowie i ich bezpośredni przełożeni już zrozumieli jak należy budować oprogramowanie i dostarczać jak najwcześniej, ale do większości PMów, portfolio managerów i rad nadzorczych jeszcze to nie dotarło. Bardzo podobało mi się w Twoim artykule przyrównanie rozwoju produktów do procesów. Może to wreszcie przebije skorupę tych, do których musi to dotrzeć, żeby zaczęło działać. No, ale jak na razie estymacja ilości firm w której LM jest rzeczywiście wprowadzony w całości to 2% i podobnymi liczbami dysponuje Scrum ...

Temat: Dlaczego managerowie nie mówia o Agile?

Tom i Mary po prostu przekazują wiedzę na temat "w jaki sposób prawidłowy proces prowadzi do prawidłowych rezultatów", czyli do produktu, dostarczonego zgodnie z oczekiwaniami i wymaganiami klienta, w jak najkrótszym czasie i jak najwyższej jakości, a także za rozsądną cenę. Produkt nie jest tu czymś drugoplanowym, choć może się tak wydawać. Dlaczego? Trzeba by w tym miejscu rozwinąć koncepcję wartości, postrzeganej z punktu widzenia klienta. Wartość w takim ujęciu to pojęcie szersze od samego produktu (lub usługi). proces realizowany ze względu na wartość, którą "wyciąga" klient.

Dziękuję za komentarz do mojego artykułu :o)

Pozdrawiam

Temat: Dlaczego managerowie nie mówia o Agile?

Kiedyś mam nadzieję zostać oświeconym w kwestii analogii pomiędzy Lean Manufacturing Toyoty a Scrumem czy ogólnie "Agile" (cokolwiek to właściwie jest).
W "inżynierii" oprogramowania (sformułowanie mocno na wyrost) temat powielenia raz opracowanego produktu praktycznie nie istnieje. Każdy projekt jest prototypem. Odwrotnie jest w normalnym przemyśle, szczególnie samochodowym.

Dziwi mnie też forsowanie pewnych - użytecznych, prawda - koncepcji przeznaczonych dla małych zespołów, pracujących blisko klienta i nad projektami typu hit & run prowadzonymi w dość specyficznych warunkach, celem umieszczenia ich w miejscach gdzie się one zupełnie nie mają możliwości sprawdzić.

Temat: Dlaczego managerowie nie mówia o Agile?

Piotr D.:
Kiedyś mam nadzieję zostać oświeconym w kwestii analogii pomiędzy Lean Manufacturing Toyoty a Scrumem czy ogólnie "Agile" (cokolwiek to właściwie jest).
W "inżynierii" oprogramowania (sformułowanie mocno na wyrost) temat powielenia raz opracowanego produktu praktycznie nie istnieje. Każdy projekt jest prototypem. Odwrotnie jest w normalnym przemyśle, szczególnie samochodowym.

Dziwi mnie też forsowanie pewnych - użytecznych, prawda - koncepcji przeznaczonych dla małych zespołów, pracujących blisko klienta i nad projektami typu hit & run prowadzonymi w dość specyficznych warunkach, celem umieszczenia ich w miejscach gdzie się one zupełnie nie mają możliwości sprawdzić.

Od ponad dwudziestu pięciu lat pracuję w branży IT i - niestety ze smutkiem - zauważam takie właśnie podejście większości ludzi z tej branży. Uważają, że za każdym razem, gdy angażują się w projekt, to jest to coś odpowiadającego wymyślaniu napędu grawitacyjnego :o) Po prostu nie zauważają, jak wiele elementów projektów w branży ICT jest powtarzalnych: technologie, funkcjonalności, które implementują, itd. Każdy projekt wydaje się "innowacyjny", choć znakomita większość wcale taka nie jest.
Stąd duża niechęć do adaptowania efektywnych metod i tak duża ilość porażek.

To nie krytyka tej wypowiedzi, tylko refleksja na jej podstawie.

Pozdrawiam

Temat: Dlaczego managerowie nie mówia o Agile?

Piotr D.:
Kiedyś mam nadzieję zostać oświeconym w kwestii analogii pomiędzy Lean Manufacturing Toyoty a Scrumem czy ogólnie "Agile" (cokolwiek to właściwie jest).
W "inżynierii" oprogramowania (sformułowanie mocno na wyrost) temat powielenia raz opracowanego produktu praktycznie nie istnieje. Każdy projekt jest prototypem. Odwrotnie jest w normalnym przemyśle, szczególnie samochodowym.

Amen. Tworzenie oprogramowania ma niewiele wspólnego z inżynierią.
Jednym z absurdów toyoty jest to, że praktycznie wszystko tworzą zgodnie z Lean, z małym wyjątkiem - oprogramowania ...

Dziwi mnie też forsowanie pewnych - użytecznych, prawda - koncepcji przeznaczonych dla małych zespołów, pracujących blisko klienta i nad projektami typu hit & run prowadzonymi w dość specyficznych warunkach, celem umieszczenia ich w miejscach gdzie się one zupełnie nie mają możliwości sprawdzić.

Możesz rozwinąć tę myśl? Brzmi ciekawie, ale nie do końca rozumiem co masz na myśli...

Temat: Dlaczego managerowie nie mówia o Agile?

Henryk M.:

Piotr D.:
Kiedyś mam nadzieję zostać oświeconym w kwestii analogii pomiędzy Lean Manufacturing Toyoty a Scrumem czy ogólnie "Agile" (cokolwiek to właściwie jest).
W "inżynierii" oprogramowania (sformułowanie mocno na wyrost) temat powielenia raz opracowanego produktu praktycznie nie istnieje. Każdy projekt jest prototypem. Odwrotnie jest w normalnym przemyśle, szczególnie samochodowym.

Dziwi mnie też forsowanie pewnych - użytecznych, prawda - koncepcji przeznaczonych dla małych zespołów, pracujących blisko klienta i nad projektami typu hit & run prowadzonymi w dość specyficznych warunkach, celem umieszczenia ich w miejscach gdzie się one zupełnie nie mają możliwości sprawdzić.

Od ponad dwudziestu pięciu lat pracuję w branży IT i - niestety ze smutkiem - zauważam takie właśnie podejście większości ludzi z tej branży. Uważają, że za każdym razem, gdy angażują się w projekt, to jest to coś odpowiadającego wymyślaniu napędu grawitacyjnego :o) Po prostu nie zauważają, jak wiele elementów projektów w branży ICT jest powtarzalnych: technologie, funkcjonalności, które implementują, itd. Każdy projekt wydaje się "innowacyjny", choć znakomita większość wcale taka nie jest.
Stąd duża niechęć do adaptowania efektywnych metod i tak duża ilość porażek.

Ciekawe - czy możesz rozwinąć temat powtarzalności w tworzeniu oprogramowania? Muszę powiedzieć że na pierwszy rzut oka nie mogę się zgodzić, ale może gdzieś się rozjechaliśmy w rozumieniu.

Temat: Dlaczego managerowie nie mówia o Agile?

Henryk M.:
Od ponad dwudziestu pięciu lat pracuję w branży IT i - niestety ze smutkiem - zauważam takie właśnie podejście większości ludzi z tej branży.

Jakie ?

Henryk M.:
Uważają, że za każdym razem, gdy angażują się w projekt, to jest to coś odpowiadającego wymyślaniu napędu grawitacyjnego :o)

Wręcz przeciwnie. Większość projektów jest nudna, powtarzalna, wtórna itp. Przynajmniej 80% pracy zostało już wykonane. Problemem IT jest właśnie to, że mimo korzystania w większości z gotowych komponentów, wzorców, praktyk rozwiązanie docelowe - rozumiane jako system który rozwiązuje jakiś problem klienta - pomimo tej commonality jest zawsze rozwiązaniem unikalnym. Sam sposób spięcia gotowców w całość najczęściej powoduje różnice, podobnie jak choćby kombinacja w jakiej zostały dobrane.
Naprawdę, aby coś było unikalne - nie musi być specjalnie zaawansowane, oryginalne, twórcze itp. Nie rozmywajmy tutaj dwóch rozłącznych pojęć..

Henryk M.:
Po prostu nie zauważają, jak wiele elementów projektów w branży ICT jest powtarzalnych: technologie, funkcjonalności, które implementują, itd.

Wręcz przeciwnie - doskonale wiedzą. Tyle że nadal integracja tych gotowców jest "manualna", na etapie wczesnej manufaktury. IT, szczególnie projekty programistyczne, nie zna pojęcia automatycznej linii produkcyjnej.

Henryk M.:
Każdy projekt wydaje się "innowacyjny", choć znakomita większość wcale taka nie jest.

Projekt nie musi być innowacyjny, aby być unikalny. Stworzone rozwiązanie również.

Henryk M.:
To nie krytyka tej wypowiedzi, tylko refleksja na jej podstawie.

Sądzę, że wynikająca z pomieszania dwóch terminów.

Katarzyna Terlecka:
Możesz rozwinąć tę myśl? Brzmi ciekawie, ale nie do końca rozumiem co masz na myśli...

Posłużę sie prostą analogią. Najpierw jest założenie wprowadzające: większa swoboda, wiąże się z większą samodzielnością -> więc z większą odpowiedzialnością. "Agile" to odpowiednik wojskowych działań nieregularnych - gdzie jest jakieś pojęcie o tym co trzeba zrobić, ale nie wiadomo do końca jak. Dlatego deleguje się małą, sprawną grupę, która powinna się składać ze zgranych, dobrze wyposażonych osób przygotowanych do radzenia sobie w różnych warunkach aby najpierw cel zlokalizować, potem zidentyfikować i wreszcie osiągnąć, albo wskazać drogę do niej większym siłom regularnym. Efektywne działanie takiej grupy nakłada na jej członków dużo większe wymagania, niż działanie w dużym regularnym oddziale. M.in. dotyczące poziomu kompetencji ogólnej i specjalistycznej.

Duża, regularna armia, musi zachowywać pewną synchronizację, standaryzację...ogólnie proces. Inaczej, z armii staje się bezładnym, więc bezbronnym wobec problemu tłumem. Dodatkowo, tłumem b. kosztownym w zorganizowaniu i utrzymaniu.

Ten wątek, zresztą warto by pociągnąć przy innej okazji - jednym z najbardziej szkodliwych mitów odnośnie Agile, jest to że zespół się automagicznie "zorganizuje". Ja uważam, na podstawie własnych obserwacji, że aby pozwolić sobie na pracę "agile" trzeba włożyć właśnie dużo pracy w szeroko rozumiane "zgranie" zespołu: wypracowanie efektywnej komunikacji, wzajemne poznanie, uzupełnienie luk kompetencyjnych, zabezpieczenie narzędziowe i czysto infrastrukturalne projektu... inaczej zamiast drużyny spadochroniarzy szybko może się zrobić gang pseudokibiców. W czasie II WŚ na Pacyfiku US Navy wprowadziła koncepcję Task Force grupy sił wydzielanej ad hoc do jakiegoś zadania, z pominięciem struktury organizacyjnej (floty, dowództwa itp). To dobry odpowiednik zespołu SCRUMowego... gdyby nie to, że zapomina się o fakcie, że składniki takiej TF były pobierane wg. potrzeb ale z zespołu podobnie wyszkolonych, zorganizowanych i zmotywowanych ludzi, mających do dyspozycji w miarę zunifikowany sprzęt.

Agile ma moim zdaniem zastosowanie tam, gdzie całość zespołu może się zmieścić (jeżeli nie w pracy, to na spotkaniu) w jednym pokoju, gdzie ma z góry wyznaczone i ograniczone czas oraz inne zasoby, jest zabezpieczona od strony infrastrukturalnej, narzędziowej i ma poza tym pełną swobodę. I taki zespół, w ciągu 1 max. 2 kwartałów powinien dostarczyć rozwiązanie, które otworzy drogę do regularnej, spokojnej pracy reszcie. Wsparcie eksperta domenowego - mile widziane, podobnie jak dostęp na żądanie do niezależnej weryfikacji. I tyle.

Czasem rozwiązanie takie będzie całym projektem. Wtedy zespół idzie po prostu na inny projekt, dla innego klienta...

Natomiast zazwyczaj - jak to zostało zauważone już - projekt NIE JEST rozwiązywaniem jakiś oryginalnych problemów w warunkach dużej niepewności. Czasem (kwestia analizy wymagań, środków i możliwości) jest to bardziej kwestia sprawnej organizacji manufaktury o dużej mocy przerobowej. I tutaj ani "agile'owa" organizacja pracy, ani mały zespól po prostu nie będą efektywne. Nie są też zresztą potrzebne.

Obecnie, bardzo często forsuje się "agile" tam gdzie problem braku wymagań lub ich zmiany jest marginalny czy wręcz nieistniejący, natomiast rozmiar problemu wyklucza pracę nad nim przez zespół tak mały, aby np. SCRUM był w nim pomocą, a nie przeszkodą.
Co więcej - problem który Agile w założeniu miał rozwiązywać - "pływających wymagań" często jest sztucznie wyolbrzymiany, lub wręcz generowany przez podejście "skoro mamy Agile, to nie potrzebujemy wymagań". Tudzież, przez brak woli i umiejętności do przeprowadzenia sensownej analizy i separacji zadań "regularnych, bezpiecznych, zestandaryzowanych".
Jeżeli dorzucić do tego typowe dla większości firm kłopoty kadrowe, słabe wsparcie czysto infrastrukturalne projektu, skomplikowaną strukturę zarządzania przez mutex-y gdzie zbyt dużo osób zbyt długo czeka aż ktoś coś skończy... to robi się przepis na prawdziwy marsz ku klęsce.Piotr D. edytował(a) ten post dnia 22.04.12 o godzinie 21:56

Temat: Dlaczego managerowie nie mówia o Agile?

Powtarzalność rozumiem nie tyle w sensie robienia tego samego, co tak samo.
W SCRUM (Agile PM) technika szacowania user stories (Planning Poker) nawiązuje właśnie do tego, co napisałem wyżej.

Pozdrawiam

P.S.: Wiem, że to duży skrót myślowy, ale nie chcę rozwijać nadmiernie tego tematu, bo dyskusja zaczyna być off-topic :o)

HME

Temat: Dlaczego managerowie nie mówia o Agile?

Nie chcę wdawać się w polemikę Piotrze. Dodam tylko, że opisane we wspomnianym (swoim) artykule podejście zastosowałem do bardzo dużego i "unikalnego" projektu, którym kierowałem - robiłem coś takiego po raz pierwszy - z bardzo dobrym rezultatem.

Pozdrawiam

Temat: Dlaczego managerowie nie mówia o Agile?

Henryk M.:
Powtarzalność rozumiem nie tyle w sensie robienia tego samego, co tak samo.
W SCRUM (Agile PM) technika szacowania user stories (Planning Poker) nawiązuje właśnie do tego, co napisałem wyżej.

Jeśli dobrze rozumiem to nawiązujesz do tego, że każde wymaganie powinno być zgodne z Definition of Done, czyli potrzebne są te same elementy aby zostało uznane za zrobione. Piotr bardzo słusznie zauważył różnice między unikalnością a innowacyjnością. Jeśli w każdym języku programowania jest co najmniej kilkaset sposobów na napisanie "Hello World" na pewno nie możemy mówić o robieniu tego samego.

A Planning Poker to inna historia. Jeśli tutaj wejdziemy w szczegóły to coś mi mówi że ta dyskusja nie skończy się w kwietniu :D

P.S.: Wiem, że to duży skrót myślowy, ale nie chcę rozwijać nadmiernie tego tematu, bo dyskusja zaczyna być off-topic :o)

Off topic, ale bardzo ciekawa :)
Panowie, mam taką małą propozycję. Niedługo, bo w czerwcu wydarza się AceConf - bardzo ciekawym doświadczeniem będzie poznać Was osobiście podczas tych dwóch dni i wywołać parę dyskusji w Open Space.