3 ms·
I have an idea on this, and I'd appreciate your feedback and opinions on that. Could it be that agile projects fail more often (or take longer to complete) bec
by martin_a 2y ago
I have an idea on this, and I'd appreciate your feedback and opinions on that.
Could it be that agile projects fail more often (or take longer to complete) because people with a different "mindset" are able to work on projects like these because they are being enabled to do so due to a different "way of working"?
Example: We have a shop relaunch going on and marketing is in the lead. Project is almost double over budget and at least two months over time, they fail so set clear expectations and requirements and there's sprint after sprint after sprint to get things to a release-ready state.
Without agile project management this relaunch would have long been counted as a fail and consequences would have followed OR marketing wouldn't have been in the lead because they would not have been able to set expecatations and a clear goal from the start on.
Any ideas on that?
- mrcartmeneses 2y agoThat’s pretty much the entire promise of capital A Agile (Scrum, Safe etc). It provides a framework for people without any knowledge or passion for software development to micromanage software engineers while ignoring agile principles and not bothering to conduct user research or to investigate product-market-fit or do anything else that might be worth doing other than creating extremely loose requirements they pulled out of the ether on a bi-weekly basis. The argument used to refute this is usually that people aren’t doing agile right and if only the people and companies were more competent and or did MORE Agile then things would be fine. Generally speaking successful tech companies don’t often put unskilled dispassionate middle managers in charge of software projects and don’t often use Agile processes Software development is a lot like photography. If your work sucks it’s because the engineer/photographer isn’t close enough to the subject/user/business goal. Agile tends to silo engineers away from their ideal motivations (users/business goals) in favour of meeting the needs of the egos of management. One case in point was a hedge fund who had increased their engineering team by a factor of 10 because they couldn’t get any work done after the Agile people took over. Their productivity had stabilised at a pre-agile /10 level. I was part of a group of consultants brought in to build them something because they were so unproductive. The consultancy’s solution was to do MORE Agile. So we ended up building a large but not very useful set of features instead of doing the smaller, more technically complex and much more useful feature. We completed the work on time only because of the generous bonuses offered to the outsourced developers. I believe it was unlikely to be worthwhile for the hedge fund.
- martin_a 2y agoInteresting information, thanks! > The argument used to refute this is usually that people aren’t doing agile right and if only the people and companies were more competent and or did MORE Agile then things would be fine. > Generally speaking successful tech companies don’t often put unskilled dispassionate middle managers in charge of software projects and don’t often use Agile processes But do you think this problem is inherent to the agile process itself? We (as in "more technical department") manage to get our things done on time and budget with the same external agency. It might be due to us formulating clear expectations and behaviours and iterating over improvements, but I'd say this whole process of "lots of little steps" works fine for us. On the other hand, when I think about it right now, we might be doing fine with a more traditional project management process too, because we are able to set expectations... Hm... not sure...
- robertlagrant 2y ago> Agile tends to silo engineers away from their ideal motivations (users/business goals) in favour of meeting the needs of the egos of management. No idea where you get this from. I've never seen teams closer to customers than with agile thinking. Waterfall with a programme manager at the top setting the timeline, the budget and the features, an army of business analysts getting between the team and the customers, and project managers making GANTT charts - you don't think this silos away information?