3 ms·

We do government contracts. Usually 8 figures. All waterfall (with JIRA and sprints, but it's still waterfall). Agile makes it really difficult to get paid b

We do government contracts. Usually 8 figures. All waterfall (with JIRA and sprints, but it's still waterfall). Agile makes it really difficult to get paid by milestones, and unless you have enough cash to float the entire development team's salaries until the project is finished, agile is not exactly conducive to those types of contracts. I'm not against Agile, btw... I just get fed up with fanboys who are dogmatic about agile being the only, best way to develop software, and yet they have no real-world experience with large projects that must interact with other systems. Agile is great for when you don't know what you want to build. It's pointless when what you need to build is already well-understood and specified by contract.

AnimalMuppet 3y ago
You actually can be pretty agile in a government contract... if your government customer will be agile. That's pretty rare, though. But when it happens, when your customer actually wants and needs that, you can make that customer much happier by being agile. In fact, this is where agile (real agile, not Agile-in-name-only) breaks down. Somewhere up the org chart, it reports to someone who is not agile, someone who thinks in waterfall terms. That impedance mismatch either takes a huge amount of translation work by the person below them, or else it eventually kills real agile, turning it into waterfall with some agile lipstick.
croo 3y ago
+1 with government project this reflect my own experience. (EU) When a project hit a certain size and have a strict budget with hard deadlines (where hard means: political party wants it done before their term ends or there is a time restriction on the budget's availability) agile just won't cut it. You cannot say at the end of the 1.5 year project that 40 programmers and managers worked on that "yeah sorry that last dozen features and 100 bugfixes did not make it to the last sprint". Also when there are several parties and subcontractors involved the "big design up front" stage is not optional anymore. QA is usually a third party who gets paid to find out if everything is according to the functional spec and documentation and enter at the later stage of a project. You simply cannot do agile in such an environment - though of course the documentation will contain the fact that you are indeed agile :D

AnimalMuppet 3y ago

You actually can be pretty agile in a government contract... if your government customer will be agile. That's pretty rare, though. But when it happens, when your customer actually wants and needs that, you can make that customer much happier by being agile. In fact, this is where agile (real agile, not Agile-in-name-only) breaks down. Somewhere up the org chart, it reports to someone who is not agile, someone who thinks in waterfall terms. That impedance mismatch either takes a huge amount of translation work by the person below them, or else it eventually kills real agile, turning it into waterfall with some agile lipstick.

croo 3y ago

+1 with government project this reflect my own experience. (EU) When a project hit a certain size and have a strict budget with hard deadlines (where hard means: political party wants it done before their term ends or there is a time restriction on the budget's availability) agile just won't cut it. You cannot say at the end of the 1.5 year project that 40 programmers and managers worked on that "yeah sorry that last dozen features and 100 bugfixes did not make it to the last sprint". Also when there are several parties and subcontractors involved the "big design up front" stage is not optional anymore. QA is usually a third party who gets paid to find out if everything is according to the functional spec and documentation and enter at the later stage of a project. You simply cannot do agile in such an environment - though of course the documentation will contain the fact that you are indeed agile :D