Moglibyśmy napisać cały cykl tekstów o wymówkach, które rzekomo mają uzasadniać dlaczego coś robimy źle. „U nas się nie da” i „zawsze tak robiliśmy” są zdecydowanie na szczycie tej listy.
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
Czym jest zespół? Grupą ludzi – to oczywisty warunek. Ale nie każdy zbiór osób będziemy mogli nazwać zespołem. Potrzebne jest coś, co spaja wszystkich. Będzie tym jeden, wspólny cel. Zespół musi mieć powód swojego istnienia, a bez niego napotkamy na wiele dobrze znanych problemów.
Wiele dyskusji prowadzonych przez nas na warsztatach i szkoleniach kręci się wokół „problemów agile’a”. Bo nagle okazuje się, że wymagania się zmieniają, że zakres się poszerza albo że próbujemy zabrać się za coś, co tak naprawdę nie wiemy jak zrobić. Tylko czy to rzeczywiście jest problem zwinności?
Zwinność i „bycie agile” wywodzą się z IT. Najszybciej za tą modą zaczęły podążać zespoły wytwórcze, które dostarczają skomplikowane rozwiązania, czyli oprogramowanie. Reszta świata nie zawsze nadąża za postępem w informatyce, nawet jeżeli chodzi o tak nietechniczne rzeczy jak zwinne metodyki.
Proxy Product Owner to rola, która nie występuje w czystym Scrumie. Jest to jednak jedna z bardziej popularnych modyfikacji tej metodyki. Proxy Product Owner często znajduje się w jednym worku razem z takimi tworami jaki Area Product Owner czy Tribe Leader.
Jaki Product Owner jest, każdy widzi. Czasami PO jednak zapomina o swoim zakresie odpowiedzialności i zmienia się w pośrednika pomiędzy zespołami, a klientem. Brakuje wizji, wartości, a czasami nawet dostępności. Tak nie powinno być, dlatego dziś – 3 Grzechy Product Ownera.
Deweloper w Scrum to źródło nieporozumień. Tym bardziej ma to miejsce na polskim rynku, gdzie bardzo często bywa utożsamiany z programistą. Tak jednak nie jest!
Jak pokazać, że agile „nie działa”? Najłatwiej jest ograniczyć całą zwinność do jednego pilotażowego procesu, zespołu lub komórki organizacyjnej. Nawet jeśli pozwolimy im na wszystko, to i tak możemy na koniec pokazać, że nic się nie zmieniło. Bo przecież nie miało prawa.
W marcu zeszłego roku większość zegarów w europejskich mikrofalówkach miało sześć minut opóźnienia. To nie tylko ciekawostka, ale także świetny przykład na to, jakie konsekwencje mogą mieć działania w systemie, który jest zbyt duży i zbyt skomplikowany.
Ostatnio dużo dyskutujemy o wartości i o tym, w jaki sposób najlepiej pomóc naszemu klientowi. Co jednak zrobić w sytuacji, w której trafiło do nas wymaganie, które nie tylko zawiera błędne założenia, ale wręcz wiemy, że jego realizacja zaszkodzi naszemu odbiorcy? Co zrobić, gdy klient się myli?
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]