3 ms·
I don't think this post is quite accurate that Royce proposed the model just to critique it. Royce's 1970 paper describes a way of adapting normal project manag
by Zigurd 2y ago
I don't think this post is quite accurate that Royce proposed the model just to critique it. Royce's 1970 paper describes a way of adapting normal project management practice to software.
Royce's criticism of the model touches on the brittle nature of specs in the face of discoveries about performance that mean a project could potentially have to start over.
Agile, however, has a lot more solid basis in the difficulty of estimating software development tasks. Using traditional project management tools, you would do a resource-leveled critical path analysis, which is a very heavyweight way of optimizing who does what and when, which then within a couple weeks is no longer useful because your task estimates suck. Instead you get. the team together every couple of weeks and decide who does what. Rinse and repeat.
Agile works better because estimates almost always suck but that's OK because that doesn't break your exquisiite schedule analysis because you're not making one.
- replyifuagree 2y agoYep and here we are in 2024 and just this last week I got into a heated discussion with an 'Technical' Program Manager raging about how the deliverables are slipping by three days mostly because he and his up chain are heavily invested in a schedule that is built on hope. Not only are the estimates bad, but the resourcing from the different silos has not happened either, so there is tons of unfinished work just on the work that is known, let alone the unknown unknowns! Next up he's about to find out his integration timeline is complete and utter bullshit.
- beastcoast 2y agoTime to get a new TPM. Any TPM worth their salt should be doing everything in their power to catalog and mitigate those risks, and communicate them upwards. Lack of communication in both directions and adversarial conversations with engineers is a whole parade of red flags. That said, Gantt charts absolutely have their place alongside Agile. Our budget and goals are set yearly so inevitably there’s going to be milestones and work back dates to meet, as well as cross-team/org dependencies to track.