Apply Agile trong những tổ chức thuần túy Waterfall
~ By Sonal Shah
https://www.projectsmart.co.uk/agile-through-the-waterfall.php
Nhiều tổ chức đã thực hành Agile, đưa Agile vào trong phương pháp luận phát triển và họ đã chứng tỏ được sự thành công của việc áp dụng này trong cả tổ chức. Cũng có nhiều tổ chức khác, họ có khá nhiều người muốn “làm Agile”, nhưng họ không thể có đủ động lực để có thể giúp Agile được thực hành rộng rãi trong toàn thể doanh nghiệp đó.
Gần đây tôi đã có cơ hội tham gia vào một buổi Open Space, ở đó chúng tôi đã tìm hiểu xem các tổ chức mà đang chủ yếu thực hành Waterfall, lại đang “vô tình” thực hành một số practice của Agile như thế nào.
Tôi thấy rằng phần lớn các dự án đang được coi là “top priority” đối với tổ chức, thường lại được ưu ái sắp xếp vào 1 phòng của team riêng (co-location). Rất nhiều team lúc đầu sẽ phản kháng lại các setup kiểu này, nhưng rồi họ nhanh chóng nhận ra khả năng hợp tác (collaborate) và tung hứng các ý tưởng cho nhau (bounce ideas off) khá là có lợi cho sự thành công của họ – đối nghịch với việc các ý tưởng bị đá qua đá lại khi họ ngồi ở nhiều nơi khác nhau. Team co-located đó có thể brainstorm các ý tưởng và nhanh chóng quyết định loại bỏ hay thực thi bằng cách thực hiện những mini-PoC (proff-of-concept) cho phép họ hiểu rõ giải pháp và hiểu ra đó có thực sự là hướng giải quyết hợp lý để theo không. Tôi cũng thấy rằng việc giao tiếp giữa các nhóm ngồi gần nhau – neighbouring groúp – được cải thiện rõ rệt, qua đó tăng cường mối quan hệ cross-functional giữa các team đó.
Các team cũng có thể tự xây dựng những concept về daily scrum/daily standup. Một lần nữa, ban đầu sẽ có những sự khó khăn để tiếp nhận. Nhưng theo thời gian, khi dự án tiến triển dần, những buổi họp daily đó dường như trở nên cần thiết để định hướng công việc trong một ngày. Daily scrum/daily standup cũng giúp đưa ra các giải pháp để giải quyết các issue nhanh hơn rất nhiều so với phương pháp truyền thống. Thực tế có PM đã được bảo rằng, khi cô ấy không có mặt để chạy standup, thì team cảm thấy lúng túng khi thiết lập mục tiêu trong ngày.
Một quan sát nữa mà tôi nhận ra là phần lớn công việc được tạo ra bởi team đó thường được test ngay lập tức bới chính team ấy hoặc bởi những dedicated tester (tester chuyên trách). Từ đó, các giải pháp được cải thiện thường xuyên liên tục (continuous improvement – kaizen) và chứng minh được tính khả thi của nó.
Tôi đưa ra những item ở trên, chưa hoàn toàn thỏa mãn các yêu cầu về phát triển theo Agile, nhưng tôi tin chúng đều nguyên tắc quan trọng, hay đúng hơn là nền tảng, của một tổ chức đang mong muốn trở nên Agile theo dạng này hay dạng khác. Đây mới là điểm bắt đầu, của một tổ chưc đang sẵn sàng chấp nhận thay đổi để toàn tổ chức đó trở nên thành công.
Tôi mong muốn được biết nhiều hơn về quan sát của bạn, đặc biệt từ những tổ chức mà bạn đang sống trong đó, và nghĩ rằng “Agile is Fragile” (Agile là mong manh) và có thể gặp khó khăn trong việc đêm Agile concepts vào tổ chức “cứng đầu” của bạn.
Many organisations have adopted Agile practices into their development methodologies and they have proved to be successful for the organisation as a whole. There also are many organisations that have pockets of people who wish to be Agile, but can’t get traction within to make it a widely accepted practice throughout the enterprise.
I recently had an opportunity to participate in an Open Space session where we explored how organisations that are mainly guided by Waterfall methodologies, unwittingly also employed Agile practices.
I observed that most projects that were considered “top priority” projects for an organisation typically had the luxury of being situated into a team room. As much as the team initially resisted this set-up, they quickly found that the ability to collaborate and bounce ideas off of each other was quite beneficial to their success versus being bound to the walls of their cubicles on various areas of the floor. The team was able to brainstorm ideas and quickly rule them in or out by conducting mini-proof of concepts that allowed them to understand the solution in more detail and determine if it was a logical path to follow. I also learned that the communication with neighbouring groups improved; therefore, strengthening their cross-functional relationships.
These teams also had some home grown concept of a daily SCRUM or stand up. Once again, there was initial resistance. But, as the project progressed, these daily “meetings” seemed necessary to set the direction for the day. They also helped bring resolution to issues a lot faster then the traditional methods. In fact, one project manager was told that when she wasn’t present to run the standup, the team then found themselves floundering on their targets or goals.
One last observation that I made was that most of the work produced by these teams was immediately being tested by the team itself or by dedicated testers. So, the solution was continuously being improved and proven out.
I realise that the items discussed above don’t fully satisfy a complete Agile development shop. However, I believe they all are tenets, or rather the foundation, of an organisation that is willing to be Agile in some shape or form. This is the beginning, of an organisation that is willing to accept change to make the entire organisation successful.
I’m interested in hearing more about your observations, especially from those of you who are currently in organisations that think “Agile is Fragile” and may be challenged with slowly introducing Agile concepts into your resisting organisation. Please post your comments, so we can expand the thinking into a collaborative effort in defining if Agile truly is visible “through the Waterfall.”
