HowAgile

01/09/2022

推薦 ‧NET Walker 大內行者 的分享！

很喜歡裡面從原則直接連貫到務實作法的敘述，討論到（軟體）工程實踐、引導、和能力！

「沒有技術能力支撐的開發團隊，就如同沒有體力支撐的球隊」

40分鐘的議程長度，能談論的主題不多。但一年就這麼一次，所以難免會想塞很多東西進去。但每個議題，都只能帶入一些些概念。不過，剩下的細節，在網上其實都可以找到線索。

底下連結整理了昨天在 Agile Summit 2022 我的場次60分鐘裡面，自己覺得比較精彩的部分。如果你沒來現場，當然會少了一些內容(例如不該劇透的魔術表演)，但剩下的那些，我想也夠有趣的了。

最近幾年，上台分享只求開心，其餘就不太在意了...
https://hackmd.io//rJM2NAByj

16/06/2022

你的 Scrum 團隊是否在跑 ？還是只是跑 Scrum 的流程？
⋯⋯
這文章內提到了 Professional Scrum 團隊需要的「價值觀、成長型思維模式、結果導向、持續學習、與道德行為」
http://ow.ly/kMGg50JwzBU
⋯⋯

Are you practicing , or are you just going through the motions and only holding Scrum Events? Learn more about Professional Scrum here: http://ow.ly/kMGg50JwzBU

06/03/2022

你聽過 Spotify 組織內績效的考量嗎？在 2016 年，負責 Spotify 美國與瑞典工程部門的 Kevin Goldsmith 發表了他們組織的設計，提到了個人成長與在組織中的影響力。

您現在身在的組織是如何打考績的呢？你對團隊績效有興趣或想分享想法嗎？
歡迎在明天 3/8 一同來線上聊聊！
🍻 一起喝一杯，聊聊績效相關的議題
https://www.facebook.com/events/335055995214005

🍀 https://notes.howagile.org/blog/spotify-technology-career-steps/

「許多人聽過 Spotify suad 團隊，但你看過當時組織內部的升遷設計嗎？當時的績效考量的點為何呢？」

05/03/2022

3/8 星期二就要到了！你過去這一個月還好嗎？
過去這個月發生了太多事情了。。。
讓自己放鬆一下，星期二一起來線上喝一杯，聊聊聽到經歷過的績效相關的議題吧！

🍻 https://www.facebook.com/events/335055995214005

03/03/2022

今天突然發現，我也時常不經意的把敏捷性(agile) 打成了大寫，造成容易誤導他人以為 「敏捷性 agile」是一個可以買到的商品。未來將會改進。

agile 在英文中是形容詞；
『敏捷』在中文中是「反應迅速快捷」的意思

在 2001 年，Dave Thomas 一同寫下了 “Manifesto for Agile Software Development"
在 2015 年，Dave Thomas 說， 大寫 'A' 的敏捷這詞已經變成了一個產業，並與當初的初衷愈來愈遠了。並造成了嚴重的狀況。。。（詳情請看影片）

🎥. 影片：https://youtu.be/a-BOSpxYJ9M?t=1266

2015 年，Dave Thomas 一語驚人的提出當把「敏捷性」（agile）當一個名詞/商品賣錢。。。就離當初的初衷愈來越遠了。。。

02/03/2022

上星期在 敏捷專家學會 的活動，在交流中討論到每個人在不同組織與團隊中經歷到的考績歷程，話題甚至談到曾經看到的不成文規定。。。🙊
你的團隊現在是如何量測績效的呢？有沒有想要一起討論的績效相關話題？

🍀歡迎下星期二來線上交流活動，一起分享經歷和擴充不同角度的視野！

🍺 https://www.facebook.com/events/335055995214005/

團隊在敏捷轉型 (Agile Transformation) 中需要突破的挑戰除了關於交付有價值的產品，還有如何與組織中各個的部門一同合作，尋找出增加效能的合作方式。

13/01/2022

《如何敏捷》您所處的團隊是否有導入系統化的流程，定期開放性的邀請團員討論改善的機會？

朋友A 分享說感覺身處的團體裡大家的焦點是頭銜與各自行事的流程，抱怨這與他期待的團隊環境有所落差，雖然有這感受，但他卻苦無對團隊提出討論的機會 ── 因為團隊沒有固定時間邀請每個人討論回顧，他與熟識的同事也不敢找長官討論。。。

我也有聽過朋友 B 的故事，雖然她的團隊的經理在一開始建立團隊時有指派任務，但經理有特別註明之後的工作分配，交給團隊自己決定。團隊也因為彼此熟識，很有默契的重新分工合作，共同分擔成敗。

在您所處的團體裡，是否每個人可以很容易的發表建議，甚至各自可以主動推動改善？還是您的團體需要每個人各自先找到勇氣、擠出時間、擬定提議計畫之後才有討論的機會？

哪一個做法可以增加個人的參與感與為組織提供貢獻？
哪一個作法可能會造成個人參與感與貢獻低落？

在 Scrum 中，Sprint 回顧會議 (Sprint Retrospective) 是系統化開放式邀請團員討論的做法，製造討論的機會！

如果你有興趣學習 Scrum 框架、願意一起分享經驗與參與討論，歡迎參加我們在 二月21～11 的 Professional Scrum Master 課程。
⚡️ https://www.scrum.org/courses/professional-scrum-master-2022-02-21-55286

「團隊」是指一種為了實現共同的目標，由而彼此依賴與互相協調和合作所組成的團體──團隊成員共同負擔團隊的成敗責任。

12/01/2022

今天 LINE 上面的疾管家持續報導者 COVID-19 在台灣境外與境內感染情況，似乎 Omicron 變種病毒來勢洶洶。許多聚會都再次取消，並提醒每個人保持社交距離，希望大家能都平安健康！

HowAgile 敏捷/Scrum 札記、專案管理、產品開發、隨性閱讀等閱讀筆記

12/01/2022

《如何敏捷》與兩個朋友聊到他們團隊，發現雖然都稱自己為 Scrum 團隊，並使用了共同的「估點數」工具，但似乎兩個團隊著重的點不一樣。。。你覺得兩個團隊A、B 各自著重在那裡？

情況一：
朋友 A 的團隊來了一個新同事，提出了「Scrum 團隊應該要估算 Story Points！」的建議。朋友 A 覺得當整個團隊一起估算 Story Points，增加了討論與釐清認知的機會，的確對擬定工作計畫和提升團隊知識有幫助。

情況二：
朋友 B 的團隊也使用 Story Points 做估算。但因每個團員都負責各自專業的工作事項，他們團隊的流程是在 Sprint Planning 的時候每個人稟報自己工作的點數，之後會在 Sprint Review 上一同回顧做了多少點數，和還剩下多少點工作點數。朋友 B 覺得這流程能給予清楚的進度資訊，雖然希望團隊能夠做更多。。。

朋友 A 的團隊發現使用這個工具，可以促進隊員發表見解與學習，著重的是合作。
朋友 B 的團隊發現可以由每個人報告做事的進度，可以收集到進度報告，著重的是需要進度與時間的控管。

或許他們都有各自的理由與情況，不過當團隊能夠釐清 Scrum 的規則，明白行為背後的「好處」與「代價」，或許能夠增加他們察覺更有效交付價值的方法。

如果你有興趣投資自己與團隊、願意一起分享經驗與參與討論，歡迎參加我們在 二月21～11 的 Professional Scrum Master 課程。

⚡️ https://www.scrum.org/courses/professional-scrum-master-2022-02-21-55286

圖片來源：Chee Hong Hsia 的 《Don't confuse Scrum with "An Implementation of Scrum“》文章

「Scrum 框架」與實踐 Scrum 的「方法」是不同的事情，猶如「圍棋規則」雖然簡潔易懂，但「玩法」卻千變萬化。