Do czytania

  1. Kolejny materiał, który utwierdza mnie w przekonaniu, że osoby opowiadające się #noestimates, to skrzywdzeni ludzie słabym Scrumem, implementowanym na kolanie i z masą złych praktyk. ⏩ #NoEstimates and #NoIterations
  2. Ten materiał jest dla mnie taką bazą pod organizację zespołów i całej organizacji. Coś, od czego moim zdaniem należy zacząć, zaopiekować się w pierwszej kolejności. ⏩ Productivity and IT Organizations - Some questions answered
  3. Zawsze mnie intrygował model finansowy w zespole czy organizacji, w którym to zespół odpowiada za poziom wynagrodzenia. Moim zdaniem, to cholernie trudne, ponieważ uważam to za szczyt, jeśli chodzi samoorganizacje, ale nie niemożliwe. Chciałbym kiedyś współpracować z tak dojrzałym zespołem. ⏩ Using Team-Set Salaries for Company-Wide Compensation
  4. Coś dla śmiechu (i nie tylko). ⏩ My Favorite Product Management Memes
  5. Wskazówki i lekcje z mierzenia sukcesu produktu. ⏩ 21 Lessons In Measuring Innovation: Truth Is Often The First Casualty
  6. Ostatnio w pracy tłumaczyłem kro-funkcjonalność, więc podrzucam, bo może się przydać. ⏩ What Does Scrum Mean by Cross Functional Teams?
  7. Ciekawe, czy John Cutler wie, że dostarczył mi fantastycznie prostego wytłumaczenia Scruma? ⏩ Making Things Better (With Enabling Constraints and POPCORN)
  8. Bartek Michalski (tak, ten Bartek Michalski z DW) wraca do pisania w serwisie. Jak zwykle na świeczniku jest temat motywacji i wskazówki, że czasem dawanie jest odbieraniem, a nie każda nagroda motywuje. ⏩ Kto daje i odbiera ten się w piekle motywacji poniewiera
  9. Kolejny materiał od Johna Cutera, który przedstawia ciekawy model rzeczy, które zespół JEST W STANIE zrobić, kontra rzeczy, które POWINIEN zrobić. Zgadzam się z autorem, że dużo zespołów skupia się na tym, co jest w stanie zrobić wyłącznie i zapomina o tych, które powinien zrobić. ⏩ TBM 16/52: Can Do vs. Should Do
  10. Całkowicie się zgadzam. Jeśli chce wiedzieć, w co się pakuje jako team lead, to robię dwie rzeczy: analizuję strukturę organizacji oraz rozmawiam z zespołem. Tutaj jest wszystko. ⏩ Its the engineers, stupid – one from the heart
  11. Jak rozpocząć pracę z metrykami w zespole, czego się przestrzegać oraz o czym nie zapominać. ⏩ Team Metrics in Depth — Lean Agile Intelligence
  12. Dlaczego wprowadzenie story pointów jest stosunkowo łatwe, ale robi się z czasem trudniejsze do utrzymania w zespole? ⏩ Story Points: Why is this so hard?
  13. Czym jest bezpieczeństwo w miejscu pracy, w zespole, w organizacji i co nam daje - było wałkowane wiele razy, ale warto. ⏩ How Psychological Safety at Work Creates Effective Software Tech Teams that Learn and Grow
  14. Scrum Guide opisuje stan końcowy, wskazując jednocześnie wszystkie problemy, które zespół i organizacja posiada obecnie. Mało zatem skupia się na przestrzeni, pomiędzy co jest jednocześnie plusem, ale i problemem. ⏩ Mind The (Scrum) Gap!
  15. Zobowiązanie to termin, który jest jednym z bardziej uwypuklonych w ostatniej aktualizacji Scrum Guide’a - co dokładnie się za nim kryje, bo nie chodzi o dostarczenie wszystkich historyjek ze sprintu. ⏩ One of the most overlooked parts within the Scrum Framework - Commitments
  16. Czy mierzenie adopcji Agile w organizacji ma sens? ⏩ How to Measure Agile Maturity
  17. Ciekawa propozycja ćwiczenia dla zespołu pracującego nad produktem, którego celem jest poznanie kim są beneficjenci naszego produktu i rozwiązań, jakie dostarczamy. ⏩ Start A Stakeholder Treasure Hunt With Your Scrum Team
  18. Co nauka i fakty mówią o stabilnych zespołach vs zmiennych? Okazuje się, że nie za wiele. ⏩ In-Depth: Stable Or Fluid Teams? What Does The Science Say?
  19. Efekt Dunninga-Krugera to coś, co jest rzucane w rozmowach o uczeniu się, rozwoju juniorów, seniorów itd. Jednak okazuje się, że jest to najzwyklejszy bubel i kłamstwo. Polecam. ⏩ The Dunning-Kruger Effect is Autocorrelation – Economics from the Top Down
  20. System dostarcza tego, do czego został zaprojektowany. Tak proste zdanie, mające tak dużo do powiedzenia o tym, jak podchodzimy do planowania produktów. ⏩ Systems Produce As Designed

Do oglądania | słuchania

  1. Materiał, który jest reklamą kursu związane z Myśleniem Systemowym w połączeniu z Human Centric Desgin, więc „szczypta soli” przyda się przy słuchaniu, natomiast jest tu trochę ciekawych informacji o przykładach obu podejść w życiu codziennym. ⏩ How to Think in Systems for Greater Impact
  2. Jako lider zespołu czy ten Scrum Master powinienem rozwijać moją wiedzę, spoza zakresu zarządzania, procesów, Agile i innych przyjemnych tematów, dlatego sięgam od czasu do czasu po materiały dla developerów, jak poniższe wystąpienie Eberharda Wolfa o roli Software Architekta. ⏩ How to Become a Great Software Architect • Eberhard Wolff • GOTO 2019
  3. Inspirująca rozmowa na kanale Mob Mentality z Joe Justice, który od lat pracuje w Tesli, i wspólnie (jak się okazuje) z Elonem Muskiem stosuje mob dla rozwiązywania codziennych problemów oraz pracy ogólnie. ⏩ Mobbing at Tesla with Joe Justice
  4. Nie będę tego ukrywał: nieco się krzywię, gdy słyszę, jak ktoś mówi o sobie “full-stack developer” i płaczę nieco, gdy widzę całe organizacje opierające się na full stack developerach. Dave Farley dobrze opisuje problem z takim podejściem i wskazuje tę dobrą drogę.How To Be A Full Stack Developer In 2022
  5. W ramach mojej kwartalnej katy jednym z punktów na liście do przeczytania jest model Spotify, natomiast tym razem postanowiłem zobaczyć klasyki od Henrika Kniberga w formie wideo - pewnie widzieliście, ale lubię ich słuchać: Spotify Engineering Culture - Part 1 , Spotify Engineering Culture - Part 2
  6. Pozostajemy w Spotify jeszcze na chwilę i tym razem bardzo luźna rozmowa z Jason Yip, który był jednym z współtwórców tego, co szerzej rozumiemy jako Model Spotify, jako Agile Coach. ⏩ It’s hard to explain how salt tastes to someone who does not know salt.(Jason Yip Who Is agile 012)
  7. Daniel Vacanti oraz jego gość o tym, co jest sednem myślenia zwinnego - potwierdzanie jak bardzo byliśmy w błędzie, kontra potwierdzanie naszych racji. ⏩ Episode 44 Ex Ante vs Ex Post
  8. Kanał Continuous Deliver tym razem o istocie tworzenie ewolucyjnego produktu, architektury, rozwiązań. Coś, co jest sednem Agile. ⏩ How To Avoid Big Upfront Design

Heheszek