I had a talk in monthly meetup of hocvienagile.com, July. And here is a slide. In fact, some few words in the slide cannot express my idea clearly enough while our discussion was very interesting. It’s not easy to write these ideas in a short article but it’s nice for some notes:

  1. Agile is for speed, budget…? No. In business perspective, Agile is for value while Agile is for quality in developer’s view. Agile is a method to adjust / negotiate between the constrains of scope, time and budget to get the highest value / quality in the current situation.
  2. Agile team is happier than non-Agile team. Not sure. If we don’t use the negotiation to adjust these constrains in the right way, Agile team never has chance to be happier.
  3. Agile is built for fast success. No. There are many tricks to get a Agile team successful in the early stage but it’s normally a trap.
  4. Scrum is the best Agile framework. Not sure. About 50% of Agile-share doesn’t show that Scrum is the best Agile framework. Every Agile team should start with Scrum because it’s easier and has clear guideline with specific roles, events…etc.  But when the world is changing fast from development-in-black-box to operation stage, Scrum is going down due to limitation of Sprint goal.
  5. Always say no to ScrumBUT. Not sure. If we are aware that ScrumBUT is being used in reasonable way, it’s fine. Read more here.
  6. Scrum needs 5 core values to success. No. If a team has 5 core values (as Scrum mentions), they would be successful no matter Scrum or another framework is being used. It’s not a required values to start a Scrum team, it’s a target for having high performance team. If a Scrum team doesn’t have, find the right ways from 3 Scrum pillars to get them up.
  7. Agile works without XP practices. No. Never. I have never seen any Agile team (in software development) be successful without XP. XP is the most important thing in Agile umbrella.
  8. Retrospective never talks about people. We should talk about processes, tools and also people. But please do it in constructive way, for both people who give and receive feedbacks. Please not that “Individuals and interactions over processes and tools” is mentioned in Agile Manifesto.
  9. Agile team needs stability, so small turnover-rate is good. Not sure. We also need the new knowledge and change by getting Agile team in a downer stage with new guys.

584 total views, no views today

ScrumBUT is an interesting term for a Scrum team. I have met a lot of Scrum team that has never been performance team because of this thought “Agile and especially Scrum normally welcome the changes, Scrum itself is just a framework so we always need to modify it to work for us”. This idea doesn’t seem wrong because Scrum provides the method that helps the team finds it best process itself; but modifying Scrum before the team totally own it seems a bad idea. Because Scrum is very simple and a minimise framework, the team should follow Scrum guide for being stable before thinking about adjustment. Remember, the adjustments just bring the best values while the team owns Scrum to deep understand which is suitable for it. And please adjust, don’t modify it.

ScrumBUT is practising Scrum without following Scrum guide:

“We use Scrum BUT we don’t have Daily Scrum”

“We use Scrum BUT we do Sprint Retrospective for 5 hours”

ScrumBUT of course isn’t recommended by the Scrum organisations. In my opinion, practising Scrum or ScrumBUT doesn’t matter, if it can bring the good values. But the important thing is: Is the team aware of practising Scrum or ScrumBUT? The team practises ScrumBUT because of ability of following Scrum guide or adjustment need? Is there any reason, evidence shows that practising ScrumBUT brings more values? If these questions are well answered, ScrumBUT brings more values and it should be recommended. But, practising ScrumBUT without deep understand about Scrum is normally a pitfall, be careful.

If there are many BUT, the team isn’t practising ScumBUT; it’s following another process that might unrelated to Scrum. Then why does the team need Scrum? It happens in 2 cases: or team has high knowledge and practice to give another method (there are few teams); or the team in “Scrum beginning” period.

Somebody talks to me “my team is practising Scrum because we have daily standup meeting”. “No, you don’t practise Scrum, you just practise only 1 Scrum event. It isn’t ScrumBUT as well”.

742 total views, 3 views today

ScrumBUT là một khái niệm rất đáng lưu tâm với những nhóm thực hành Scrum. Tôi đã tiếp xúc với rất nhiều nhóm Scrum không đạt được hiệu quả cao bởi tư tưởng “Scrum và Agile nói chung chào đón những thay đổi, bản thân Scrum cũng là một framework nên việc thay đổi Scrum cho phù hợp là đương nhiên”. Ý kiến đó không sai, bởi Scrum cung cấp cách thức giúp nhóm tìm ra quy trình hợp lý cho chính mình; song việc chỉnh sửa Scrum khi nhóm chưa thực sự làm chủ Scrum thường là một quyết định thiếu sáng suốt. Bởi Scrum đã rất tối giản, các tổ chức khi triển khai Scrum cần làm theo hướng dẫn Scrum để có sự ổn định trước khi đưa ra những điều chỉnh, bởi những điều chỉnh chỉ đạt hiệu quả tốt khi chúng ta thực sự làm chủ bằng cách thực hành đúng để hiểu Scrum có phù hợp hay không.

Khái niệm ScrumBUT để chỉ việc thực hành Scrum không theo chỉ dẫn:

“We use Scrum BUT we don’t have Daily Scrum” – “chúng tôi thực hành Scrum nhưng không thực hiện Daily Scrum”

“We use Scrum BUT we do Sprint Retrospective for 5 hours” – “chúng tôi thực hành Scrum nhưng sử dụng 5 giờ cho sự kiện Sprint Retrospective”

ScrumBUT đương nhiên là không được khuyến nghị từ các tổ chức đào tạo Scrum. Nhưng theo tôi, việc thực hành Scrum hay ScrumBUT không quan trọng, nếu việc làm đó mang lại hiệu quả cao. Điều quan trọng là: Nhóm có nhận ra mình đang thực hành Scrum hay ScrumBUT không? Nhóm thực hành ScrumBUT vì không thể thực hành đúng Scrum hay cần sự điều chỉnh? Có lý do, bằng chứng nào cho thấy việc thực hành ScrumBUT cho hiệu quả cao hơn không? Nếu 3 câu hỏi đó được trả lời thoả đáng, việc thực hành ScrumBUT sẽ cho hiệu quả cao và nên được khuyến khích. Tuy vậy, việc thực hành ScrumBUT nếu thiếu những lý thuyết thường là cạm bẫy, hãy cẩn thận.

Nhưng nếu có quá nhiều BUT, nhóm cần biết rằng mình đã không còn thực hành ScrumBUT nữa, mà đang đi theo 1 quy trình hầu như không còn liên quan tới Scrum. Lúc đó nhóm cần một tên gọi khác cho quy trình của mình, đừng sử dụng Scrum. Nhưng nếu vậy, nhóm cần Scrum để làm gì? Chỉ có 2 trường hợp dẫn tới kết quả này: hoặc nhóm đã có hiểu biết và thực hành rất cao để đưa ra một phương pháp khác (rất ít); hoặc nhóm đang trong giai đoạn “chưa hiểu gì về Scrum”.

Thậm chí nhiều người gặp tôi và khẳng định “nhóm của tôi đã thực hành Scrum vì chúng tôi có standup meeting hàng ngày”. “Không, bạn thậm chí còn không thực hành ScrumBUT, bạn chỉ thực hành 1 trong nhiều sự kiện của Scrum mà thôi.”

759 total views, no views today

The introduction to Scrum in TapLife, shared in 2 hours with the product teams.

After a short introduction, they talked about the current context to get my shares.

Taplife is a startup, building some great mobile apps that are focused on the augmented reality. They are facing some common startup issues: looking for the effective working methods in the software development as they “seem” be following waterfall right now by the content team goes first with full specifications, design team make them visual on UI and developers end up by code implementation. It of course takes more time to make an idea go live.

410 total views, no views today