Regardless of intent or documentation, I’ve never come across a methodology that didn’t devolve into the same practice as every other methodology. The root problem is that the people who are looking for a methodology/silver bullet are convinced — and no amount of reality will ever convince them otherwise — that software development can be done with 100% predictability, just like, say, adding a garage to a house. So even XP, that explicitly states up front that this is not possible in software, gets morphed into “agile” which is actually a great way to manage predictable development tasks, but a horrible way to manage software.
Adding a garage isn't predictable either. You think you have good as-built drawings, then it turns out your house has creative electrical wiring that you have to deal with first, or your shingles don't show up on schedule, etc.
Any non-trivial project with external dependencies is going to have to be able to adjust when things don't go as planned.
Software development might be worse and it's worth trying to improve, but it's far from unique.
Here's an example of that: when I built a house, we had the following characteristics:
1 A geotechnical exclusion zone at the front of the house whose exact location was unknown.
2 Three strange angles (one for solar access, two marking out the block size) making measurement tricky thus tricky locating the exclusion zone.
3 A brick house base and a steel frame to go on top. There was 5 centimetre tolerance for the location of the steel beams.
Get #1 wrong, and start building all over again.
Get #3 wrong, and it's time to re-fabricate the frame.
Could have been costly. Went well but took a lot of care, attention and coordinating across 5 groups of contractors.
As a side note, one of my occasional hobbies is performing super-sketchy surveying methodology. It turned out that my extermely non professional, totally un-certifiable methodology was within 10cm of the actual exclusion zone (whose length is around 10 metres from the front of the block of land).
I feel you have just described the role of management in software development. Management has to compile weekly/monthly progress reports and give estimates of when development will be complete. Then the testers can start doing their thing before the rollout teams start training end users. In big corporate companies, there are many people downstream from the developer who needs to be kept informed of development progress. Management needs a methodology to follow and include in their slides. Something that sounds official and has been proven somewhere else.
Well, you just described waterfall. And the track record of trying to compile accurate progress reports, only starting testing after development is ”completed”, and only involving actual users in a one-way communication... is not exactly great.
No, I have not described the waterfall method. I have listed the role players and processes associated with software development in a big organisation. Perhaps I wasn't clear on what I meant by testing which is a broad term which includes piloting software. Testing in a POS environment involves piloting out the POS software to a limited number of stores and letting it process actual transactions for a period of time. The perennial question which no one has been able to answer definitively is how do you align everyone with the software development process. You cannot roll out software without testing it and writing out a manual whether you use waterfall method or Agile.
There is a move away from the capital 'A'gile processes in use with agile as an adjective to describe how you approach problems and the development process itself should be fluid.
So the answer seems to be use agile to find a fit, or if that doesn't fit other organizational requirements/abilities, then choose the least poorly fitting process.
Software engineering can be much more predictable than it is. It isn't in practice for primarily two reasons: most software projects simply don't need the rigor, and the fraction of developers who think their ability to write a working program makes them smarter than everyone else to the rest of us is quite high.
As someone who is renovating their house: home improvements are not 100% predictable. Although I admit they are easier to predict than software, and easier to explain in layman's terms why something went over the expected time or price.
The big difference is building work can be repeatable, the people that built the garages on the housing development behind me did the same job for each of the 39 houses.
Development is never really like that, why would you write another JSON parser if you already did it yesterday.
To be fair to those who add Garage's to houses, you can't do that with 100% predictability either. Nothing slows down an addition like digging the foundation and hitting a unknown oil tank.
