Những ý chính nổi bật:
- Không có một cách tiếp cận chuẩn mực duy nhất nào để làm mọi việc nhanh nhẹn hơn, hoặc để mở rộng quy mô Scrum
- Tinh gọn (Lean) và Agile là hai khái niệm khác nhau nhưng lại là bạn đồng hành tuyệt vời
- Bạn có thể tinh gọn mà không cần linh hoạt, và có thể linh hoạt mà không cần tinh gọn
- Nhân viên điều hành cần tham gia vào toàn bộ quá trình và là một phần của nó
- Hiểu được sự phức tạp và hệ thống đa nhóm là yếu tố quan trọng để thành công
Toyota Connected áp dụng Scrum kết hợp với Hệ thống Sản xuất Toyota để có thể cung cấp Lean Production (Sản xuất Tinh gọn), cho phép các nhóm phân phối chu trình PDCA một cách nhanh chóng. Scrum of Scrums, Meta Scrum và chủ sở hữu sản phẩm chính, là một số phương pháp được sử dụng để mở rộng Scrum cho nhiều nhóm và nhiều sản phẩm. Linh hoạt không phải là mục tiêu hướng đến mà nó là một kết quả.
Nigel Thurlow, giám đốc Agile của Toyota Connected, sẽ nói về “Scrum theo cách của Toyota” tại sự kiện eXperience Agile 2018. Hội nghị này sẽ được tổ chức tại Lisbon, Bồ Đào Nha, vào ngày 1 và 2 tháng 10.
Trong InfoQ hôm nay chúng ta sẽ nói về eXperience Agile thông qua mục hỏi và đáp, kèm một số tóm tắt sơ lược và bài viết liên quan. Chủ đề hội nghị năm nay, “Cải thiện thông qua con người” được mô tả như sau:
Khám phá cách áp dụng Agile tân tiến nhất của các nhà lãnh đạo ngành công nghiệp hàng đầu từ khắp nơi trên thế giới. eXperience Agile không chỉ là một hội nghị đơn giản. Đây là một sự kiện làm nổi bật các ứng dụng mang tính cách mạng nhất của Agile đang được sử dụng ngày nay.
InfoQ đã phỏng vấn Thurlow về cách mà DNA của Toyota kết nối với Scrum cùng sự linh hoạt; những thách thức mà Toyota Connected đang đối phó; cách họ áp dụng sự linh hoạt và những gì họ đã học được; vai trò của chủ sở hữu sản phẩm; bằng cách nào các lãnh đạo cấp cao có thể hòa nhập với thế giới của Agile, và làm thế nào Scrum và sự linh hoạt liên hệ với hệ thống sản xuất của Toyota và Lean Production (Sản xuất Tinh gọn).
InfoQ: DNA của Toyota là gì và nó kết nối với Scrum cùng sự linh hoạt như thế nào?
Nigel Thurlow: Tất cả nhân viên ở Toyota đều hiểu việc đặt khách hàng lên đầu là gì và các nguyên tắc sáng lập của TPS cũng như của Toyota Way. Khi chúng tôi thảo luận về giá trị của việc sử dụng công nghệ mới và kỹ thuật số, chúng tôi luôn có DNA ở bên cạnh nhắc nhở lý do vì sao chúng tôi cần làm điều đó: vì khách hàng của chúng tôi.
Customer First hay quy tắc đặt khách hàng làm ưu tiên lần đầu xuất hiện vào năm 1946, đặt ra bởi chủ tịch đầu tiên của Toyota Motor Sales Nhật Bản, Shotaro Kamiya, và đây là nguyên tắc về việc xem xét nhu cầu và mong muốn của khách hàng khi xác định phương hướng và chiến lược. Nói một cách đơn giản, nguyên tắc này hướng tới việc mang lại chất lượng cao nhất, trong thời gian ngắn nhất, với chi phí thấp nhất.
Scrum là một khung làm việc, nó cho phép các nhóm phân phối chu trình PDCA một cách nhanh chóng, nơi mà giá trị mang lại cho khách hàng được ưu tiên và những công việc không mang lại giá trị sẽ được loại bỏ. Điều quan trọng cần lưu ý là Scrum không mang lại sự tinh gọn, và làm việc tinh gọn không có nghĩa là bạn đang làm tốt Scrum.
Agile là kết quả chứ không phải là mục tiêu. Scrum là một cách để giúp bạn đạt được điều đó, trên thực tế đó là cách tốt nhất mà tôi đã dùng để mã hóa PDCA. Mọi người đều biết PDCA là gì, nhưng không ai thực sự hiểu được chu kỳ PDCA kéo dài bao lâu. Những gì chúng tôi đang cố gắng làm với Scrum là rút ngắn chu kỳ đó. Đó là việc kiểm tra phản hồi của khách hàng (check) và điều chỉnh cho phù hợp với phản hồi đó (act). Tôi giải thích việc này thông qua các khâu PDIA: Plan (Lập kế hoạch), Do (Thực hiện), Inspect (Kiểm tra), Adapt (Thích ứng).
Cũng như việc Scrum không làm cho bạn Lean (tinh gọn), Lean không có nghĩa là bạn Agile (nhanh nhẹn). Bạn có thể là Lean mà không cần đến Agile, và bạn có thể Agile mà không cần Lean. Chúng những khái niệm khác nhau, nhưng bổ sung cho nhau. Chúng tôi muốn Lean, cung cấp các giá trị một cách hiệu quả nhất có thể, nhưng chúng tôi cũng muốn Agile bằng khả năng phản ứng nhanh chóng với những thay đổi về nhu cầu của khách hàng hoặc thị trường hoặc phản ứng nhanh với các sự kiện không xác định.
InfoQ: Những thách thức mà Toyota Connected đang phải đối mặt là gì?
Thurlow: Toyota Connected (TC) được thành lập như một startup đơn giản để giúp Toyota phản ứng nhanh chóng với sự thay đổi của công nghệ kết nối không gian. Chúng tôi không chỉ nói về những chiếc xe tự động, mà còn về việc cung cấp một loạt các dịch vụ kết nối với chủ xe để đáp ứng nhu cầu di chuyển của họ. Ý tưởng đến từ tầm nhìn của Chủ tịch Toyota, Akio Toyoda, và chúng tôi cố gắng thực hiện điều này bằng cách tận dụng các công cụ kỹ thuật số theo ý của chúng tôi – từ Trí thông minh nhân tạo đến Internet of Things (Internet Vạn Vật) – cho phép chúng tôi xây dựng tương lai cho công nghệ xe kết nối.
Chúng ta đang làm việc trong một thế giới thay đổi nhanh chóng, nơi thời gian để thị trường thay đổi không còn được đo lường bằng năm nữa, mà thường là bằng tháng, và thậm chí ngay cả với thời lượng ngắn hơn. Khi hàng ngày chúng tôi phải nghĩ đến cách nâng cấp xe trong thời gian ngắn nhất, đồng thời phải quan tâm đến sự tăng trưởng của các phương tiện dữ liệu trực tuyến có thể truyền đi, và chúng tôi cũng phải có khả năng mang lại những lợi ích và năng lực mà khách hàng của chúng tôi tìm kiếm. Điển hình như giúp một công ty bảo hiểm đo được tỷ lệ một cách chính xác thông qua hệ thống lắp đặt cho lái xe, hay sửa chữa một vấn đề trong hoạt động của hệ thống khí, hoặc tạo ra các tùy chọn di động như dịch vụ chia sẻ xe Hui ở Honolulu kết hợp với Servco Pacific Inc, tích hợp chương trình Alexa của Amazon vào xe Toyota và nghiên cứu những tiến bộ trong khoa học dữ liệu cùng AI (trí thông minh nhân tạo).
InfoQ: Toyota Connected áp dụng agile như thế nào?
Thurlow: Chúng tôi thực hành và giảng dạy các nguyên tắc của Hệ thống Sản xuất Toyota (Lean) và Toyota Way, nhưng chúng tôi cũng được thiết kế như một công ty linh hoạt. TC được thiết lập để hoạt động như một startup, nhưng với sự ổn định và nguồn tài trợ của một tập đoàn toàn cầu. Chúng tôi tạo ra một môi trường văn phòng tuyệt vời dành cho thực hành kĩ thuật và thiết kế, nhằm cho phép các đội ngũ phát triển mạnh theo một cách sáng tạo và cởi mở.
Nhóm hợp tác nhỏ (thường từ năm đến sáu người) của chúng tôi ngồi rất gần nhau trong các văn phòng với không gian mở, phòng Obeya (một hình thức quản lý dự án được sử dụng trong các công ty châu Á và là một thành phần của sản xuất lean và đặc biệt là hệ thống sản xuất Toyota), quản lý trực quan và Andon (một thuật ngữ sản xuất đề cập đến một hệ thống để thông báo cho quản lý, bảo trì và các công nhân khác về vấn đề chất lượng hoặc quy trình. Trung tâm là một thiết bị kết hợp đèn tín hiệu để cho biết máy trạm nào có vấn đề) xung quanh. Trong khi chúng tôi sử dụng các công cụ điện tử, chúng tôi cũng dạy và khuyến khích việc quản lý trực quan, nhằm tạo sự minh bạch và cởi mở, đồng thời tạo ra những cuộc tranh luận thực sự tại gemba (hiện địa) giữa các lãnh đạo và bên liên quan chính.
Chúng tôi đang tập trung vào việc tạo ra dòng chảy hiệu quả bằng cách loại bỏ tắc nghẽn và trở ngại, tăng tốc việc mang lại giá trị cho khách hàng. Để làm được nhiều này chúng tôi triển khai nghiên cứu khoa học đa nhóm, hợp tác với Đại học Bắc Texas để nghiên cứu và thực hiện nhiều thí nghiệm nhằm xác định các hình mẫu lặp lại trong nhiều bối cảnh, từ đó gia tăng sự linh hoạt. Chúng tôi hiện đang làm việc để xuất bản trong tháng tới những tài liệu học thuật với mục đích chia sẻ công nghệ Agile.
Một ví dụ về Multi Team Systems (Hệ thống đa nhóm) là Scrum of Scrums và Meta Scrum. Chúng tôi định nghĩa chúng như các mẫu hành vi, và thông qua việc quan sát chúng, chúng ta có thể xác định những gì hoạt động và những gì gặp vấn đề. Sau đó chúng tôi có thể thử nghiệm bằng cách điều chỉnh quy trình và xem xét hiệu ứng trên hành vi. Khi chúng tôi tinh chỉnh các nhóm tương tác này, chúng tôi lặp lại quy trình và ghi lại chúng dưới dạng mẫu, cả tích cực lẫn tiêu cực.
Một ví dụ khác là ý tưởng tạo ra một SoSM (Scrum of Scrums Master), để nó chịu trách nhiệm về sự thể hiện nỗ lực chung của nhóm. Chúng tôi thấy rằng điều này tạo ra một lãnh đạo có thể ra lệnh và kiểm soát, vì bây giờ chúng tôi chỉ có một người duy nhất có thể “yêu cầu” các đội phân phối. Điều này làm giảm sự hợp tác giữa các đội khi họ đang được đo lường và chịu trách nhiệm bởi một người quản lý ủy nhiệm.
Chúng tôi nhận ra rằng việc đơn giản thành lập một nhóm sử dụng Scrum không tạo ra một đội ngũ tuyệt vời, và càng liên quan đến càng nhiều đội các thách thức càng lớn hơn. Do đó thay đổi hành vi và đào tạo kỹ năng làm việc nhóm là điều cần thiết.
Cynefin giúp chúng tôi hiểu được các hệ thống thích ứng phức tạp của các nhóm với nhiều hành vi không thể đoán trước. Điều quan trọng cần phải hiểu rằng, chính sự phụ thuộc lẫn nhau trong công việc xác định việc có cần đến một nhóm không, chứ không phải cứ những người trong một cấu trúc đã xác định là một nhóm, mặc dù đây có thể là điều thể hiện trong biểu đồ tổ chức. Nếu các cá nhân cần phải làm việc nhất quán với các cá nhân khác để thực hiện nhiệm vụ, thì chúng tôi coi đó là sự phụ thuộc lẫn nhau và chúng tôi hình thành một nhóm, bỏ qua các báo cáo. Những người này sẽ làm việc phụ thuộc lẫn nhau, cùng thích nghi và cùng năng động hướng tới mục tiêu chung.
Qua việc nghiên cứu công trình của David Snowden với các giáo sư tại UNT, chúng tôi đang bắt đầu xác định các dấu hiệu hành vi của các nhóm mà họ có thể tự nhận ra và tự sửa chữa, cùng với việc huấn luyện và hỗ trợ chặt chẽ từ Scrum Master của nhóm.
Chúng tôi đang tìm kiếm ý nghĩa của sự linh hoạt đối với Toyota trong tư cách là một tập đoàn toàn cầu. Chúng tôi tích lũy rất nhiều kiến thức về ngành và chúng tôi đang trao lại chúng cho cộng đồng bằng cách tìm kiếm sự phối hợp giữa TPS/ Lean và thế giới Agile. Gần đây, chúng tôi đã tung ra một sản phẩm với tên gọi Scrum the Toyota Way, và sau khi thử nghiệm beta thành công, chúng tôi hiện đang lên kế hoạch cho việc phổ biến rộng rãi khóa đào tạo này. Chúng tôi vẫn tiếp tục học hỏi những điều mới và tìm hiểu sâu hơn về thế giới này.
InfoQ: Các bạn đã học được những gì?
Thurlow: Chúng tôi đã học được rằng để trở nên linh hoạt hơn là rất khó, thực sự khó. Cũng không tồn tại thứ gì như một sự chuyển đổi để linh hoạt hơn. Về cơ bản bạn phải thay đổi mô hình hoạt động của bạn, và thực hiện một sự chuyển đổi cấp tổ chức để đạt được sự linh hoạt mà bạn mong muốn. Scrum là một công cụ giúp bạn thực hiện việc này. Việc chuyển đổi cũng phải thực sự cần thiết. Nếu cấp trên không thấy lý do đủ thuyết phục để thay đổi, rất có khả năng bạn sẽ làm mọi việc tồi tệ hơn bằng cách làm rối loạn tình hình hiện tại. Lúc này thì việc thay đổi sẽ bị cản trở mạnh và không có một bàn tay nào đủ đanh thép để thực hiện được sự thay đổi mong muốn.
Chúng tôi cũng nhận ra rằng không phải ai cũng cần linh hoạt! Nếu bạn đang vận chuyển bê tông, bạn có thể không cần chạy nước rút trong hai tuần, vì ở đây không xuất hiện nhu cầu thay đổi nhanh chóng. Chắc chắn, Scrum có thể cung cấp cho bạn một kế hoạch nhịp nhàng, nhưng Scrum được thiết kế để làm việc trong các lĩnh vực phức tạp và với các hệ thống phức tạp, những lĩnh vực mà phương pháp tuyến tính và tư duy cố định không có hiệu quả.
Nếu bạn đang làm việc trong lĩnh vực mang tính cố định và thay đổi rất ít, thì sự linh hoạt có thể không quan trọng như Lean (sự tinh gọn). Tối ưu hóa hiệu quả của dòng sản phẩm có thể mang lại nhiều lợi ích hơn. Tuy nhiên, nếu bạn đang làm việc trong một thị trường đang thay đổi nhanh chóng, thì sự linh hoạt là rất quan trọng. Hãy nhớ rằng, bạn có thể tinh gọn mà không linh hoạt, và linh hoạt mà không tinh gọn. Agile và Lean theo sự gợi yếu của tôi là một sự kết hợp toàn thắng. Bạn có thể nói rằng sự linh hoạt thì cung cấp đúng thứ, và sự tinh gọn thì cung cấp mọi thứ đúng cách.
InfoQ: Bạn thấy Scrum thành công như thế nào?
Thurlow: Nếu bạn là một startup với một nhóm hoạt động và một sản phẩm, Scrum sẽ rất đơn giản để áp dụng, và rất hiệu quả. Nếu bạn đặt một nhóm các cá nhân tài năng cùng với nhau trong một căn phòng, cung cấp cho họ động lực và thách thức, họ sẽ tạo ra những điều tuyệt vời. Scrum có hiệu quả cao trong việc rút ngắn chu kỳ PDCA và cung cấp kết quả nhanh chóng, bằng cách phản hồi nhanh đối với thay đổi, và đây là một nguyên lý quan trọng của Agile.
Mở rộng quy mô cho một nhóm với nhiều sản phẩm thì product backlog sẽ trở thành backlog của nhóm. Vấn đề ưu tiên thứ gì giờ trở nên khó khăn hơn khi nhiều bên liên quan đều đang tranh giành vị trí số một. Việc quan trọng là đặt backlog dưới sự lãnh đạo để những cuộc thảo luận và sắp xếp ưu tiên có thể diễn ra tức thời. Và khi tôi về việc “đặt” backlog, ý tôi là làm sao để chúng dễ nhìn thấy được, hãy đặt chúng trên một bảng treo tại bức tường khổng lồ nơi hàng loạt các bảng khác được xếp liền nhau. Đây chính xác là những gì chúng tôi đang làm tại Toyota Connected.
Quy mô nhiều nhóm trên cùng một sản phẩm thì một số hình mẫu trở nên hữu ích; những mẫu mang đến cấp độ cao hơn của backlog và quản lý sản phẩm. Ở đây, chúng tôi bắt đầu sử dụng Meta Scrum để quản lý việc tồn đọng, cũng như Scrum of Scrums cho việc quản lý phân phối trên nhiều nhóm phụ thuộc. Do sự phụ thuộc giữa các nhóm và sản phẩm tăng lên, việc tìm ra kỹ thuật ứng dụng để điều phối hợp lý sự cộng tác này là vấn đề cấp bách.
Khi bạn mở rộng quy mô cho nhiều nhóm trên nhiều sản phẩm, độ phức tạp sẽ tăng theo cấp số nhân. Sẽ có nhiều sự phụ thuộc và hạn chế tại đây, như là có nhiều đối tác hay nhà cung cấp, hay là việc phải phát triển trong những giới hạn của một tập đoàn toàn cầu, tất cả những điều này khiến việc đạt được sự linh hoạt phức tạp hơn nhiều. Các khái niệm như cũ, các công cụ đều giống nhau, nhưng bối cảnh làm thay đổi mọi thứ. Đây là lúc mà thiết kế tổ chức và các mô hình hoạt động phải thay đổi và phát triển.
Chúng tôi đã nhận thấy rõ ràng rằng không có một khung làm việc chuẩn mực nào có thể áp dụng cho mọi hoàn cảnh. Không thể đoán trước được khung áp dụng dựa trên bối cảnh nhưng khi áp dụng theo quy mô thì bối cạnh lại cực kỳ quan trọng. Các mô hình, các kỹ thuật, các thí nghiệm và cả sức mạnh làm việc nhóm là chìa khóa, nhưng hiện nay không có một giải pháp duy nhất, ít nhất là vẫn chưa.
InfoQ: Vai trò của Product Owner quan trọng như thế nào?
Thurlow: Vai trò của Product Owner (PO) rất quan trọng đối với sự thành công của một nhóm Scrum, nhưng cũng là thách thức lớn nhất. Khái niệm về việc các nhóm tạo ra đòn bẩy hạng nặng trong việc tạo ra backlog theo Hướng dẫn Scrum không thể thực hiện được ở quy mô lớn trên thực tế. Các nhà phát triển – các kỹ sư không phải lúc nào cũng có các kỹ năng hoặc mong muốn trở thành PO của một sản phẩm tồn đọng, ngay cả khi những PO vẫn đang là người chịu trách nhiệm chính. Để có thể bán và tiếp thị một sản phẩm, cũng như phân tích kinh doanh thì đòi hỏi một số tiêu chí nhất định, những điều này các kĩ sư kĩ thuật chất lượng cao không có nhiều, mà đây cũng không phải là cách tốt nhất để sử dụng các kỹ năng và tài năng của họ. Nếu vai trò này có tồn tại hoặc phát triển trong nhóm, thì nhóm đó sẽ tự thân trở thành chủ sở hữu sản phẩm một cách hiệu quả. Tất nhiên, điều này phụ thuộc vào cách bạn xác định Quyền sở hữu sản phẩm và thế nào là Quản lý sản phẩm ở bình diện lớn hơn.
Các phương pháp tiếp cận ở quy mô khác nhau cố gắng khắc phục điều này thông qua các phương tiện khác nhau, nhưng chúng tôi nhận thấy rằng chúng tôi cần một chủ sở hữu sản phẩm với vai trò rõ ràng và độc lập chịu trách nhiệm, còn vai trò của quyền sở hữu sản phẩm là một hoạt động liên quan đến nhiều người. Một khái niệm hoạt động nhóm duy nhất thì không thể áp dụng ở các quy mô khác nhau mà không có sự thích nghi và không có quy tắc nghiêm ngặt đi kèm, mà quy tắc như vậy thì khó mà tuân theo được trong một tập đoàn lớn.
Thông qua nghiên cứu về vai trò của PO, chúng tôi đã nhận ra rằng chúng tôi cần phải mã hóa các công việc thực tiễn trong việc tạo ra backlog. Sau đó, chúng tôi cần backlog để nhóm thực thi và tinh chỉnh. Dựa vào đó, chúng tôi đã tạo một hoạt động có tên là Phát triển Product Backlog xuất hiện tại mỗi Sprint.
Phát triển Product Backlog là hành động tạo ra các hạng mục Product Backlog. Đây là một quá trình liên tục mà trong đó PO cùng với bất kỳ bên liên quan nào sẽ tạo Hạng mục Product Backlog. Các bên liên quan bắt buộc có thể là: Khách hàng, Chuyên gia về vấn đề, Người dùng hệ thống, Đại diện kinh doanh và hỗ trợ từ bất kỳ nhóm nào cần thiết để giúp PO phát triển các mục backlog. Trong quá trình phát triển Product Backlog, tầm nhìn, chiến lược và lộ trình của sản phẩm sẽ được tạo ra, xem xét và sửa đổi. Phát triển Product Backlog sẽ xảy ra vào mỗi Sprint.
Nghe thì có vẻ đơn giản, và có lẽ những người khác sẽ tranh luận rằng hoạt động này không cần thiết vì Hướng dẫn Scrum đã định nghĩa điều này mặc dù ít rõ ràng hơn, nhưng chúng tôi nhận thấy rằng định nghĩa này không đủ tốt vì vậy chúng tôi đơn giản là làm lại.
Tất nhiên, chúng tôi thúc đẩy và cho phép giao tiếp cởi mở và hiệu quả giữa các nhóm và khách hàng thực tế, nhưng thường chúng tôi nhận thấy rằng sự tham gia tích cực của chủ sở hữu sản phẩm thì hiệu quả hơn mỗi ngày, đặc biệt là khi chúng tôi có sự hạn chế về múi giờ, ngôn ngữ và công nghệ. Chúng tôi cũng sử dụng khái niệm chủ sở hữu chính sản phẩm khi chúng tôi có nhiều nhóm làm việc trên cùng một sản phẩm. Chủ sở hữu sản phẩm chính đảm bảo giao tiếp hiệu quả giữa nhiều nhóm và khách hàng, cũng như họ sẽ làm việc với các chủ sở hữu sản phẩm khác để đảm bảo mọi người tập trung vào các ưu tiên cao nhất.
InfoQ: C Suite (Các lãnh đạo cấp cao) đóng vai trò thế nào đối với thế giới Agile?
Thurlow: Sự tham gia của việc điều hành và lãnh đạo cấp cao là chìa khóa quan trọng khi bạn bắt đầu mở rộng số lượng sản phẩm, hoặc số lượng các đội. Tại Toyota Connected chúng tôi mở rộng vai trò của chủ sở hữu sản phẩm lên cấp điều hành và chúng tôi tiến hành hoạt động điều hành Meta Scrum hàng tháng để xem xét tiến độ của doanh nghiệp, nhằm đảm bảo sự liên kết với tầm nhìn và chiến lược đồng thời đưa ra các quyết định ưu tiên quan trọng.
Chúng tôi cũng có một đội ngũ điều hành (EAT), nơi các giám đốc điều hành cấp cao cùng gặp nhau thường xuyên để xem xét các trở ngại (blocking issues) và tự giao cho nhau giải quyết. Điều này có nghĩa là EAT hoạt động giống như một nhóm Scrum, kéo những trở ngại từ các backlog ra và xử lý chúng. Trong việc phân phối nhiều sản phẩm liên kết hoặc các đa giao dịch phức tạp hơn, chúng tôi cũng có thể có một Nhóm Lãnh đạo trung gian (LAT) để giải quyết các trở ngại hoặc thực hiện các hành động xử lý nhanh hơn trước khi nó được chuyển đến EAT.
Nếu bạn không có sự cam kết này, bạn sẽ thấy khả năng thay đổi hướng hoặc thay đổi ưu tiên nhanh chóng bị giảm đi, kèm theo sự linh hoạt và thậm chí cả khả năng cạnh tranh của bạn.
Cam kết điều hành còn cần thiết trong việc giải quyết các tồn đọng của các công ty và tổ chức lớn. Đây là một thách thức đối với các công ty và tổ chức khi loại bỏ sự phát triển của các tồn đọng nhằm bảo vệ sự tồn tại của bản thân.
Điều này cũng khiến quá trình thiết kế dòng giá trị dài và đau đớn hơn, và như Peter Drucker đã từng nói: “Bất kỳ sự đổi mới nào trong một công ty sẽ kích thích hệ miễn dịch của chính công ty tạo ra các kháng thể phá hủy sự đổi mới này.” Để thực sự thay đổi một tổ chức, chúng ta phải tối ưu hóa hệ thống nhằm đảm bảo các dòng chảy giá trị, và điều này đồng nghĩa với việc xem xét lại toàn bộ hệ thống, và thay đổi toàn bộ, nếu cần thiết.
Chúng ta cần phải ngừng việc tập trung vào việc trở nên Agile. Thay vào đó bắt đầu các dòng chảy đồng thời rút ngắn các vòng phản hồi. Và rồi chúng ta sẽ tự khắc trở nên Agile.
InfoQ: Toyota được biết đến với Hệ thống Sản xuất Toyota và Sản xuất Lean. Scrum và Agile đóng vai trò thế nào tại đây?
Thurlow: Scrum, hay khung làm việc Agile chính, dựa trên Hệ thống Sản xuất Toyota (còn được gọi là Lean, một thuật ngữ được đặt ra bởi các tác giả của cuốn sách, “Máy móc thay đổi thế giới”, ấn phẩm chính đầu tiên về cách mà Toyota sản xuất ra sản phẩm) và – theo như tôi được Ken Schwaber kể lại – dựa trên ảnh hưởng của DuPont vào việc áp dụng một phương pháp lập kế hoạch thực nghiệm. Trong thực tế, Scrum đơn giản là một phương pháp lập kế hoạch thực nghiệm, với các vòng phản hồi nhanh được xây dựng nhằm cho phép một số đặc điểm hành vi nhất định trong một nhóm. Nói cách khác nó chính là PDCA được mã hóa đi kèm với các bước quy định rõ về thời gian.
Cần bao lâu để lập kế hoạch, thực hiện, kiểm tra và hành động? Và điều gì thực sự xảy ra trong mỗi giai đoạn này? Scrum đã mã hóa những điều này và cung cấp các quy tắc cho PDCA.
TPS/Lean là tiêu chuẩn vàng cho việc phát triển sản phẩm lean. Việc mã hóa PDCA bằng Scrum đang cung cấp một cơ chế thông qua đó chúng tôi có thể cải thiện khả năng phản hồi của chúng tôi đối với thay đổi, đồng thời còn giúp chúng tôi liên tục kiểm tra và điều chỉnh giá trị mà chúng tôi đang cung cấp cho khách hàng của mình.
Tuy nhiên, Agile không phải cứu cánh cho Lean hay ngược lại; thực tế phong trào Agile cho phép các công ty đã vốn tinh gọn hoặc muốn tinh gọn có thể đưa ra quyết định nhanh hơn. Chúng tôi đang sử dụng các khung làm việc sẵn như Scrum và các công cụ đang sắp được đưa ra bởi Hệ thống Sản xuất Toyota nhằm giúp doanh nghiệp linh hoạt hơn, từ đó phát triển khả năng đáp ứng nhanh hơn với xu hướng thị trường. “Agile không phải là mục tiêu. Nó là kết quả ”.
InfoQ: Nếu độc giả của InfoQ muốn tìm hiểu thêm về Scrum The Toyota Way, họ có thể đến đâu?
Thurlow: Ngay bây giờ chúng tôi đang thử nghiệm triển khai một số lớp học. Chúng tôi vừa tổ chức hai lớp học beta và sẽ tổ chức hai lớp học nữa, một ở Portland và một ở Dallas. Chúng tôi cũng tài trợ cho Agile Camp. Sự kiện ở Dallas đang trong giai đoạn chuẩn bị cuối cùng và sẽ sớm được công bố trên các phương tiện truyền thông xã hội khác nhau của Agile Camp.
Chúng tôi cũng giảm giá 100% cho các cựu chiến binh và các thành viên thực thi luật pháp để họ có thể tham dự và học các kỹ năng mới nhằm tái nhập vào thị trường việc làm, đồng thời giúp họ phục vụ cộng đồng hiệu quả hơn.
Nguồn: https://www.infoq.com/articles/scrum-the-toyota-way
Bạn nghĩ sao về nội dung bài phỏng vấn này ?
Hãy đóng góp cho chúng tôi biết ý kiến của bạn về bài viết này. Đóng góp của bạn sẽ giúp chúng tôi cải tiến nội dung bài viết tốt hơn nữa.