Myślę, że inni już udzielili dobrych odpowiedzi, ale dodam moją tylko dlatego, że myślę, że twoja drużyna właśnie przeniosła się do Scrum, a teraz jesteście w bardzo podobnej sytuacji, kiedy byliśmy na początku.
Po pierwsze, nasze wprowadzenie do Agile, a dokładniej Scrum nie było bardzo płynne. Zasadniczo zarząd upadł i powiedział: od tego dnia będziesz robił Scrum i jest to proces, którego wszyscy będziecie przestrzegać. Tyle o ludziach ponad procesem .
Proces, który pierwotnie przeprowadziliśmy (ślepo, mogę dodać) skończył bardzo podobnie do tego, jak opisałeś. Ludzie otrzymują przydzielone zadania, wszyscy zostają zarezerwowani, wszyscy wracamy do biur i podłączamy się. Codziennie mamy nudne spotkanie stand-up.
Kluczem do zrozumienia jest to, że Agile, w tym Scrum, dotyczy ludzi. Kiedy zespół rozpoczyna planowanie iteracji, nie pozwól swojemu Scrumowi mistrzowi (który prawdopodobnie jest twoim menadżerem) przypisać ci godziny, historie i zadania. To całkowicie zależy od zespołu. Myślę, że dla wielu ludzi jest to bardzo trudna koncepcja, ponieważ przez wiele lat wcześniej przychodzili do pracy i mieliby szefa (kierownika, kierownika technicznego ...), który po prostu zlecałby pracę. Nurkują w Scrumie, ale wszyscy (w tym sam mistrz scrum) nadal działają w tym samym trybie.
Pewnego dnia będziesz tego dość, więc zaczniesz czytać książki, blogi i zadawać podobne pytania na temat wymiany stosów. Uświadomisz sobie, że jako programista i członkowie zespołu powinniście być siłą napędową opowiadań i zadań. Jeśli uważasz, że skorzystasz z programowania w parach, z pewnością utwórz 2 zadania dla każdego inżyniera i przydziel im oba godziny. Jedyne, co powinien zrobić mistrz scrum, to zmierzyć prędkość w stosunku do ukończonych historii, które dostarczyłeś JAKO ZESPÓŁ w poprzedniej iteracji.
Kolejną rzeczą, która mnie denerwuje, jest to, że ludzie mówią, że ich pojemność ZAWSZE wynosi 75% całkowitej liczby godzin, więc to oni zobowiązują się, a następnie przez cały czas trwania iteracji skarżą się, że a) nie mogą pomóc lub b) nie mogą zrobić dobrze, ponieważ przydzielono im zbyt wiele godzin. Ludziom nie należy mówić, ile godzin zobowiązać, a na pewno powinni się wycofać, jeśli Scrum Master próbuje wyciągnąć coś takiego! Każdy powinien zobowiązać się do tego, co mu odpowiada. Na przykład jestem liderem zespołu i często kończę przypadkową nieplanowaną dyskusję na temat projektu lub pomagam komuś z kodem lub rozwiązuję dziwne rzeczy, więc moja pojemność nigdy nie przekracza 50%.
Naszemu zespołowi zajęło 4 cykle wydawnicze, aby nauczyć się nie robić rzeczy, o których właśnie wspomniałem, i mimo że zdecydowanie się poprawiliśmy, jeśli zapytasz ekspertów, nie jesteśmy nawet w połowie zwinni. Wciąż dużo się uczy.
Aktualizacja 1: Odpowiedź na komentarz Cliffa
Cóż, zaoferowałeś swoje uszy, więc oto ...
Masz rację, zmiana kulturowa jest kluczowa, ale ta zmiana nie musi nastąpić na poziomie wykonawczym. Twój własny menedżer grupy może zmienić kulturę w zespole i odizolować was od korporacyjnych BS, z którymi ma do czynienia. To, co opisujesz, to DOKŁADNIE nas od 2007 do 2010 roku. Nasz zespół (i inne zespoły) po premierze wydał flop. W jednym z wydań wykorzystującym „proces zwinności” kierownictwa udaje nam się, aby 9 osób wykonało pracę, która zwykle byłaby wykonywana przez jedną osobę, co zajęło nam dwa razy więcej czasu. Miałem tyle wolnego czasu, że nawet zaktualizowałem swoje CV.
Następnie rozmawiałem z moim szefem i wyjaśniłem mu wszystkie te rzeczy, jak zwinny jest człowiek i że jeśli chcesz, abyśmy dbali o produkt, pozwól nam podejmować decyzje, które wpływają na sposób, w jaki pracujemy i dostarczamy produkt. Myślę, że postanowił zrobić z tego eksperyment, wprowadził każdą zmianę, którą ... no cóż, głównie ja, ale dużo rozmawiam z resztą zespołu, stąd 50% pojemności :) ... zaproponowałem. Możliwe, że doszedł do wniosku, że jeśli dokona wszystkich zmian, o które prosimy, a my nadal ponosimy porażkę, wróci ze zwycięskim „Tak wam powiedziałem”.
W ciągu ostatnich 12 miesięcy wyeliminowaliśmy tak wiele „głupich”, że nawet nie jest to śmieszne. Nasze spotkania stand-up mają teraz sens, ponieważ pracujemy razem, a nie w izolacji. Nadal mamy (przynajmniej na razie) własność określonych części produktu, ale bardzo często przenosimy się do kodu innych użytkowników. Stale przeprowadzamy przeglądy kodu, aby nie tylko członkowie zespołu uczyli się innego kodu, ale także uczyli się lepszych technik kodowania i projektowania. Podzieliliśmy monolityczny, gigantyczny „zwinny” zespół na 3 różne zespoły, więc planowanie i inne spotkania są znacznie krótsze, a ludzie faktycznie się nimi przejmują, ponieważ nie siedzą i nie słuchają o rzeczach, na których im nie zależy. JA' widzieliśmy noce, kiedy 4 na 5 naszych facetów (jeden z zespołów) będzie online o 23:00 wieczorem i nikt tak naprawdę nie powiedział nam, że musimy ciężko pracować ani nigdy nie wywierali na nas presji, abyśmy pracowali ponad 40 godzin. Ludzie, którym pół roku temu to nie obchodziło, nagle są zaręczeni i podekscytowani pracą, którą wykonują. Wystarczyło, że nasz menedżer powiedział: „Wy decydujecie, co jest słuszne i robicie to, co musicie zrobić, a ja będę trzymać korporację BS z dala od zespołu, jak tylko mogę”.
Zaczęło się jako eksperyment (moje podejrzenie, nigdy mi tego nie powiedział), ale teraz nasza grupa kopie tyłek w porównaniu z innymi grupami programistycznymi w dziale, a nawet mamy innych programistów, którzy teraz próbują przyjść i dołączyć do nas.
Największą przeszkodą dla nas od czasu tej zmiany (i nadal stanowi problem) jest fakt, że inżynierowie w normalnym środowisku korporacyjnym są jak myszy eksperymentalne w klatce. Nawet jeśli Twój menedżer zdecyduje się naprawdę „zwinnie” i usunie klatkę, wszyscy są w niej od tak dawna, nawet nie zdają sobie sprawy, że są wolni. Więc nawet z całą swobodą nadal zachowują się, jakby nadal byli ograniczeni. Myślę, że pomogłoby to mieć w zespole co najmniej kilka osób (takich jak ty), którzy wychodzą poza granice grupy i szukają lepszych sposobów działania. Następnie wróć do tej grupy i trochę ją zamieszaj.
W twoim przypadku być może programowanie w parach nie jest rozwiązaniem, jeśli szukasz innej siły zewnętrznej, która zstąpiłaby na zespół i powiedziała mu, jak pracować. Zamiast tego wyrzuć zasady, usiądź z nimi bez zarządzania i zapytaj ich, co chcą zrobić? Co sprawi, że będą szczęśliwi? Produktywny? Zidentyfikuj największe problemy, a następnie zapytaj ZESPÓŁ, jakie według nich powinno być rozwiązanie.