3 ms·

I'm a current DoD contractor (the coding type) and the agile/waterfall mentality still holds up. Different departments and different projects within each depart

I'm a current DoD contractor (the coding type) and the agile/waterfall mentality still holds up. Different departments and different projects within each department will have different methodologies for planning and delivering products. However, where I am, there is a huge emphasis on "getting shit done" well ahead of schedule. I'm lucky to work with smart and motivated folks who together, work well and we are wildly successful. My biggest gripe, shared among many of my coworkers, is the level of micromanagement. Multiple business analysts, product owners, stakeholders, SCRUM masters, managers, etc. who all share essentially the same job - delegating and scheduling work. It makes every project 10x more difficult and complex than it otherwise should be. An example just from this past week: Project A: we are delivering a single product. Three managers, two SCRUM masters, multiple business analysts. We engineers have four different JIRA/task-boards to keep up with. All of them overlap, three of them are essentially the same board in different spaces. Each day we have 2-4 hours worth of meetings spread across stakeholders amongst those three boards where we regurgitate the exact same information. It's repetitive, backward, and a time-waste. Some engineers are currently "revolting" by saying what I'm saying now - in the meetings themselves. We've had multiple blowups with management. Having meetings and discussions spread so wide leads to a lot of confusion because us engineers appear to be the only conduit with which the analysts and managers are communicating. Often times, the different stakeholders will ask for the same features in different meetings, other times they ask for different or conflicting features which leads to confusion and the need to schedule more meetings to clarify as they are not communicating amongst each other.

sirsinsalot 4y ago
The issue I found in defence, when your software integrates in to a very large engineering project with a mix of hardware and software is that often times waterfall is appropriate because everything has to be decided upfront where possible. For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing. Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design. Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed. Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes. In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit. Our little bubble is agile in a waterfall world.

sirsinsalot 4y ago

The issue I found in defence, when your software integrates in to a very large engineering project with a mix of hardware and software is that often times waterfall is appropriate because everything has to be decided upfront where possible. For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing. Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design. Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed. Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes. In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit. Our little bubble is agile in a waterfall world.