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.

50 total views, 3 views today

There are some researches about team stages, the famous ones are Tuckman’s model and ShuHaRi. To be honest, both Tuckman’s and ShuHaRi models are generic and support for group development instead of cross-functional and self-organized team in Agile. But both of them are very well known and well explained to be borrowed to Agile. I usually use those models in common Agile article/training/coaching, and in this post as well.Tuckman defined team stages with Forming, Storming, Norming and Performing in his first publish. It’s a sequence, meaning each stage has it own obstacle that needs to be overcome for moving team to next stage (see Agile Y, chpt. 6).

While Tuckman is team model of performance, ShuHaRi is not. ShuHaRi is team model of learning and practicing Agile with Shu, Ha and Ri (following, branching, owning). But Agile is iterative and empirical approach for building team and process, learning and practicing seem to be ‘everything’ that directly affect to team performance.

Working in Agile team as an Agile coach, I like the idea of combining Tuckman and ShuHaRi model: bringing the team through Tuckman’s model stages by supporting them to overcome their obstacles following ShuHaRi. That bases on understanding team’s stage and its needs in each stage as ShuHaRi.

Stage 1: The child (Forming, Storming) & Shu: Need a ‘manager’

Team should be in the chaotic stage, a group of people with an initial agreement (on vision, working method…) but lot of disagreement (on process). What team needs is the very clear direction, and who team needs is a leader with strong management skill to quickly bring team out of chaotic state. Like a child, team doesn’t need to understand why red light is for stop, just stop. Command and control is acceptable here by well explained reasons and high level of ‘command’: following code review, applying TDD…

Many people believe that Agile team shouldn’t have a leader – that I cannot agree. Any team has a leader itself in may way, with or without title or responsibilities in the job description. In Scrum, ScrumMaster is a leader of process. My experience, there are 2 reasons for Agile team never steps out of those stages: team has a manager who lacks of leadership spirit, and team has a leader who lacks of management skills. Team needs both, a ‘leader’ to set the direction, and a ‘manager’ who make sure team is doing right (Shu) on the way. If these are in one person (TeamLead or ScrumMaster…), team should expect the clear communication that they are SHUring, be patient to Ha and Ri in the next steps.

Stage 2: The teenager (Norming) & Ha: Need a ‘leader’

Team should be in organized stage, a half-team with their agreements that were built up from their experiences. What team needs is the clear objectives and a methodologies to reflect their learning. Like a teenager, team understands why red light is for stop, green to go and sometimes try the new things with yellow ones. Team needs a ‘leader’ who supports their decisions to try various things in their own way, thing by thing and step by step. Team has few knowledge and skills of managing, then still needs but weak ‘manager’ could be good here. Together, managing skills can be built up by leadership spirit.

Stage 3: The mature (Performing) & Ri: Need a ‘coach’

Team should be in out standing stage, a true team with self-organized and enough of skillset to perform well. What team needs is a methodology for keeping the continuous improvement, and who team needs is a coach. Like a mature, team understands why lights exist in places, when it should be red, when it should be green. The method and coach should be for both: team and team member. How team works well together is still an important knowledge and skills to be built up but team shouldn’t expect the big step as child and teenager stages. Keeping or stepping out of this stage needs team deep understanding about the methodology behind rather than just practices. Team and each member needs  a coach who tell them the missing knowledge and skills, manage the improvement process and give feedbacks.

FSNP-SHR

You could see it as the model or pattern to be applied in team. But the hard and trick part is the leader/manager needs to recognize the correct stage of the team to shift his role or responsibilities in the right time. The metrics are useful out there.

596 total views, 8 views today

Here is my talk in Hanoi University of Science and Technology. The students came from many majors with different backgrounds challenged me, required another approach. Good-enough with less effort is the best way today. My thanks are sent to the authors of 2 slides below, the great ideas and contents helped me save times.

982 total views, 4 views today

Sau giai đoạn nhà nhà nói về “tinh thần Agile” như một thuật ngữ cửa miệng, giờ người ta bắt đầu nói về “tinh thần MVP”.

Nhưng giống như bao nhiêu thứ “tinh thần” khác được hô hào, cổ vũ mà thiếu nền tảng và thực hành rõ ràng – rất nguy hiểm. Chạy theo “tinh thần Agile” mà thiếu thực hành tạo ra một nhóm hỗn độn. Chạy theo “tinh thần MVP” mà thiếu thực hành tạo ra một sản phẩm tạp nham.

Tôi bắt đầu gặp nhiều nhóm làm sản phẩm với một công cụ MVP duy nhất là “tinh thần”:

  1. MVP không đồng nghĩa với kém chất lượng. “Có bug chút cũng được, chắc gì đã có ai dùng”. Nếu bạn đã không tin sẽ có người dùng (chức năng đó), tại sao lại làm? Rồi bạn sẽ biết người dùng không sử dụng do chức năng đó thực sự không nằm trong nhu cầu của họ hay nó tệ đến mức không thể sử dụng? Chúng ta có thể đặt nhỏ scope nhưng không được thoả hiệp với chất lượng.
  2. MVP không đồng nghĩa với “cứ làm đi”. MVP phải dựa trên giả định, phải tìm kiếm, nghiên cứu trước để củng cố phần nào cho giả định… MVP là công cụ để kiểm chứng lại giả định trong thực tế. MVP không phải là cứ có ý tưởng là lao vào làm, rồi để thực tế trả lời mà không định nghĩa rõ những giả định nào cần kiểm chứng.
  3. MVP rồi cũng phải dừng hoặc đi tiếp. Cần phân biệt rõ ràng, test là test. Khi đã đủ dữ liệu để kiểm chứng giả định, học từ đó và quyết định: đi tiếp hay dừng lại. Đã quyết định dừng lại thì phải thẳng tay loại bỏ chức năng không hữu ích. Đừng biến sản phẩm thành bãi rác.

Một sản phẩm làm sao phát triển bền vững nếu nó cứ loanh quanh trong việc “test” để tìm ra phần hồn của mình? “Tinh thần MVP” không có thực hành sẽ tạo ra một mớ hổ lốn không còn đúng với nguyên lý 80/20 mà chính MVP theo đuổi nữa.

403 total views, 3 views today

Trong quá trình đào tạo, tư vấn về Agile, tôi nhận được nhiều câu hỏi về “nhóm không chủ động đưa ra suy nghĩ, ý tưởng, thảo luận”, đây là vấn đề lo ngại rất cơ bản. Nhưng rất ít người nhận ra một vấn đề trái ngược hoàn toàn – nhóm có quá nhiều ý tưởng và thảo luận – điều mà tôi thấy xuất hiện nhiều hơn trong thực tế, ở một số nơi tôi huấn luyện.

Khi triển khai Agile, tư tưởng đề cao nhóm (phát triển) được cổ vũ, nhóm hiểu rằng mình là nòng cốt, trung tâm, quyết định thành bại của việc phát triển (được ScrumMaster và Product Owner hỗ trợ hết mức trong Scrum). Những thành viên trong nhóm (phát triển) yêu cầu thảo luận và tham gia thảo luận vào mọi vấn đề, và dường như không có một điểm dừng cụ thể. Tôi gọi đó là hội chứng nghiện thảo luận. Bài viết đề cập tới hội chứng này trong nhóm phát triển Agile/Scrum.

Dấu hiệu

Hội chứng nghiện thảo luận có thể được nhận biết qua những dấu hiệu:

Quá nhiều ý tưởng không được quản lý. Các thành viên nảy ra ý tưởng và thảo luận mọi lúc mọi nơi: trong các cuộc họp, trong ngày làm việc… , được đưa ra song không được ghi chép, lưu trữ lại.

Liên tục thảo luận không theo kế hoạch. Mỗi khi một ý tưởng được đưa ra là bắt đầu ngay một cuộc thảo luận không có dự định trước. Hai thành viên thảo luận bên ly cafe. Nhóm thảo luận trong buổi họp hàng ngày…

Liên tục đặt câu hỏi hoặc thảo luận trên những miền kiến thức khác với chủ đích không rõ ràng. Khi công việc đã được gán cho một thành viên cụ thể, các thành viên khác vẫn luôn mốn thảo luận thêm về cách làm. Lập trình viên quan tâm quá mức tới từng bước nhân viên marketing giới thiệu về sản phẩm và đóng góp ý kiến.

Liên tục mở rộng ý tưởng. Khi một ý tưởng được đưa ra, cuộc thảo luận bắt đầu, ý tưởng khác lại phát sinh, lại tiếp tục thảo luận không có hồi kết.

Tất cả chỉ là ý tưởng, không có nhiều hành động cụ thể. Hiệu suất sản sinh ý tưởng của nhóm vượt xa hiệu suất thực thi, nhóm dành 1/2 thời gian để sinh ra 8 ý tưởng khác nhau mỗi tuần và dành 1/2 thời gian còn lại để thực hiện 1 ý tưởng không rõ ràng.

Thực thi trên những thứ không rõ ràng. Khi thực thi một ý tưởng, những yêu cầu dừng ở mức chung chung, không rõ ràng, khiến việc thảo luận tiếp tục không dừng.

Hệ quả

Tốn thời gian. Tốn tiền.

Nguyên nhân

Hội chứng nghiện thảo luận tới từ việc thiếu cách làm việc khoa học, trong khi nhóm được cổ vũ quá mức. Sức mạnh của nhóm là không thể nghi ngờ, trí tuệ đám đông thì tốt. Nhưng khi tổ chức cổ vũ nhóm thì cũng cần song song với đó trang bị cho nhóm cách làm việc khoa học, nhận biết những vấn đề nào nhóm cần thảo luận và vấn đề nào thì không. Những thành viên trong nhóm phát triển có tần suất ra ý tưởng nhiều hơn cả Product Owner (nhóm Scrum) thường là không tốt.

Loại bỏ

Đừng nhầm lẫn giữa loại bỏ hội chứng nghiện thảo luận và loại bỏ thảo luận, giữa loại bỏ hội chứng nghiện ý tưởng và ý tưởng. Ý tưởng và thảo luận luôn luôn là điều tuyệt vời, song nhóm cần thực hiện khoa học hơn

Hãy đảm bảo có các buổi họp / workshop để brain storming. Hãy tạo không gian để những ý tưởng được “xả” ra, tập trung và đều đặn.

Hãy đảm bảo mọi sự kiện kết thúc trong khung thời gian cho phép. Buổi họp hàng ngày cần kết thúc đúng trong 15 phút, không nêu ý tưởng và thảo luận vượt quá thời gian.

Hãy đảm bảo mọi cuộc họp đều đi đúng mục tiêu ban đầu. Các buổi họp Planning là để lập kế hoạch, buổi họp Retrospective là để đánh giá lại quy trình… không thảo luận những ý tưởng bất chợt, không liên quan.

Hãy đảm bảo mọi thảo luận đều phải có kết luận cụ thể. Làm, không làm, để sau tính. Không kết thúc cuộc thảo luận, họp mà không có kết luận cụ thể. Không chuyển sang thảo luận trên chủ đề khác khi chủ đề trước đó bị bỏ lửng.

Hãy luôn nhớ tới Product Backlog. Bất cứ khi nào thành viên có ý tưởng, viết ra, đặt vào một nơi tập trung, Ideas Bag, Brown Bag… PO sẽ cùng nhóm xem xét để đưa vào Product Backlog và làm rõ sau.

Hãy thực thi. Thảo luận không có giá trị cho tới khi việc thực thi mang lại kết quả. Hãy đảm bảo những thảo luận phải được chuyển hoá thành hành động với sản phẩm cụ thể.

Cụ thể hoá và đo lường. Nhóm phải cụ thể hoá ý tưởng trước khi thực thi. Và hãy nhớ đo lường. Nếu không, ý tưởng nào cũng tốt hoặc tệ như nhau.

Kết

Trong đào tạo Agile/Scrum, những trainer luôn đề cao vai trò của nhóm, cho rằng tri thức của nhóm là tốt – điều này không sai. Song nếu nhóm không tỉnh táo nhận biết những gì nên thảo luận trong toàn nhóm, những gì nên giải quyết bởi cá nhân, việc hình thành tri thức nhóm sẽ dẫn đến chi phí khủng khiếp. Những thành viên với kỹ năng chính là testing tham gia thảo luận về kiến trúc với lý do “đóng góp một góc nhìn khác”, nhóm phát triển tham gia bàn quá sâu về kế hoạch marketing sản phẩm (không liên quan tới công nghệ)… không hề hợp lý. “Góc nhìn khác” đôi khi mang lại giá trị, song hãy nhớ, “đôi khi” – đánh đổi quá nhiều công sức chỉ để chờ đợi một “đôi khi” là lãng phí.

883 total views, 3 views today

Estimating by Story Point (SP) is important for a project that is following Scrum. It helps Product Owner (PO) and Development Team (DT) quickly imagine the workload of the upcoming Sprints and vision the release roadmap. Good estimation helps so much; the better accuracy is, the better Sprint goes. Then choosing the “unit” User Story (US) or the baseline of SP is important step.

Some of the Scrum guideline chose the baseline of SP by following:

  • Choose the “smallest” US and set it is 1 SP, call it a baseline.
  • Estimate other USs by comparing them with the baseline.

But this method isn’t good enough by 2 reasons at least:

  • What does it come between 1 or 2 if DT think a US is larger than 1 but less than 2 SP? We don’t have 1 and 1/2 in single card.
  • How does DT maintain the consistent compare of each US estimation? How they can make sure all 5-SP US are the same?

As my observer, following guideline above leads the new DT to less accurate estimation. One signal of not-good estimation is that SPs are distributed around a number like 1, 2, 1, 2, 1, 1… as it shows that the DT doesn’t know how to compare the difference between USs so that they choose the same number just because of the feeling.

Another way to choose the baseline is:

  • Choose the “smallest” US and set it 2 SP.
  • Find a US that is good to set 5 SP.
  • Call 2 and 5 baseline, estimate others.

The idea of the above method is:

  • DT can reserve 1 SP for the future US that maybe less than today smallest – 2.
  • DT understand how to compare US because they did it when finding 5-SP US.
  • When estimating a US, DT can choose to compare it with 2 or 5 instead of single unit for better accuracy.

The idea of choosing 2 SP as baseline is getting DT understood about US comparison and setup more anchor for the next estimation. Then choosing 2 & 5, 3 & 8, 1 & 2… doesn’t matter but my recommend is 2 & 5 because they are small enough in both absolute value and their difference.

464 total views, 1 views today

Ở Việt Nam, nhiều tổ chức bắt đầu chuyển mình sang thực hành Agile/Scrum. Và như một lẽ tự nhiên, nhu cầu tìm kiếm / tuyển dụng Scrum Master (SM) tăng cao. Lương thì vô kể, từ vài trăm tới vài ngàn USD. Khoảng cách rộng ghê gớm, song cũng hợp lý tuỳ thuộc vào chất lượng của SM.

  • Mức thấp nhất, SM phải biết Scrum guide, tổ chức được các sự kiện của Scrum.
  • Mức tốt hơn, SM phải có khả năng thu thập thông tin, giải quyết những trở ngại trong nhóm.
  • Mức tốt nữa, SM phải đưa ra gợi ý cho nhóm, điều hướng tới những cải tiến.
  • Mức tốt nữa, SM phải có khả năng huấn luyện, tư vấn ở quy mô ngoài nhóm và trong tổ chức

Nói chung là nhiều level, cũng giống như developer vậy – từ đọc 1 vài cuốn sách “for dummies” hoặc stackoverflow là lập trình được đến hiểu rõ về ngôn ngữ, đến hiểu rõ về công nghệ, đến hiểu rõ về nguyên lý…

Nhưng điều khác biệt là test level một developer thì dễ hơn test level một SM. Để biết developer ở level nào, tổ chức dùng những developer hiện có để đánh giá. Để biết SM ở level nào thì lại không thể làm như vậy bởi trong đa số trường hợp, SM này là người duy nhất trong tổ chức có hiểu biết về Agile/Scrum. Tôi đang nói đến việc đánh giá khi tuyển dụng, khi SM đã làm việc trong tổ chức thì việc “đo đạc” cũng dễ hơn.

Không đánh giá được làm sao mà tuyển dụng? Làm sao mà đặt được mức lương? Chịu thôi. Thị trường còn mới thì các tổ chức phải chấp nhận giả định rằng chế độ mong muốn phản ánh năng lực và nhu cầu làm việc. Nếu tổ chức thiết lập vị trí SM mà tư duy rằng “SM làm gì mà hết được 8 giờ / ngày?” là đã sai ngay từ cách đặt bài toán; thì bất kỳ lời giải nào cũng sẽ không đúng.

Một cách đánh giá khác, là thông qua chứng chỉ. Chứng chỉ không phải tất cả nhưng phần nào phản ánh kiến thức và năng lực của SM. Chứng chỉ không quá quan trọng với developer vì trình độ của họ có thể test được khi phỏng vấn; song chứng chỉ khá quan trọng với SM vào thời điểm này (như đã nói ở trên). Và vì các chứng chỉ về Agile thì thường không rẻ, nên khi các SM đã đầu tư vào chứng chỉ thì họ cũng có mong muốn nhận về mức lương tương xứng cho ROI.

Thế là, các tổ chức thì nghĩ “SM có mang lại giá trị sản xuất trực tiếp đâu mà đòi lương cao?”, SM thì nghĩ “đầu tư nhiều vậy mà ROI như này thì sao làm được?” – nên họ có ít cơ hội gặp được nhau ở một tiếng nói chung.

Lại mới chi tiền và submit SEUs để gia hạn CSP. Lý do duy nhất là trót viết CSP vào Agile Y rồi, không gia hạn thì biến mất khỏi membership directory, anh em lại bảo “nhận bừa” thì cũng kỳ. Hay anh em tẩy dùm cái dòng đó ở #agiley đi, hoặc coi như em viết sai chính tả thôi để năm sau em khỏi mất tiền nữa, được không? 

417 total views, 2 views today

Following my post about How programmer gets his wife happy, here is a simpler version for who is using Mac with Message app.

Forget all Twilio setup, you just need to create the cronjob. Replace the content and your wife’s number.

1. Create a file sweet_sms_to_darling.sh, put the command above.

2. Get it executable, and run at 18:30 every day.

Add this line, correct your file path, 18, 30 is the hour and minute triggers this bash script.

3. Save this file and add to cronjob. That’s all.

Life is easy if you are a programmer.

935 total views, 2 views today