Do czytania

  1. Zaczynamy tegomiesięczną Ścianę Tekstu od dosyć inżynierskich tematów, aczkolwiek ciekawych dla świata produktowego, czy zwinności. Tutaj ciekawy pomysł z rotacyjną rolą Support Hero, a więc developera, który spędza czas “na słuchawce”. ⏩️ http://newsletter.posthog.com/p/doing-support-makes-you-a-better

  2. Jak przekonać PO na poświęcenie czasu w delivery, na spłacanie długu technicznego. ⏩️ http://newsletter.eng-leadership.com/p/engineers-guide-to-convincing-your

  3. Spike, to potrzebne narzędzie w repertuarze każdego zespołu produktowego, jednak może sprawić wiele problemów zespołowi, jeśli przyzwyczaimy się do jego stosowania nazbyt często. ⏩️ http://mdalmijn.com/p/6-common-mistakes-when-using-spikes

  4. Zależności to jedna z najbardziej upierdliwych cech każdej rozwijającej się organizacji. Jak sobie z nimi radzić i unikać. ⏩ https://www.thoughtworks.com/insights/articles/how-to-tame-evil-dependencies

  5. Przeważnie nie jestem przekonany przez listy obowiązków i zadań, jakiejś roli, ale ta prezentuje się całkiem nieźle. Zastanawiacie się nad objęciem roli Product Managera? Polecam. ⏩ https://www.prodpad.com/blog/product-manager-tasks/

  6. Ah, klasyka. Opisz różne rzeczy nie mające związku ze Scrumem, czy Kanbanem, podaj przykłady jakiś patologii organizacyjnych i zwal winę na frameworki. Uwielbiam. 🍋 https://levelup.gitconnected.com/beyond-agile-and-scrum-great-leadership-matters-more-than-methodology-89e1c36129a9

  7. Choć analogia do mapy i terytorium jest dla mnie nieco miękka, to materiał ukazuje dobre rady, aby zwiększyć koncentrację na aspektach technicznych produktu i przez to na zadowolnyn kliencie. ⏩ https://maruz.medium.com/the-map-is-not-the-territory-6b8bb6d86973

  8. Case study przygotowane przez Botify, w którym firma dokumentuje swoją podróż ku tercetom produktowym w zespołach - bardzo dobre podejście, które z autopsji mogę polecić. ⏩️ http://producttalk.org/2024/09/botify-product-trios

  9. Przeważnie w sprawie Discovery rozmawiamy o samym procesie, którego podmiotem są już gotowe idee, ale ten proces powinien mieć również strategię. ⏩️ http://romanpichler.com/blog/product-strategy-discovery

  10. Hierarchie i szczeble zarządzania to codzienność w większości organizacji. Niemalże podstawa ich funkcjonowania. A przecież można pracować inaczej. ⏩️ http://corporate-rebels.com/blog/hierarchy-in-teams-why-it-often-does-more-harm-than-good

  11. Bardzo trafne spostrzeżenia dotyczące problemów, jakie przeważnie inżynierowie mają ze Scrumem, a raczej, z jego implementacją w swoich zespołach. Takie, How-NOTto. ⏩ https://ageling.substack.com/p/9-practices-that-haunt-developers

  12. Wszyscy mówią o bezpieczeństwie psychologicznym, ale źle to rozumieją. W tym materiale znajduje się kilka przykładów praktyk, które są podpinane pod psychological safety, a tak naprawdę są strzałem w kolano. ⏩ https://gustavorazzetti.substack.com/p/5-myths-about-psychological-safety

  13. Prawda. Nieprawda. Gówno prawda. Oto przewodnik po trzydziestu kategoriach “pierdo&^%$#” w miejscu pracy (i nie tylko). ⏩️ http://everythingisbullshit.blog/p/30-useful-concepts-about-bullshit

  14. Dawno nie czytałem czegoś o modelu Kano, więc fajnie, że w tym miesiącu się udało. Nie jest to poradnik krok po kroku, ale posiada cenne wskazówki, które pomogą przeprowadzić ten feedback i wyciągnąć z niego najwięcej. ⏩️ http://productify.substack.com/p/your-guide-to-kano-model-for-feature

  15. Ostatnio miałem problem z refinementami w zespole, więc szukałem źródeł cennych wskazówek do prowadzenia backlogu i refi. Tutaj mniej o refinementach, ale wciaż dużo dobrego od Stefana Wolpersa. ⏩️ http://scrum.org/resources/blog/27-product-backlog-and-refinement-anti-patterns

  16. Bardzo podoba mi się to podejście. Wcześniej używałem jego odpowiednika, który nam wpojona, a więc, aby oczekiwać od członków zespołu przychodzenia TYLKO z rozwiązaniami, ale podejście opisane w materiale, znacznie bardziej oddaje moje rozumienie roli lidera. ⏩️ http://antmurphy.me/newsletter/great-leaders-think-bring-problems-lets-find-a-solution-together

  17. Uwielbiam takie artykuły: coś jest złe, więc tutaj macie lepsze rozwiązanie - szkoda tylko, że to lepsze rozwiązanie jest kilkukrotnie bardziej skomplikowane niż to wcześniej. Mimo wszystko, proponowane podejście do mierzenia satysfakcji klienta z produktu jest dobre, więc przeczytać warto. ⏩️ http://productify.substack.com/p/net-promoter-score-is-a-scam-heres

  18. Bardzo doceniam, że kolega Martin Dalmijn połączył tematykę gier z pracą nad produktem software’owym, ale ten cytat jest już nieaktualny w dzisiejszych czasach. Gdyby w momencie jego wypowiedzenia Miyamoto miał świadomość aktualizacji, patchów i poprawek, prawdopodobnie by go nie wypowiedział. ⏩️ http://mdalmijn.com/p/why-estimates-and-timelines-are-the-biggest-enemy-to-delivering-value

  19. Miesiąc zakończymy cytrynką, w której pan developer zrzuca wszystkie grzechy organizacji na Scrum i nigdy nie słyszał o słowie ‘refinement’ - co zdecydowanie może być winą Scrum Mastera w jego teamie. ⏩️ http://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-out

Do oglądania | słuchania

  1. Przyjemny wykład na temat budowania zwinnej kultury w organizacji, bezpieczeństwa psychologicznego, ale również dostarczania i osiągnięcia wartości produktu. O typach osobowości i zależnościach. ⏩ https://youtu.be/gn3HTkX3LY8?si=sjOd5C9UxWLFQgIZ

Heheszek

alt_text