Knowledge Sharing Meeting, #14 ,Warsztat online
Dnia: 15.10.2021, Godz.: 9:00-13:00, Liczba miejsc: 10

10 typowych błędów projektów Agile, które Cię nie ominą

Zapisz się na warsztat
10 typowych błędów projektów Agile, które Cię nie ominą

Czy wiesz że...

tylko 61% projektów dostarczyło oczekiwanych projektów na czas i w budżecie

tylko 61% projektów dostarczyło oczekiwanych projektów na czas i w budżecie

eliminacja 10 powszechnych błędów znaczenie zwiększy szanse powodzenia projektu

eliminacja 10 powszechnych błędów znaczenie zwiększy szanse powodzenia projektu

poprzez naukę od doświadczonych praktyków Altkom możesz dowiedzieć się jak reagować na poszczególne błędy

poprzez naukę od doświadczonych praktyków Altkom możesz dowiedzieć się jak reagować na poszczególne błędy

Weź udział w praktycznym warsztacie z cyklu Knowledge Sharing Meeting.

Program warsztatu to:

  • konkret, prezentujący 10 powszechnych błędów projektów Agile
  • baza wiedzy przyczyn błędów i ich konsekwencji oraz zastosowanych rozwiązań, które zebraliśmy na  bazie naszych wniosków wyciągniętych z przeprowadzonych projektów w metodyce Agile
  • prezentacja skutków błędów projektów Agile i sposoby na identyfikacje ich symptomów
  • praktyczne przykłady i sposoby, aby skutecznie poradzić sobie z podobnymi wyzwaniami w swoich projektach.

AGENDA WARSZTATÓW

Błąd 1. Projekt agile’owy rozliczany fixed-price bez wymagań

Szczegóły: Projekt agile’owy rozliczany fixed-price, czyli bez precyzyjnie określonych wymagań przy jednoczesnym oczekiwaniu od dostawcy stałej ceny i gwarancji prawa do codziennej kontroli prac.

Skutek: dostawca przestaje być transparentny, tworzy bufory na ryzyka, następuje utrata elastyczności i przeciąganie negocjacji CRów. Ostatecznie budżet zostaje przekroczony o 50%, a zakończenie projektu przesunięte o 11 miesięcy (60%).

Symptomy: Przejrzyj log kierownika projektu i sprawdź, które symptomy dotyczą Twojego projektu:

  • Ruszam z nowym projektem na półtora roku, spory nowy system!
  • Udało mi się przeprowadzić warsztaty wewnętrzne, na których wspólnie wypracowaliśmy listę wymagań. Może lista nie jest rozpisana bardzo szczegółowo, ale w końcu każdy zorientowany rozumie, co znaczy sprzedaż produktu online w 4 krokach: wybór produktu i podanie parametrów, możliwość wyboru dodatków, uzupełnienie danych do realizacji zamówienia i umowy, potwierdzenie i odpowiednie zgody.
  • Mam potwierdzenie budżetu przez Zarząd.
  • Wybieram dostawcę. Chcemy pracować z nim zwinnie, bo nie mamy szczegółowo rozpisanych wymagań. Poza tym chcemy mieć na bieżąco dobrą kontrolę nad jego pracą.
  • Sukces! Wynegocjowaliśmy umowę. Wdrożenie jest podzielone na 4 funkcjonalne etapy, po każdym jest płatność dla dostawcy. W każdym etapie dostawca pracuje w sprintach, dookreśla wymagania, robi demo.
  • Za mną pierwszy sprint. Praca idzie dobrze. Użytkownicy zmęczeni, ale zadowoleni. Doprecyzowywanie wymagań jest angażujące, ale też wymaga podejmowania decyzji i nowych ustaleń, których nie zawsze się spodziewaliśmy. Na demo zobaczyliśmy pierwszy ekran, bardzo obiecujące.
  • Dzisiaj uczestniczyłem w dość zaskakujących warsztatach. Pracując nad krokiem wyboru produktu, analityk od dostawcy powiedział, że oczekiwany przez nas przycisk do obliczenia szacowanych kosztów nie mieści się w zakresie. I to ma być Agile? Eskaluję.
  • Żenada. Wpadła nam ważna biznesowa zmiana od Zarządu – nowy produkt. I teraz dostawca mi mówi, że ekran wyboru produktu musi zostać w całości przepisany, ponieważ nie został wcześniej przygotowany do możliwości ponownego użycia.
  • Rozmowy o CRze z nowym produktem są jakąś męką. Nie dość, że ja muszę poświęcać na to czas, ściągać użytkowników biznesowych, to dostawca wystawia do nich najbardziej doświadczone osoby, odciągając je od ratowania opóźniającego się projektu.
  • Dostałem wycenę CRa. Muszę o tym poważnie porozmawiać. Jak przeliczę koszt na czas porównywalnych zdań, to dniówka pracy w tym CRze kosztuje mnie prawie dwa razy tyle, co w projekcie.
  • Jestem po poważnej rozmowie z dostawcą. Od dłuższego czasu dokładają do projektu. Nie przewidzieli takiej złożoności naszych wymagań, szukają oszczędności i dewelopują najprościej, jak się da. Właściwie jak nie wezmę tego CRa na ich warunkach, to chcą wypowiedzieć umowę. To nie tak miało być…

Zapisz się na warsztat

Błąd 2. Testowanie tylko całych procesów biznesowych

Szczegóły: Testujemy tylko całe procesy biznesowe, czyli użytkownicy końcowi testują całe procesy biznesowe, przez co historyjki czekają na feedback 3-4 sprinty.

Skutek: niespodziewane rozbieżności w rozumieniu wymagań odkrywane po wielu tygodniach od developmentu, znaczący nieplanowany rework, opóźnienie uruchomienia pierwszego etapu o 2 miesiące oraz wzrost kosztu o 100%.

Symptomy: Przejrzyj log managera po stronie biznesu i sprawdź, które symptomy dotyczą Twojego projektu:

  • Startujemy w końcu projekt, który unowocześni systemy wspierające nasze kluczowe procesy.
  • Wybraliśmy dostawcę, który będzie pracował z nami zwinnie. Nie mamy dużego doświadczenia w projektach Agile, ale IT obiecało wsparcie w tym zakresie. Istotną zaletą jest to, że będziemy pracować nad wymaganiami już w trakcie projektu.
  • Ruszamy z pierwszym sprintem. Codziennie uczestniczymy w warsztatach, wypracowując wymagania odnośnie pierwszego procesu. Dzięki makietom widzimy, jak elementy procesu będą wyglądały w tworzonym narzędziu.
  • Z niecierpliwością czekamy na testy.
  • Pracujemy dalej nad pozostałymi elementami. Kończymy wymagania do pierwszego procesu, zaczynamy opisywać kolejny proces. Czekamy na testy.
  • Zbliżamy się do końca opracowywania wymagań do drugiego procesu, cały czas z niecierpliwością czekamy na testy pierwszego.
  • Zaczynamy testy! Niestety nie jest to łatwy start – mamy wrażenie braku zrozumienia w wielu miejscach, z drugiej strony minęło sporo czasu i nie mamy pewności, czy o tym wszystkim rozmawialiśmy.
  • Kontynuujemy pracę nad wymaganiami, bierzemy na warsztat kolejny proces, jednocześnie testujemy, zgłaszając sporo problemów.
  • Wstrzymujemy pracę nad nowymi wymaganiami, koncentrujemy się wyłącznie na testach i poprawkach błędów. Niestety projekt nabiera opóźnienia.
  • Cały czas testujemy i wyjaśniamy.
  • Kolejny sprint poprawiania błędów. Następne procesy czekają. Opóźnienie wzrasta.
  • Rozpoczynamy testy Family & Friends. Dostajemy kolejne błędy.

Zapisz się na warsztat

Błąd 3. Awans Product Ownera i jego zastępstwo

Szczegóły: Product Owner awansuje i zastępuje go proxy Product Owner, wszystko wydaje się funkcjonować jak dotychczas, ale stopniowo biznes zostaje oddzielony od zespołu scrumowego rozrastającą się warstwą dokumentacji wymagań.

Skutek: projekt stał się iteracyjnym waterfallem, przekroczenia budżetu 20-30%, przekroczenia harmonogramu o 200%.

Zapisz się na warsztat

Błąd 4. Brak szczegółowej dokumentacji projektu

Szczegóły: Jesteśmy agile, więc nie potrzebujemy szczegółowej dokumentacji, ale ponieważ biznes nie jest częścią zespołu scrumowego, to występuje etap UAT bazujący na doświadczeniu i pamięci biznesu.

Skutek: fala błędów, opóźnienie na poziomie 2 miesięcy, frustracja użytkowników biznesowych i zespołu developerskiego.

Zapisz się na warsztat

Błąd 5. Wdrożenia paczek przez zewnętrzny zespół adminów

Szczegóły: Wdrożenie paczek realizuje zewnętrzny zespół adminów, przez co wydawanie wersji na środowisko testowe zajmuje 2 dni (budowanie paczek, przekazywanie do administratorów, oczekiwanie na instalację).

Skutek: brak przeglądu prac w trakcie/na zakończenie sprintu, zgłoszenia błędów wpadające w czasie trwającego następnego sprintu powodujące niedowiezienie zakresu sprintu obiecanego na planningu.

Zapisz się na warsztat

Błąd 6. Brak budżetu na dług technologiczny

Szczegóły: Brak budżetu na realizację zadań zmniejszających dług technologiczny przez ponad rok w systemie rozwijanym już od 3 lat, w którym kilka większych zmian zrealizowano, zaciągając dług technologiczny w wysokości kilku pełnych sprintów.

Skutek: zmiana, która funkcjonalnie wymagała 2 sprintów, z powodu konieczności spłaty części długu technologicznego zajęła 4 sprinty.

Zapisz się na warsztat

Błąd 7. Pułapka dużego zespołu i dużych zadań

Szczegóły: Pułapka dużego zespołu i dużych zadań polegała na tym, że duży 30-osobowy zespół pozwalał biznesowi operować na bardzo dużych zadaniach – zespół często brał 1 zadanie na sprint, co zespołowi sugerowało, że nie powinien dzielić się na mniejsze.

Skutek:  wysokie koszty spotkań (daily, planning, retrospektywa) dochodzące do 20-30% kosztu sprintu, z małą korzyścią dla zespołu z powodu rozległości systemu.

Zapisz się na warsztat

Błąd 8. Ekspansywna rozbudowa zespołu

Szczegóły: Ekspansywna rozbudowa 10-osobowego zespołu, który otrzymał dwukrotnie większy strumień prac i postanowił urosnąć dwukrotnie w ciągu jednego sprintu. 

Skutek:  nawet po 4 sprintach nie było efektu przyśpieszenia, nastąpiło ono dopiero po kilku miesiącach.

Zapisz się na warsztat

Błąd 9. Product Owner nie posiada umocowań w organizacji

Szczegóły: Product Owner bez umocowań w organizacji, który mimo swojej wiedzy biznesowej musi konsultować wszystko z wieloma interesariuszami i nie ma spójnej decyzji na czas. 

Skutek: realizacja przez zespół historyjek zastępczych, a potem jednoczesna realizacja wielu historyjek priorytetowych, postrzeganie przez interesariuszy pracy zespołu jako zbyt powolnej.

Zapisz się na warsztat

Błąd 10. Zespół silosowy ze sztywnymi rolami

Szczegóły: Zespół silosowy ze sztywnymi rolami – analitycy, programiści i testerzy ograniczają się do „swojego” fragmentu procesu wytwórczego. Nie wychodzą poza tradycyjną rolę, czekają na polecenia lub zgłaszają oczekiwania, zamiast udzielać aktywnego wsparcia innym członkom zespołu. 

Skutek: kumulacja realizacji większości zadań w końcówce sprintu, co powodowało przesunięcie  ok. 20-30% z nich na kolejny sprint.

Zapisz się na warsztat

Dla kogo

Do udziału w warsztatach zapraszamy szczególnie: managerów IT, managerów jednostek biznesowych, kierowników projektów

Korzyści:

Umiejętność wychwycenia symptomów przyszłych kłopotów – uniknięcie typowych błędów na wczesnym etapie projektu

Poznanie sposobów zaradzenia problemom oraz kontekstu ich stosowania

Wzbogacenie warsztatu managerskiego o praktyczną wiedzę do zastosowania w projektach zwinnych w swojej organizacji

Prowadzący

Artur Kret - Szef Zespołu Konsultingu</br>w Altkom Software & Consulting

Artur Kret - Szef Zespołu Konsultingu
w Altkom Software & Consulting

Od ponad 20 lat związany z analizą systemów informatycznych, doradztwem IT dla rynku finansowego i dużych przedsiębiorstw. Jest pasjonatem docierania do kluczowych wymagań i problemów. Specjalizuje się w audytach IT oraz budowie strategii.

Lider zespołów projektowych w kilkunastu dużych projektach (1000+ md). Realizował projekty dla Polkomtel, Credit Agricole Ubezpieczenia, PZU, Aviva, Concordia, AXA Direct, ING, BRE Bank, Randstad, Skanska, Seris Konsalnet.

Łukasz Rauer - Solution Manager</br>w Altkom Software & Consulting

Łukasz Rauer - Solution Manager
w Altkom Software & Consulting

Od ponad 20 lat związany z tworzeniem i wdrażaniem oprogramowania, doradztwem w zakresie technologii i projektów IT dla rynku finansowego i dużych przedsiębiorstw. Kierownik projektów oraz lider dużych zespołów projektowych, doskonale znający metodyki klasyczne i zwinne. Dzięki doświadczeniu programistycznemu zna procesy i wyzwania związane z wytwarzaniem oprogramowania.

Ma na swoim koncie kilkanaście projektów powyżej 2000 md, m.in dla Polkomtel, Credit Agricole Ubezpieczenia, AXA Direct, PZU, Aviva, Concordia, Pocztowe TUW.

Zapisz się na warsztat już teraz!

Udział w warsztacie jest bezpłatny i wymaga naszego potwierdzenia.
Zależy nam na tym, aby uczestnicy wynieśli z tego warsztatu maksimum wartości. Zapewni to odpowiedni dobór uczestników.
Wypełnij poniższy formularz. Na podstawie udzielonych informacji zaproponujemy CI udział w tym lub kolejnych terminach.

!
!
!
!
!
!
!
!
!
!
!
!