3 ms·
In my experience it has been due to several glaringly obvious oversights and blunders. 1) Not empowering developers by blocking access to critical resources, b
by temporallobe 9y ago
In my experience it has been due to several glaringly obvious oversights and blunders.
1) Not empowering developers by blocking access to critical resources, basically walling them off in a tightly-controlled box and still expecting them to do their jobs because "they should be able to figure it out". Ridiculous shit like no admin rights, strict enforcement of specific tools,etc. This is usually due to an IT or security department with a inflexi,no fucks given, block everything attitude.
2) Not hiring a strong architect who has the vision for project and the power to make major decisions. So many organizations don't think this is necessary and often have someone in management play this role.
3) Having a weak management team that won't stand up to the customer to tell them what can and can't be done, and not letting them dictate how to do technical things.
4) Skipping or not enforcing basic well-established engineering practices such as design, testing, peer review, etc.
5) Using ill-advised "solutions" platforms that are not intended for engineers but for business analysts with some tech background. These platforms are sold to government and enterprise by used-car-salesmen-like sleazy marketing departments that straight up lie about capabilities or omit huge faults or inabilies. Stupid and/or tech-ignorant management buys this shit and it's crappy, expensive licenses for years to come. They can't get rid of it because of sunken costs, etc.
6) Fear of anything open source
7) Inability to find good, reliable talent -- anything from engineers to testers to tech writers (and who actually have good English skills). Many, many people I work with are great engineers but have such poor English skills that I literally can't understand a thing they're saying, even in an email.
8) Management or stakeholders straight up not giving a shit and letting the project die due to personal problems, infighting, interpersonal issues, corruption, etc. This I would say is the most important issue.
- Joeri 9y ago9) Letting the sales guys write the spec, in the form of a powerpoint. 10) taking estimates from development and lopping off a big chunk plus adding extra scope, because “I couldn’t sell the original estimate” and “this project will be a great reference, so we can take the hit” 11) doing agile in the sense of changing scope / direction constantly, but requiring complete timelines for project delivery to check planned vs actuals. 12) the perennial favorite: having multiple managers who are too busy to talk to each other but not too busy to give conflicting instructions.
- temporallobe 9y agoOh God #10. I currently work for a project manager like this. He asks for LOE, and he rejects it, saying there's no way it could take that long. Then we'll be halfway through development, then told that in a week we're gonna go to production because that's what he promised to the stakeholders. He basically lies is ass off about delivery dates, then blames the devs for not delivering on time.
- jakub_g 9y agoMost of the points above are very true, particularly 3,5,7,9,10,11 from my experience. Additionally: 13) POs and devs accepting feature requests that don't add value but add a lot of complexity 14) Team members who add negative velocity and lower morale of everyone else in the project (but typically are highly regarded by the management who dismiss any complaints) The core IMO is that most people (especially non-technical, but technical too) can not properly understand the complexity of a software project as it's not something tangible like a building or a bridge.