AGILE

4 typy rozwiązywania konfliktów:

Win – Win

Rozwiązywanie konfliktów przez szukanie konsensu m.in. analizując co jest ważne dla obu stron aby znaleźć elementy z których można zrezygnować bez uszczerbku dla jednej i z satysfakcją drugiej strony.

Lose – Win

W zespole część osób może czuć się nie wysłuchana przez resztę co prowadzi do zaprzestania dzielenia się swoim zdaniem i realizowania wszystkiego, co zostaje im nakazane nawet jeśli nie widzi w tym sensu co wpływa na efektywność przez niską motywację i brak pomysłu na usprawnienia.

Lose – Lose

Niejednokrotnie zbyt asekuracyjne podejście osób nie chcących być nie kulturalnymi doprowadza do osiągnięcia tzw. zgniłego kompromisu czyli porozumienia będącego tymczasowym i nie pełnym rozwiązaniem problemu. Należy unikać tego podejścia zadając pytania o alternatywne możliwości.

Jedną z ważniejszych umiejętności leadera jest identyfikowanie i rozwiązywanie konfliktów.

Pierwszy stymuluje współpracę ale każdy kolejny ją utrudnia a w końcu wręcz uniemożliwia.

Czy widzicie je w swoim zespole? Społeczeństwie? Rodzinie, sąsiedztwie lub u znajomych?

Jako Scrum Master i Agile Coach ale także Polak i obywatel małej ojczyzny widzę je wciąż.

Poziom 1 – Problem do rozwiązania

Członkowie zespołu czują się na tyle swobodnie, że dzielą się opiniami przez co czasem pojawią się różnice zdań ale są rozwiązywane na poziomie zespołu bez ingerencji innych osób (np. Scrum Mastera). To bardzo dobra oznaka dojrzałego zespołu.

• Informacja jest dzielona podczas współpracy​

• Rozmowa jest owarta i bazuje na faktach
  

Poziom 2 – Nieporozumienie w zespole

Jeśli konflikt nie jest rozwiązywany przez zespół, generuje problemy wpływajace na projekt a brak otwartej wymiany informacji zmniejsza współpracę i efektywność. Zespół może czekać na kogoś, kto rozwiąże konflikt ale powinien sam go rozwiązać.

Źródłem konfliktów może być brak czasu i tzw. mocne osobowości w zespole, np. nie pohamowani cholerycy walczą między sobą lub z powściągliwymi melancholikami żądnymi analizy przed podjęciem działań i krytykującymi ich pochopność.

• Zamiast współpracy jest dystans i defensywne podejście

• Rozmowy są ostrożne i zostawiają miejsce na interpretacje
  

Poziom 3 – Zawody

Zespół trwa w konflikcie różnych grup i członkowie nie czują się swobodnie aby mówić o tym głośno. Zespół może potrzebować moderatora jak doświadczony Scrum Master lub zewnętrzny Agile Coach aby zamiast przerzucać się odpowiedzialnością rozwiązać konflikt.

Często istnieje jakieś źródło np. członkiem zespołu jest były team leader wciąż traktujący innych z góry; bardziej doświadczeni członkowie dominują tych świeższych stażem i obwiniają za niską jakość kodu; testerzy developerów i nawzajem za brak / mało testów.

• Wygrana jest ważniejsza niż rozwiązanie​

• Rozmowa zawiera ataki personalne
  

Poziom 4 – Krucjata

Na tym etapie rywalizujące grupy uznały, że już nic się nie zmieni i trzeba zniszczyć przeciwników. Sytuacja jest bardzo ciężka do poprawy i wymaga zew. doradcy (np. Scrum Mastera i Scrum values). Dalej jednak warto spróbować zrozumieć istotę problemu i podjąć współpracę.

Przykładem jest konflikt pracowników z managementem gdy wyśrubowane oczekiwania dostają nierealne plany, które po drodze „napotykają” na różne, niezależne problemy, które uniemożliwiają realizację planu a próby zrozumienia powodów kończą się wybuchem oskarżeń.

• Obrona siebie / swojej grupy jest głównym celem​

• Rozmowy są ideologiczne (tylko 1 strona ma rację)

Poziom 5 – Wojna światowa

Z naszego podwórka wojna polsko – polska (choć może to dopiero krucjata i wciąż jest szansa 🙂 )

• Zniszczmy pozostałych!

• Rozmowy nie występują

Jak na poziomie 4, należy zrozumieć sytuację od strony wartości i celów różnych osób i grup a następnie tworząc przyjazne środowisko z odpowiednią ilością czasu na omówienie problemów wskazując kierunek przez dzielenie się wiedzą ale unikając bezpośredniego wyrażania opinii.

Manifest zwinnego wytwarzania oprogramowania, inaczej Agile Manifesto (agile = „zwinne”), jest niezwykle krótkim przekazem mającym na celu zbliżenie świata IT do biznesu, będących często odgrodzonym murem kosztorysów i umów oraz zwiększenie efektywności i satysfakcji z pracy zespołu dzięki samoorganizacji a przez to dowożenie coraz lepszego oprogramowania spełniającego oczekiwania klienta i użytkowników.

4 wartości Agile:

Ludzie oraz interakcje ponad procesami i narzędziami
Działające oprogramowanie ponad złożoną dokumentacją
Współpraca z klientem ponad negocjacją kontraktu
Reagowanie na zmianę ponad trzymanie się planu

Choć ciężko nie zgodzić się z którymkolwiek z poniższych punktów manifestu Agile to jednak nie jest on samospełniającą się przepowiednią i nie zawsze wystarczy gdyż czasem trzeba aktywnie kreować rzeczywistość dostosowując ją do realiów odmiennych od znanych autorom manifestu, bardzo dobrze opłacanym managerom IT z firm takich jak Google, Apple i Microsoft. Bezdyskusyjnie to budżet oraz odpowiednie wynagrodzenie jest podstawą motywacji i pierwszym mitem manifestu Agile.

Oczywiście wynagrodzenie jest różne dla różnych państw z racji PKB per capita mimo iż praca programisty może być realizowana zdalnie w różnych krajach, regionach czy strefach czasowych (choć to problematyczne czytaj Scrum zdalnie) a dla niektórych, w szczególności chcących się rozwijać w nowej technologii lub dopiero uczących się developerów może mieć drugie i trzeciorzędne znaczenie a nawet żadne dla osób ideowo pracujących dla sektora NGO jednak poczucie pomocy potrafi być egoistycznie  mocnym wynagrodzeniem.

Prześledźmy go po kolei:

„Odkrywamy coraz lepsze sposoby w trakcie wytwarzania oprogramowania i pomagając innym to robić.”

Co ma sprawić, że doświadczeni członkowie zespołu będą faktycznie pomagać innym developerom w coraz lepszym programowaniu? Toż to nasza konkurencja! Oczywiście nie uważam takiego podejścia za właściwe a wręcz na odwrót, pełna współpraca daje efekt synergii i win – win ale ciężko ukryć, że niektórzy tak myślą i jest w tym coś prawdziwego. Wiem, czepiam się ale tak bywa naprawdę a założenie manifestu Agile jest trochę naiwne bo ludzie są z reguły egoistami choć każdy chce się rozwijać zgodnie z piramidą Maslowa.

Korzystanie z coraz bardziej zmyślnych ułatwień w pracy, w postaci kolejnych bibliotek wydaje się być naturalnym rozwojem ale już aktualizacja do kolejnej wersji danego języka programowania czy zmiana frameworku wymaga znacznych nakładów pracy i finansów, na które mniejsze firmy często nie mogą sobie pozwolić a nawet nie chcą, gdyż po co modyfikacje StartUp’u, która wciąż działa? Oczywiście biznes  imperatywie rozwoju oprogramowania piszę tutaj.

„W wyniku tych doświadczeń przedkłada się:”

 

„Ludzi i interakcje od procesów i narzędzi”

– co nie oznacza, że

Działające oprogramowanie od szczegółowej dokumentacji

Współpracę z klientem od negocjacji umów

Reagowanie na zmiany od realizacji założonego planu.

 

1. Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
2. Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
3. Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
4. Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
5. Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
6. Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
7. Działające oprogramowanie jest podstawową miarą postępu.
8. Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
9. Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
10. Prostota — sztuka minimalizowania ilości koniecznej pracy — jest kluczowa.
11. Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
12. W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Pełna nazwa: „Agile manifesto, Manifesto for agile software development”

Strona manifestu: agilemanifesto.org

 

Scrum w pigułce https://biegajewski.com/pl/artefakty-w-scrumie/

 

Agile Guide

Właściciel Produktu omawia założenia Sprintu i te elementy Backlogu Produktu, których realizacja
w trakcie Sprintu pozwoli na osiągnięcie Celu Sprintu.

 

przez Zespół Deweloperski, które elementy Backlogu Produktu będą dostarczone,
Zespół Scrumowy tworzy Cel Sprintu. Jest to cel, który zostanie osiągnięty w ramach Sprintu
poprzez implementację wybranych elementów Backlogu Produktu.

Cel Sprintu to założenie, które zostanie spełnione w ramach Sprintu poprzez implementację
wybranych elementów Backlogu Produktu. Dostarcza Zespołowi Deweloperskiemu wskazówek w
jakim celu tworzony jest Przyrost. Jest on tworzony podczas Planowania Sprintu.

Scrum Master zapewnia, że Zespół Deweloperski spotyka się w ramach Codziennego Scruma,
jednak to Zespół Deweloperski jest odpowiedzialny za przebieg tego spotkania.

Scrum Master egzekwuje zasadę, że tylko Zespół Deweloperski bierze udział w Codziennym
Scrumie.vsnZespół
Deweloperski może także zaprosić na to spotkanie inne osoby, aby wsparły Zespół wiedzą
techniczną lub domenową. Planning

espół Deweloperski omawia, co poszło dobrze w trakcie Sprintu, jakie napotkano
problemy oraz jak te problemy rozwiązano. Review Vs Retro

 Cała grupa wspólnie omawia kolejne kroki. W ten sposób Przegląd Sprintu dostarcza
wartościowego wkładu w następujące po nim Planowanie Sprintu.
 Dokonuje się przeglądu tego, jak rynek lub potencjalne zastosowanie produktu mogły się
zmienić i co w tej sytuacji jest najbardziej wartościową rzeczą do zrobienia.
 Rewiduje się czas, budżet, potencjalne możliwości i uwarunkowania rynkowe dla
kolejnego przewidywanego wydania produktu.

 

Zespół Deweloperski modyfikuje Backlog Sprintu w czasie trwania całego
Sprintu, tym samym „wyłania się” on podczas Sprintu. To wyłanianie się zachodzi w miarę jak
Zespół Deweloperski realizuje plan i dowiaduje się coraz więcej na temat pracy, która jest
potrzebna do osiągnięcia Celu Sprintu. Vs ustalenie z góry w planning czy budżetach i fail jeśli nie skończymy

 

Jedynie Zespół
Deweloperski może zmieniać swój Backlog Sprintu w trakcie Sprintu. Vs zmiany product ownera

 

Nazwa M.I.T. w tytule jest jedynie trickiem marketingowym nie mającym nic wspólnego  zesłynną politechniką Massachusetts Institute of Technology.