Ngày nghỉ cafe thảo luận, tôi cho rằng thế giới Agile đang ngày càng phức tạp. Phạm Anh Đới cũng đồng ý rằng, Agile đang bị bias – thành kiến: kẻ thích trở nên cuồng, người không thích trở thành căm ghét.

Bài viết dài, là tập hợp của các ý tưởng lộn xộn. Vì thế bạn có thể nhảy vào bất cứ đoạn nào cũng nhận được các thông tin riêng lẻ; thấy hay thì đọc tiếp, không nhất thiết phải đọc từ đầu.

Agile là gì (và không là gì)?

Tại chính thời điểm này, định nghĩa về Agile hoàn toàn không rõ ràng. Quay lại lịch sử, thuật ngữ này lần đầu tiên được giới thiệu là “Agile Software Development”, sau một cuộc hội thảo giữa 17 người là tác giả của một số phương pháp phát triển phần mềm hiện đại (có tên và không tên), 2001. Họ chia sẻ chung một số phương pháp, nguyên lý… và Manifesto for “Agile Software Development” ra đời với 4 điều trong Tuyên ngôn và 12 nguyên lý.

Vậy là Agile Software Development có định nghĩa từ hời điểm đó, nhưng không bị giới hạn. Sau này có một số phương pháp nữa ra đời, dựa trên những nguyên lý trên, đồng thời khái niệm Agile cũng dần được thay thế cho Agile Software Development và lan dần sang một số lĩnh vực khác. Định nghĩa này chưa bao giờ được “nâng cấp version” một cách chính thức bởi những tác giả cũ cũng như mới nên nó trở nên không rõ ràng.

Agile thế nào (và không thế nào)?

Nhìn lại 4 điều trong Tuyên ngôn và 12 nguyên lý, dễ nhận thấy là chúng khá chung và đúng. Điều này dễ hiểu vì tìm kiếm điểm chung của nhiều phương pháp cũng như đồng thuận của 17 người, đại diện cho 17 tư duy, quan điểm thì khó mà cụ thể được.

Thời điểm đó, Agile là tập hợp của các phương pháp phát triển phần mềm dựa trên sự kết hợp của phương pháp lặp và tăng trưởng. Lưu ý, tôi đang nói về phần “thể hiện” của các phương pháp, không phải “tư duy” (nguyên lý) phía sau.

Nhưng sau này, dựa trên nguyên lý, nhiều thứ khác được coi là Agile với nhưng thể hiện không giống như ban đầu. Người ta bắt đầu nói về no planning, no estimation, no Sprint,… đủ thứ. Một ví dụ là Kanban, nó chỉ có thể hiện phần tăng trưởng, không rõ ràng đề cập tới lặp nhưng vẫn nằm trong Agile.

Agile có gì (và không có gì)?

Lưu ý rằng Agile Software Development cũng phải dựa trên một số nguyên tắc về quản lý, cách tổ chức nói chung nhưng những thứ này không được định nghĩa rõ ràng. Điều này dẫn đến một số hiểu lầm khá tệ. Ví dụ như “self-organized team”“cross-functional team”, Agile sử dụng mà không sở hữu; vậy nên không thể hiểu chỉ Agile mới xây dựng những team như vậy. Hay như mô hình về team stage của Tuckman cũng không thuộc về Agile. Kỹ thuật 5Whys, Kaizen… cũng vậy. Đó là những công cụ để nhóm hay người quản lý nhóm thực hiện tiến hoá quy trình.

Tương tự, DevOps ra đời sau, và “có liên quan” tới Agile. Nhưng ngày nay, cách hiểu Agile quá lớn nên DevOps được hiểu như là “nằm trong”. Holacracy?

Trách nhiệm có lẽ thuộc về những nhà tư vấn, đào tạo không phân biệt rõ, gây ra những hiểu nhầm rằng “Agile là con đường duy nhất để đạt được những điều này”.

Agile hướng tới gì (và không hướng tới gì)?

Agile hướng tới giá trị (value oriented), không hướng quy trình (process oriented). Quy trình trong Agile cũng buộc phải thể hiện được giá trị mới có lý do để tồn tại. Để tìm được giá trị, bắt buộc phải trả lời câu hỏi “tại sao (why)?”. Để tìm được quy trình, câu hỏi là “thế nào (how)?”. Câu hỏi why khó hơn rất, rất nhiều câu hỏi how. Và thông thường, để trả lời được câu hỏi why, chúng ta cần dựa trên how đang tồn tại.

Rắc rối ở đây, các nhà tư vấn, huấn luyện hoặc quản lý mong muốn đưa how vào trước; và kỳ vọng thời gian sau tổ chức sẽ tự trả lời được câu hỏi why. Công bằng mà nói, cách làm này không sai, nhưng nếu why không dần được tổ chức nhận ra, họ vẫn cứ loay hoay trong how. Và vô tình, Agile trở thành process oriented. Dù vậy, các “process” trong các phương pháp Agile vẫn khá tinh giản (so với các mô hình phát triển phần mềm khác), nên các team đã có quy trình trước đó khi chuyển sang Agile vẫn thấy bình thường. Điều tệ hại là, hầu hết các team ngày nay đều không áp dụng một phương pháp nào trước đó cho tới khi thực hành Agile, họ bỗng thấy Agile “cồng kềnh” và trở nên căm ghét.

(Ví dụ, team trong Scrum là self-organized, thật khó tin là đưa 5, 7 con người vào một team và hy vọng self-organized được nên vẫn cần có một số quy tắc, quy trình cơ bản ban đầu; nếu team không có sự tiến hoá, sẽ trở thành process oriented).

Sau không trào “doing Agile”, giờ là phong trào “being Agile” – dù không dễ, tôi vẫn thấy nó thiết thực. Nhưng “go Agile” thì không. Tôi chẳng biết trông nó sẽ thế nào.

Agile phù hợp với gì (và không phù hợp với gì)?

Nên nhớ, Agile ra đời với “Agile Software Development” tức là để giải quyết bài toán của phát triển phần mềm. Scrum nói rõ nó phù hợp với các dự án / sản phẩm nằm trong miền “phức hợp và phức tạp tương đối” về yêu cầu và kỹ thuật – tức là các dự án / sản phẩm đơn giản (đã rõ ràng) hoặc quá phức tạp (VD: R&D, công nghệ quá cao…) cần được xem xét. Thế nào là đơn giản, phức tạp… phụ thuộc nhiều yếu tố: con người, trình độ, công cụ,… nên (ví dụ) Scrum có thể phù hợp với team này ở sản phẩm này nhưng không phù hợp với team khác ở chính sản phẩm đó.

Agile dựa trên giả định về việc “chào đón sự thay đổi” (welcome change, Scrum: adapt to change, XP: embrace change); tức là, mọi cá nhân trong tổ chức đều thống nhất rằng “thay đổi là điều được chấp nhận”. Tổ chức không đồng tình với sự thay đổi, không “chào đón” mà áp dụng Agile là sai từ gốc.

Hầu hết các phương pháp Agile đều dựa trên gỉa định “cá nhân có động lực làm việc” nên các tổ chức còn loay hoay trong việc này cũng nên cẩn trọng.

Nếu nhìn lại các câu hỏi đã được trả lời trên, Agile có thể giải quyết rất nhiều bài toán khác, không chỉ với việc phát triển phần mềm (trong Agile Y tôi còn nói tới cá nhân). Cùng với sự thống trị của các công ty công nghệ (mà lõi là sản phẩm phần mềm), Agile lan rộng sang những lĩnh vực khác, “nuốt chửng cả thế giới”. Cần lưu ý:

– Vì vậy Agile càng không rõ ràng.
– Các lĩnh vực khác không có chỉ dấu rõ ràng về hiệu quả vượt trội của Agile như trong phát triển phần mềm – nơi Agile ra đời do trải qua sự khủng hoảng về phương pháp.

hãy cẩn trọng.

Agile trở thành “thuốc chữa bách bệnh”.

Agile thực sử trở nên không rõ ràng. Cách hiểu gần nhất (của tôi) có thể là “Agile là công cụ (mindset, toolset) để tăng tính linh hoạt (agility) của tổ chức, qua đó thích ứng tốt với thay đổi (hoặc dẫn dắt thay đổi)”.

Và cho đến giờ này, đây có vẻ là “bệnh” rõ nhất của các doanh nghiệp; và với hổ lốn những thứ được gắn tag Agile, Agile có vẻ được kỳ vọng quá lớn để chữa bách bệnh.

Và khi không chữa được, đương nhiên Agile bị đổ lỗi.

Như trên, tôi cho rằng trách nhiệm nằm ở những nhà tư vấn, đào tạo Agile trong việc rạch ròi Agile là gì, và Agile trong phạm vi anh cung cấp dịch vụ là gì, nó thế nào, hướng tới đâu. Bằng cách vơ vét tất cả mọi thứ vào Agile cùng sự quảng cáo quá đà, gây ra sự ảo tưởng về sức mạnh từ tổ chức.

Agile trở thành “đạo”.

Agile dự trên pull-system, giả định “cá nhân có động lực làm việc”, điều này đi ngược với phần lớn cách tư duy về quản lý hiện có. Dù có hệ thống lý thuyết chặt chẽ đứng sau, Agile vẫn cần niềm tin để thực hiện trong tổ chức. Khi phương pháp cần tới “niềm tin” là điểm xuất phát thì nó không khác gì “đạo” – sẽ có kẻ sùng đạo và phản đạo.

Có fan và anti-fan là điều dễ hiểu.

Scrum đã làm tốt gì (và không làm tốt gì)?

Scrum thực sự tuyệt vời. Nó là một mô hình tuyệt vời với đủ sự tinh gọn, hiệu quả cho phép tổ chức “nhận diện vấn đề”. Đây là điều siêu quan trọng để phát triển sản phẩm cũng như phát triển tổ chức.

Scrum không làm việc giải quyết vấn đề. Vậy nên nếu nhóm không giải quyết những vấn đề được nhận diện, Scrum là đống rác cạnh hàng ăn. Nhưng có phương pháp nào giải quyết vấn đề không?

Scrum làm tốt trong việc ghi chú “Scrum dễ hiểu, khó làm chủ”.

Scrum (đúng hơn là các tổ chức cấp chứng chỉ Scrum (Master, Developer, PO)) làm không tốt trong việc đào tạo. Khá dễ dãi. Có 2 lỗ hổng lớn, khiến các ScrumMaster cầm chứng chỉ và nếu không chịu học hỏi thêm sẽ mắc phải:

1. Không trả lời được rõ ràng các câu hỏi trên. Cái gì thuộc Scrum, cái gì không? Dẫn đến ngộ nhận trong lỹ thuyết lẫn thực hành.

2. ScrumMaster không yêu cầu kiến thức về phát triển phần mềm. Về lý thuyết, điều này không sai; song thực tế thật khó để tham gia vào nhóm phát triển phần mềm mà không hiểu gì về cách nhóm thực hiện.

Từ đây dẫn tới những hệ luỵ vô cùng phức tạp. Chuyển giao cái gì? Technical debt là gì? Simple design là gì? Xử lý thế nào? Tài liệu thế nào là đủ?…

ScrumMaster yếu về chuyên môn (ngành) và non tay dẫn dắt nhóm có trình độ cao hơn mình sẽ là thảm hoạ. Đội bóng cần HLV tương xứng. Vấn đề là, tốc độ phát triển của thành viên Nhóm phát triển thường nhanh hơn (và khởi đầu tốt hơn) những ScrumMaster. Vậy nên nhiều nhóm phát triển bắt đầu chán ghét Scrum.

Trách nhiệm này thuộc một phần vào các tổ chức cấp chứng chỉ Scrum, phần lớn thuộc về các ScrumMaster khi không thể hiện được vai trò tương ứng, và cả các nhà đào tạo – không trang bị đủ hệ thống lý thuyết và thực hành.

Trách nhiệm của những nhà đào tạo, tư vấn?

Đừng trách sự tồn tại của những nhà đào tạo, tư vấn. Đừng trách những quảng cáo, khóa học. Đó là nhu cầu tất yếu, và thiết thực, bởi họ giúp rút ngắn con đường tổ chức tiếp cận Agile (nếu muốn). Nếu họ làm việc trên nguyên tắc cung cấp đúng giá trị và đạo đức.

Nhưng, đến lúc này, tôi cho rằng những nhà đào tạo, tư vấn cần phải có câu trả lời rõ ràng cho mình, cho khách hàng rằng với anh, Agile là gì (và không là gì), Agile (trong phạm vi đó) mang lại giá trị gì và lấy đi gì…?

Giống như bác sỹ, cần rõ ràng rằng những thành phần này là gì, tổ hợp lại được gọi tên gì, chữa bệnh gì, chống chỉ định gì, tác dụng phụ gì…?

Tuyệt nhiên không thể mông lung như Agile làm nhóm hạnh phúc hơn, Agile giúp tăng năng suất, Agile giúp tăng tốc độ hoàn thành dự án… – những điều Agile nguyên thuỷ không hề đề cập.

Những chuyện “nhỏ nhặt” khác:

Còn một mớ trao đổi khác. Cơ chán rồi. Có phản hồi mà rảnh thì viết tiếp, thế cho nó Agile.

171 total views, 2 views today

I had a talk in monthly meetup of hocvienagile.com, July. Here is the slide. In fact, some few words in the slide cannot express my idea clearly 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;  in development’s view, Agile is for quality. 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 an 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.

725 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”.

925 total views, no 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.”

852 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.

532 total views, no views today