Wrong determination
People often think that persistence or not giving up will bring them to the success. However looking back to your past, how many times you tried, but did not get a good result? Your determination faced with many failures than successes or even just only failures? Did you ask yourself "Why" and "What is missing to be successful"? Let's talk about football. Does the football team want to win the cup or want to win all the matches? If you put your expectations on how to win every match, that’s more challenging and might be impossible. But if the goal to win a cup, it will give you a better chance and strategies like you do not need to win all the matches (by accepting the loss or draw in some matches). Or even have a long preparation to be the champion in the couple years rather than this year . Having persistence and determination is good but putting it on the right thing, and the right time is more important. The journey to reach the goal is a long journey. And you can have a lot of strategies to achieve it. Knowing how to inspect and adapt the plan or strategy to help you reach the goal; once you failed, you learn from it, change your plan, and continue. Hai ngày Face to Face với các đồng nghiệp Professional Scrum Trainers tại Delft là một trải nghiệm tuyệt vời mà tôi sẽ không bao giờ quên. Từ Việt Nam đáp chuyến bay cuối năm đến đất nước Hà Lan xa xôi, trong lòng không khỏi bồi hồi, vì tại Việt Nam thời điểm này là thời điểm nhà nhà đang chuẩn bị đón Tết Nguyên Đáng.
Trời Hà Lan những ngày này rất lạnh, nhiệt độ từ 0 đến 3 độ C. Với cái rét này khiến tôi nhớ Việt Nam và cái không khí Tết càng da diết hơn. Tuy nhiên, càm giác sắp được gặp những người bạn, đồng nghiệp và cùng chí hướng, khiến tôi nao nao hơn bao giờ hết. Dưới đây là những hình ảnh lưu giữ kỷ niệm cho chuyến đi này. Scrumviet xin giới thiệu đến các bạn một phương thức đơn giản và dễ dàng cho việc minh bạch về cảm xúc của các thành viên trong nhóm. Phương thức này có thể sử dụng cho nhiều mục đích khác nhau như: meetup, workshop, meeting.
Đây là bài đầu tiên trong loạt bài các cách thức tổ chức một buổi Retrospective, và trong bài đầu tiên, tôi xin giới thiệu đến các bạn một trong những cách mà tôi hay sử dụng nhất: Speed boat
Trong thời đại V.U.C.A, mọi thứ trở nên hỗn loạn, khó lường hơn. Nơi kiến thức của ngày hôm qua đã không còn đúng vào hôm nay nữa. Sự cạnh tranh trở nên ngày càng khốc liệt, và công nghệ đã góp phần lớn dẫn dắt sự thay đổi khó lường này. Bạn dễ tìm thấy ví dụ như một hãng Taxi truyền thống sẽ không thể ngờ được, miếng bánh thị phần sẽ rơi vào tay của một hãng Taxi công nghệ, mặc dù họ không cùng ngành nghề với nhau. (Grab và Uber)
Trong kỷ nguyên này đòi hỏi các doanh nghiệp phải thay đổi để trở nên linh hoạt hơn, họ không thể dùng mãi một công thức là kinh nghiệm để chiến thắng hay nắm phần thắng trong tương lai nữa. Mà họ cần một phương thức mới, giúp họ có thể nhanh chóng ra quyết định và thay đổi theo nhu cầu của thị trường một cách nhanh nhất, và Agile là chìa khoá. Nhưng làm thế nào để thay đổi?
"The journey is never ending. There's always gonna be growth, improvement, adversity; you just gotta take it all in and do what's right, continue to grow, continue to live in the moment." - Antonio Brown
"Là những giá trị chưa được tìm ra, có thể có được trong tương lai nếu tổ chức có thể thoã mãn được nhu cầu của khách hàng tiềm năng." Mục tiêu chính của việc tập trung vào Unrealized Value là để giúp tổ chức có thể tối ưu hoá và đạt được những giá trị theo thời gian, những câu hỏi giúp tổ chức có thể xác định và đánh giá những giá trị mà mình chưa đạt được:
"Nhìn nhận ra được giá trị sản phẩm đang trên tay người dùng hiện tại" Mục tiêu chính của việc nhận thức rõ giá trị hiện tại của sản phẩm được đưa đến tay người dùng là để có thể giữ vững, gia tăng và củng cố những giá trị đã đạt được đó. Đây là những giá trị đã đạt được hiện tại không phải là giá trị sẽ có thể đạt được trong tương lai, và có thể được xác định bằng cách trả lời câu hỏi:
1. Khách hàng của bạn có hạnh phúc với sản phẩm hiện tại không? Họ đang cảm thấy ngày càng vui vẻ khi sử dụng sản phẩm hay đang cảm thấy đang suy giảm niềm vui khi sử dụng sản phẩm? 2. Nhân viên của bạn có hạnh phúc với công việc không? Niềm vui đó đang gia tăng hay suy giảm đi? 3. Nhà đầu tư và các bên liên quan thì thế nào? Họ có vui hay đang cảm thấy ngày càng khó chịu? Ability to Innovate là thể hiện khả năng của tổ chức phát triển sản phẩm có thể cung cấp giá trị mới đáp ứng nhu cầu của người dùng.
Mục tiêu của việc đo lường A2L là để xem xét khả năng tối ưu hoá việc có thể cung cấp được những giá trị mới đến người dùng thế nào, việc này có thể đo lường qua việc tập trung trả lời những câu hỏi như sau:
"Thể hiện khả năng của tổ chức trong việc nhanh nhạy như thế nào để cung cấp chức năng, sản phẩm hay dịch vụ mới" Mục tiêu trong việc xem xét Time-to-Market là để giảm đi thời gian cần thiết cho tổ chức cung cấp được giá trị sản phẩm đến tay người dùng. Nếu không được xem xét và quản lý, thì khó có thể đoán biết được trong tương lai khi nào sản phẩm đó hoàn thành và được sử dụng bởi khách hàng. Dưới đây là những câu hỏi gợi ý mà bạn nên quan tâm để liên tục đánh giá Time-to-Market:
Trong sự kiện Scrum Day Vietnam 2019, có rất nhiều bạn có mối quan tâm về việc, làm thế nào để thuyết phục được Top Manager hay Khách Hàng đồng ý sử dụng Scrum? Hôm nay tôi xin viết một bài blog về chủ đề này, để liệt kê những thách thức và những điều bạn có thể quan tâm đến khi muốn thành công trong việc thuyết phục Top Manager hay Customer của mình ủng hộ bạn sử dụng Scrum. Thách thức: Bạn hiểu rõ được thách thức hiện tại bao nhiêu, khả năng thành công của bạn sẽ càng cao bấy nhiêu Nexus Sprint Retrospective là một sự kiện diễn ra sau Nexus Sprint Review, và trước khi bắt đầu Sprint mới. Cũng như Sprint Retrospective trong Scrum, mục đích của Nexus Sprint Retrospective là nhìn lại sprint đã qua, trong đó Nexus team sẽ cùng nhau xem xét và điều chỉnh để cải tiến công việc của Nexus team trong tương lai.
Trong Nexus, Nexus Sprint Review sẽ thay thế cho Sprint Review của mỗi Scrum team, và được tổ chức tại cuối mỗi Sprint. Mục đích của Nexus Sprint Review là cơ hội để Nexus Team và Stakeholders có thể cùng nhau xem và thảo luận về kế hoạch tiếp theo cho sản phẩm qua Integrated Increment của Nexus team. Cũng như Scrum, đây không phải là Demo meeting. Trong Nexus, Output của Refinement sẽ là input của Nexus Sprint Planning, event này mục đích chính là giúp tối ưu hoá sự đồng bộ của tất cả Scrum Team trong cùng một Sprint.
Có ba điều chính cần phải được quan tâm trong Nexus Sprint Planning, đó là:
Vào ngày đầu tiên sau Sprint Planning, đại diện của team sẽ cùng nhau hợp lại để thực hiện Nexus Daily Scrum. Mục tiêu chính là thảo luận về những vấn đề ảnh hưởng, cản trở đến công việc giữa các Scrum team với nhau.
Việc ai là người sẽ tham dự Nexus Daily Scrum sẽ không có câu trả lời cố định, mà nó phụ thuộc vào nhu cầu thực tế của các Scrum team tại thời điểm đó. Đây không phải là một meeting của cấp cao để ra quyết định và giao việc cho những người khác, đây là meeting để tập trung thảo luận và xác định những vấn đề cần phải được giải quyết và Nexus Sprint Backlog được update hay quản lý cùng với event này. Nhắc lại rằng, Nexus Daily Scrum mục đích chính là transparent những vấn đề (tương tác, dẫm chân nhau, hay chính xác hơn là những vấn đề về công việc tích hợp) giữa các Scrum team, qua đó người sẽ giải quyết vấn đề không phải là Nexus Integration Team, mà là chính Scrum team (Dù cho NIT cũng là member của Scrum team). Scrum Day Vietnam 2019 đã diễn ra và thành công tốt đẹp! Sự kiện đánh dấu lần đầu tiên Scrum Day tại Việt Nam được Scrum.org và Scrumviet đồng tài trợ chính và tổ chức. Ngoài ra sự kiện còn được tài trợ truyền thông bởi Agile Alliance.
Hơn 140 người tham dự sự kiện với nhiều chia sẻ và hoạt động thú vị được diễn ra nguyên ngày, người tham dự đã thực sự thích thú và chia sẻ cùng nhau nhiều kiến thức về Scrum và Agile. Xin cảm ơn các đơn bị tài trợ và nhất là các Speakers đã dành thời gian và effort của mình để chia sẻ. Hi vọng sự kiện sẽ được ngày càng nhiều sự ủng hộ và sẽ tiếp tục diễn ra trong nhiều năm tới. Hẹn gặp lại mọi người tại Scrum Day Vietnam 2020! Scrum on! Integrated Increment là một trong những Artifact của Nexus framework. Việc nhiều Scrum team cùng làm việc trên một product sẽ làm cho độ phức tạp và giảm tính minh bạch của thông tin lên, nên dẫn đến việc các Scrum team dễ bị phụ thuộc và dẫm chân lên nhau. Chính vì lý do đó Nexus được tạo ra, và nếu Nexus chỉ có một mục tiêu duy nhất thì đó sẽ làm tạo ra được Integrated Increment vào cuối Sprint.
Có nhiều câu hỏi và mối quan tâm về việc quản lý rủi ro xoay quanh việc trao quyền cho Scrum Team như:
Làm thế nào để đảm bảo thành công cho Product nếu Product Owner không hiểu nhiều về Product hoặc chưa đủ kỹ năng? Làm sao Product Owner quyết định được Business Value nào sẽ là trong 20% mang lại 80% giá trị? (80/20 - Pareto Principle) Việc trao quyền cho Development Team dẫn đến nhiều rủi ro tiềm ẩn? Làm sao Development Team biết nên làm gì và làm thế nào để tạo ra Done Increment? Cross-team Refinement là một Event mới trong Nexus, mặc dù được đề cập trong Scrum Guide nhưng không phải là Event chính thức trong Scrum. Nhưng trong Nexus thì Cross-team Refinement là một event chính thức.
Cross-team Refinement được tổ chức với 2 lý do chính: 1. Dự đoán được nhóm nào sẽ làm việc với Product Backlog Item nào. 2. Và từ đó tạo sự minh bạch, và giúp các nhóm giảm thiểu sự phụ thuộc. Những ngày cuối tháng 9 thật tuyệt, vì Scrumviet lại có cơ hội được chia sẻ kiến thức cùng mọi người. Hai ngày qua là những trải nghiệm chia sẻ về Scrum, về nghề IT, Scrumviet cảm thấy có thật nhiều động lực và luôn mong muốn mình có thể làm tốt hơn nữa để mang những giá trị của Scrum đến với cộng đồng.
Xin chia sẻ cùng mọi người những hình ảnh của lớp học đã qua. Khi áp dụng Nexus ngoài Sprint Backlog của từng Scrum team, chúng ta còn có Nexus Sprint backlog. Nexus Sprint backlog là Backlog của Nexus Integartion Team, được quản lý bởi họ.
Nexus Sprint backlog không chứa tất cả những Sprint Backlog Item, mà chỉ chứa những Sprint Backlog Items nào bị phụ thuộc lẫn nhau giữa các Scrum team, và những mối quan tâm tiềm ẩn có thể tạo ra sự phụ thuộc giữa các Scrum Team. Sự phụ thuộc lẫn nhau nên được thể hiện rõ trong Nexus Sprint Backlog. Cũng như những Artifact khác của Scrum, Nexus Sprint Backlog phải được Transparency với các bên liên quan. Dưới đây là ví dụ của một Nexus Sprint backlog: Mỗi ngày Scrumviet chọn một niềm vui, nhưng niềm vui lớn nhất là được chia sẻ Scrum cùng các anh chị và các bạn. Hôm nay Scrumviet xin chia sẻ với mọi người hình ảnh về lớp PSM vừa diễn ra cuối tuần qua. Scrum on! Không có sự khác biệt giữa Product Backlog khi Scrum Team sử dụng Nexus. Trong cùng một product, thì chỉ nên có một Product Owner và một Product Backlog duy nhất. Đọc thêm về: Product Backlog.
Có một số sai lầm về cách sử dụng Product Backlog khi mở rộng Scrum team như là:
Việc nhiều Scrum Team cùng làm việc với nhau, sẽ dẫn dến nhiều sự phức tạp hơn, lúc này hơn bao giờ hết vai trò Scrum Master rất quan trọng:
|