Experience Report From Walmart

1. Experience Report From Walmart Author : BhavinKamani(Gembatech) AbinavMunshi(Walmart) 31-Dec-2013 報告人 : 林志信 (資工三 100502058)

2. .Outline • Background 背景簡介 • Problem & Learnings 遇到的問題與學習處理 • Conclusion 從過程中反思

3. .Background: • 在一個龐大的電子商務平台上遇到的挑戰 • 現有的系統升級 • 如何”無痛式”地增加新的功能 • 遭遇的問題切割成各個獨立問題 • 舊有的演算法整合進新的系統

4. ❶Problem: • During the beginning of our journey, our dilemma was where do we start, how do we knowif things are working and how do we align everyone on the teams to have the same goal. How do we present information that is real time, easy to understand, available and actionable? • 重點: 整個行程從何處開始、如何了解和如何組織？資訊要該如何呈現？

6. ❶Learnings: • Visualization : A good inception point for achieving agility • Know what is happening • Let the visualization evolve • Separate signals from noise • 重點: 了解目前的行程、把逐步發展視覺化和屏除干擾

7. ❷Problem: • As we began, we quickly realized after few iterations that to achieve agile delivery, we needed a well decomposed product backlog. We needed finer acceptance criteriasthat were well aligned with both business priorities and architectural feasibility. Who will be most suited to take care of this requirement : • 重點: 要拆開backlog, 而且找到一套標準來規劃優先權和架構上的可行性, 誰最適合這份工作?

8. ❷Learnings: • Answer : all of the above – it is collaborative • Product Manager/Domain expert -- get the big picture, market alignment. Help the team to establish a delivery rhythm by prioritizing requirements • Functional/System architect -- contribute by vertically slicing into time-boxed deliverable workflows while aligning with the architecture • Engineering team -- bring value by detailing the acceptance criteria and questioning the value that each slice brings. • In order to build a workable product backlog the whole team has to contribute. • 重點: 團隊中每個人都要互相溝通合作, 提供貢獻

9. ❸Problem: • One of the key challenge that we were facing in a large program, such as this, is to ensure that teams are executingindependently and at the same time are aligned to the cross-functional use cases. Furthermore, existing business had to go on and we wanted incremental upgrades to our programs, which directed us to have an appropriate release plan supported by the right architecture. • 重點: 面對龐大的程式, 團隊要同時獨立運作且使用跨功能的case, 並在持續運作的程式上加新功能, 所以需要一個完善的配套措施

10. ❸Learnings: • Organizing Release Management was an important learning for us: • We divided the system functionally to enable individual teams to stay autonomous for their releases. • The architecture choice of using a Service Oriented architecture with ESB provided the necessary framework. • This strategy helped us run multiple programs (both new as well as old) with their respective delivery cycle while still retaining the alignment required for a holistic user experience. • 重點: 我們把系統切割給團隊並賦予自治權自我管理,架構要使用服務導向, 尊重各個delivery cycle但仍然要保持整體使用者感覺

11. ❹Problem: • Having multiple autonomous teams brought agility at project level. It created a web ofdependencies at program level. The situation challenged us with maintaining program levelalignment around usecases, user experience, technology, tools, etc. It was critical for theprogram to establish certainstandards and synergy across teams while maintaining theirautonomy. • 重點: 在專案中各自有自治權帶來了Agility, 卻也挑戰了維護程式這項工作, 建立可靠的標準和團隊的合作是極大關鍵

12. ❹Learnings: • Building continuous communication channels via: • A working agreement between various stakeholders is formed to thrash out modus operandi. This has been huge success in establishing understanding between dependent teams. • Bringing“away” user story as a concept to track and manage inter team dependencies. • Tools, technologies, QA methodologies agreement within and outside the team. • 重點: 在多人共同協議推敲出工作方法, 在不同的團隊裡都適用的, 用user story 的觀念管理組織

13. ❺Problem: • After making initial progress, we realized that definition-by-book templates for processes did not yield the desired results. Certain practices such as planning meetings and story points worked well for some and did not work well for others. We could either stick with a process by the book or introspect the process itself. • 重點: 原先的模型並不太滿足需求, 特定的方式對於某個部分表現得很好, 但某些方面表現的卻不好, 我們不是堅持就是反省

14. ❺Learning: • Process Retrospection: • Retrospectives were good platforms to listen to the voice of the team. For example, some of the key improvement that came out team retrospectives were: WIP bottlenecks QA, UI resources. Focus on finishing stories rather than completing task. • Experiment with process changes. Preponingacceptance test case creation before start of development Establishing early integration with related projects • 重點: 回顧反省是一個很好的傾聽平台, 有很多關鍵的改變都來自那裡,在開始發展時提前規畫好測試案例

15. ❻Problem: • We observed that estimation planning and tracking was sucking a large chunk of teamenergy. We,therefore,introduced story points and started observing velocity variance and other keymetrics. • 重點: 觀察到計畫和追蹤project是很耗團隊的能量的, 因此特別導入story points的方式, 觀察整個團隊的工作速率提升

16. ❻Learning: • As we went from absolute to relative measurement, planning and tracking overheads reduceddramatically. • Story decomposition was the key to do a better job at estimation. Estimation became a communication tool to normalize and refine stories • Team commitment was more important than hitting estimation numbers. • 重點: 過度的計畫和追蹤大幅度的減少了, 預測成了一個溝通的工具, 而且團隊會議是比達到預期更來的重要.

17. ❼Problem: • The journey of adapting agile practices is a huge culture change for any organization. Asan organization, we wanted to establish a continuous improvement mindset that helps theteam/people identify improvement areas and experiment with solutions • 重點: 在調整Agile的過程對任何一個組織而言都是高度文化的改變, 我們想要建立一個不斷地進步的思維來幫助整個團隊發現改進的地方和處理方法的實驗

18. ❼Learning: • Listen by getting outside-in perspective - Coaches, experts • Bringing in industry experts such as Jez Humble, Henrik Kniberg, Naresh Jain to share their experience. • Actively seek different perspectives • Hiring external agile consultants to push start agile practices by providing real-time coaching to teams. • Conduct workshops on story slicing, agile practices, iteration management etc. • 重點: 藉由聆聽外面世界的聲音和可以洞察事情的教練和專家, 不斷的進步

19. .Conclusion: • 結論: 在沃瑪特的工作團隊中實行Agile Method來建立持續整合的能力, 把看這件事情的視野放大, 就會發現這整個程式是需要從最基礎的地方開始改善, 例如: project, teams, processes, technology and tools, 而且AgileMethod的關係幫助我們把不同的領域拆開來, 並給予各自需求的實作方式, 同時我們仍要秉持著維護整體的一致性,特別強調他們彼此之間的關連, 終究給使用者一個整體的感覺.