3 ms·
I wonder if this thread has fallen into the trap of talking about the fashionable stuff instead of what is actually in use...in the same way a newcomer to softw
by jimnotgym 9y ago
I wonder if this thread has fallen into the trap of talking about the fashionable stuff instead of what is actually in use...in the same way a newcomer to software on HN might be forgiven for thinking that the majority of software is written in Node or Rust, and rather underrepresented the amount of Java actually in use.
When I hear Agile, experience has taught me to suspect that these guys don't spend enough time writing requirements. In the mid market web agencies Agile is a synonym for 'we don't do project management.
I visited a software company recently who are still using a lot of VB6(!), and they are having a big drive to modernize. But instead of finding a new GUI framework they just employed a Scrum-master to re-arrange the deck chairs on their Titanic and some ex-Oracle sales guys to paper over the cracks.
I suspect in the UK, if you are to be engaged on a project to implement a new feature for an enterprise customer like a bank, or you are in a mixed hardware/software environment you may see Kanban/Agile for little sub-teams, but the actual project will be running under Prince2.
Prince2 is how you do projects in UK enterprise/government, and if you are writing software as part of an enterprise project you will be under Prince2 as well. However Prince2 is pretty flexible about letting you run individual tasks the way you want, don't expect to be able to reshape requirements on the fly without having to justify how that affects the 'business case'
I would be interested to hear if that was not anyone else's experience?
- firegrind 9y agoITIL is common enough, as are less formal strategies adopted by project delivery teams, departments and more lateral communities. Without organisational support for agile adoption, from C-level down, agile is very unlikely to be successfully implemented because at some point the team who collectively contract to deliver a testable result in a sprint will derail, or be derailed by a conflicting schedule. I guess it's the same phenomenon that was observed when people noticed that the waterfall software lifecycle was more of a spiral model, and started exploring Rapid Application Development techniques. There's nothing new under the sun.