#priwlearning Serving in Agile Teams
#pluralsight by Jon La Plante
Note before read: เป็นการสรุปการเรียนคร่าวๆ แบบ TH ปน EN เนื่องจากเรียนเป็น EN จด EN และบางทีก็คิดคำไทยไม่ออก
ในโลกนี้มี Agile framework ประมาณ 50 อันได้ แต่ที่เด่นๆ ก็คงไม่พ้น Scrum, Kanban และถ้า Large scale หน่อยก็จะมี SAFe, LeSS, Nexus แต่คอร์สนี้เน้นเรื่อง Scrum เป็นหลัก เหมือนมาทบทวนความรู้สิ่งที่เคยเรียนมา และได้ Tips บางอย่างมาเพิ่ม
Link ที่เกี่ยวข้องที่เคยเขียนมาก่อนหน้า
- [Knowledge Sharing] Scrum Refreshment by Coach Num
- D-Class: Retrospective | Not just for Agile teams! by Coach Num
- [Knowledge Sharing] Kanban vs Lean vs Agile by Coach Num
สิ่งที่ Scrum master ต้องทำ
ขึ้นชื่อว่าเป็น Scrum master แล้วก็คือต้องช่วยให้ทีม deliver งานให้ได้ แถมยังต้องเป็น agile coach ได้ด้วย
- ensure ว่า team dynamic ยังดีอยู่
- สร้าง team environment ให้มีประสิทธิภาพ
- กำจัดอุปสรรค สิ่งกีดขวางต่างๆ
- สร้างความสัมพันธ์ที่ดีทั้งในทีมเอง กับ PO แล้วก็คนข้างนอกด้วย
- facilitate Scrum ceremonies
- provide tools ที่สร้าง value ทำให้มันใช้งานได้อย่างมีประสิทธิภาพ ทำเองไม่เป็นก็หาคนช่วยได้ แต่ต้องทำให้มันมีใช้อย่างดี
- สามารถให้ข้อมูลเกี่ยวกับ team performance ได้ เช่น burndown chart, team velocity (sum of a story point in a sprint)
Servant Leadership
- focus ที่ความต้องการของทีมมากกว่าตัวเอง คิดถึงตัวเองท้ายสุด
- honesty, personal vulnerability, respect, speaking the truth, openness
- strong relationship
- feeling personal achievement
- higher overall work satisfaction
- find the best way to apply agility to generate an outcome
Scrum — Way of Working
- ความต้องการที่จะทำงานออกมาให้ดีที่สุด
- focus ที่ปัญหาเดียว
- experiment (POC)
- respect the Boy Scout rule
- เชื่อมั่นและเชื่อใจกันและกัน
- กล้าที่จะแชร์ประสบการณ์
- วิจารณ์กันที่ไอเดีย ไม่ใช่ตัวบุคคล
- แม้จะทำงานกันอย่างจริงจัง ก็ต้องมีความสนุกในการทำงานด้วย
Product Backlogs
- reflects the planned business value
- highly technical work
- highly level user-focused items = user stories
- every task becomes one card
- avoid backlog zombies — keep fresh and active
- focus on outcome
- assumes change / prioritize
- smaller decks to focus work = task
- Epics = container of multiple user stories, multiple sprints
- User stories start with a business value statement
As a <role>, I want to <action>, so that <benefit>
OR
When <situation>, I want to <motivation>, so I can <expected outcome>
Backlog refinement
เพื่อให้ทีมดูว่า backlogs พวกนี้เป็น stories ที่ ready to start สร้างความเข้าใจอย่างลึกซึ้ง ได้ input estimation
- สิ่งที่เอาไป estimate points ได้ควรจะเป็น user stories ที่ validate แล้ว แตกเป็น task แล้ว รวมถึง technical tasks ด้วย
- การ estimate เป็นการ compare ของ another piece of work ที่นิยมใช้ก็คือ planning pokers, t-shirt sizing หรือ affinity estimations
- ตัวเลขที่มากหรือไซส์เสื้อที่ใหญ่ไม่ได้ based on time แต่ based on Complexity, Value, Risk
Definition of Ready
- outline best practices (not hard, fast rules)
- prevent concurrent work
- enough detail
- INVEST model for user stories: independent, negotiable, valuable, estimable, small, testable
Definition of Done
- all acceptance criteria are met
- code peer review
- testing (all) completed
- associated documentation
Definition of acceptance criteria
- independent testable
- provide PASS/FAIL result
- test the result not a solution
- written before work on
- GIVEN-WHEN-THEN
Sprint Backlog
- สิ่งที่ทำไม่เสร็จใน sprint ที่แล้ว จะถูก move ไปยัง sprint หน้า หรือโดนโยนกลับไปใน backlog ก็ได้ ห้าม auto move งานที่ไม่เสร็จไปทำ sprint หน้าทันที คือต้องมีการ planning กันก่อน
- เมื่อการเสร็จสิ้นการแพลนแล้ว New sprint Locked! จะไม่มี item ไหนสามารถเอาเข้าหรือเอาออกได้ ถ้าไม่ได้รับการยอมรับจาก Full team
Scope of Change Request
- การ Change นี้ให้ Business Value อะไร
- มัน Impact ยังไงกับ Product backlog, Strategy, Vision
- ทำไมมันถึงต้องเสร็จ ตอนนี้
- ทำไมมันถึงต้องทำให้เสร็จ ด้วยทีมนี้
ถ้าคำตอบทั้งหมดคือ Yes แบบมีเหตุผล ก็ต้องมีการต่อรองกัน เอางานที่สำคัญน้อยกว่าออก เพื่อมา support new request นี้
Sprint Review
- เป็นการ demo ว่าเราทำอะไรเสร็จ ด้วยทีม product กับ stakeholder ที่เกี่ยวข้อง
- มันคือการ discussion เพื่อ get feedback ไม่ใช่ request for approval และไม่ใช่ phase gate ด้วย
- ถ้าเป็นไปได้ ควรเชิญ end user มาให้ feedback การ demo ครั้งนี้
- เมื่อได้ผลลัพธ์เราก็เอาไปทำการ inspect and adapt ต่อได้
Sprint Retrospective
- ดู performance เพื่อจะได้ optimize and improvement
- share feedback and insight
- recognition of win and success, building team morale
- encourage accountability
Time: Learning ~2hrs, Blogging ~1hr
