As someone who has worked in Project Management of Bridges, Enterprise ERP transformations and everything in between, there are definitely benefits in certain u

As someone who has worked in Project Management of Bridges, Enterprise ERP transformations and everything in between, there are definitely benefits in certain use cases. It really comes down to the type of "thing" being delivered and how to deal with the inherent risk. Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff. It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails. Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful The two things I often see in agile projects/organizations that are often done poorly and lead to failure are: - Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design) - Not allowing for or tracking risk mitigation, or how residual risk is trending - Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods) - Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).