|
I think that you bring up a great point regarding a hybrid between agile and waterfall, within the context of government. This is my own experience, but I was involved with a multi-year project for a federal agency that did exactly this. I think what many people don't understand is that the design phase is a byproduct of the internal processes necessary for even getting to the point of developing a system in the government. What I mean by this is, systems don't appear within based on good ideas or pitch decks, they start with policies, and based on those policies, procedures. Why is that necessary in government? Because typically, there are laws, executive orders, regulations, and various other policy devices that have to be implemented at the agency level, there is a review period that allows for input from affected external agencies, etc. In some cases, there is even involvement from congressional committees and their staff members. This is especially true if appropriations are necessary for funding a program. I can honestly say it took a year and a half just to develop the policies and procedures, to coordinate them, and to begin work on the system. That was ridiculously quick, given the scope of the project. The good thing about doing it this way, is you have a very clear roadmap at the outset. The downside is, the process for making significant changes to the system's functional requirements can be a challenge (e.g., changes to policy/procedures, another review period, etc.). That being said, once we actually began the development phase we took a much more agile approach. We would hold daily stand-ups, regular testing/feedback sessions with customers, established product owner(s), etc. I would say it worked really well, but it was not without difficulties. Those difficulties are far bigger than agile vs. waterfall though, it's just the way the bureaucracy functions (for better or worse). |