我在半年前〈以談判角度看 Sprint Planning〉一文曾提過：

只要是我有權主導的 Sprint Planning，都會先花些時間請 PO 重新展開 Impact Mapping 及 Scaling Lean 的內容，尤其是還沒有穩定扎實 Product Backlog Refinement 的團隊。

前同事 Peter Su 提出他在荷蘭工作的觀察：

貼文短短，卻已提到幾則重點：

• 準則
• 思考框架
• 句型
• 參考範例

儘管自己還沒有在國外工作過，但成天浸潤在外文書籍，也感同身受。

自從去年在〈有了 Agile，為什麼還要有 DevOps？〉及〈從限制理論看 DevOps〉兩場演講中，分別以 lean thinking 及 theory of constraints (TOC) 兩個角度探討 DevOps 之後，心中一直有個願望：想再從「系統思考」角度探討 DevOps。

湯姆・漢克與梅格・萊恩主演的《電子情書》中，有一段台詞：

Do you ever feel you’ve become the worst version of yourself? That a Pandora’s box of all the secret, hateful parts - your arrogance, your spite, your condescension - has sprung open? Someone upsets you and instead of smiling and moving on, you zing them. “Hello, it’s Mr Nasty.” I’m sure you have no idea what I’m talking about.

思考框架

我自認是個思考框架控。

學生時代只是不自覺就這麼做了。但後來被勝間和代《新・知識生產術》洗腦，我就開始下意識蒐集並應用。

過度依賴既定框架是不好的 ¹，但是，看到連鼓吹思考框架甚力的勝間和代也曾有此疑問，且給出一份建議，我就放心了。她在《培養商業腦的７種組織力》書中是這麼說的：

另一位我很崇拜的憲哥（謝文憲），在書籍中也一再重申：