Disclaimer: My job title is "LEAN architect", so I might be biased here. The point is, "agile" emerged from accepting that building new things primarily deals

Disclaimer: My job title is "LEAN architect", so I might be biased here. The point is, "agile" emerged from accepting that building new things primarily deals with the uncertain. You plan something, and then there are the "unknown unknowns" where things will take orders of magnitude more time than planned. Additionally, more often than not it isn't even clear how the solution actually looks like or if the stakeholders even articulated what their real problem is. So the solution: just start with something and then establish a short feedback cycle to steer the next steps in the right direction, which wasn't obvious in the previous cycle. Therefore all the ceremony, like doing daily standups to resolve problems that arrive while iterating the problem space, or retro/review where progress gets presented and the next steps are agreed upon. The heart of the principle translates to "be flexible" in the face of uncertainity. This also implies that the team is trusted to decide on the spot. In reality, "Agile" often comes in the form of something like "Scrum", which isn't agile at all. There is ceremony and cargo-culting how one should behave without any understanding _why_ to do things. Management gets sold the idea that they get a tight grip on all decisions (Micromanagement) and can closely "watch how workers perform" with a short feedback loop. Because "we cross the bridge when we come to it", all the "engineering" parts of software development are thrown out of the window and essential things like caring about sound architectures/maintainability/... are supressed. This gets even more emphasized with the usual mindset of "Velocity", translating to managers as "build more features faster, now!". This in turn leads to some early successes but mostly turns into swamps of unmaintainable glue code and after a while the voices wanting a "rewrite" become louder... back to square one. Oh, and do not forget that "Backlogs" (especially with months/years ahead planned and communicated with stakeholders) are just chunked Waterfall processes without any flexibility, ironically killing actual flexibility. Daily standups become just virtue signalling happenings where everyone agrees that they're "on schedule" or "things will take longer". There ARE teams that deliver high-quality solutions without getting slower over time using Scrum, but know what? These teams would achieve the same with any process, including some internal Waterfall variations. Great/experienced people deliver great results, even more so if they can act autonomously. So instead of some magical "Agile Processes" that everyone has to follow and great results will appear (in reality: they won't), my job is to increase the chances for actual success in the real world. How? by following some LEAN values (instead of processes). But here is the next catch: there are huge misunderstandings about LEAN when it comes to software development! Classical "LEAN Production" comes from a world where physical things are manufactured in large numbers, basically doing the same thing again and again, and tries to optimize how to do this thing better/faster/cheaper. In software development the root problem is inversed: we are never actually doing the _same thing_ more than once (except cases of reinventing the wheel). All attempts to use classical LEAN Production techniques to software projects will fail miserably (except you have awesome people to begin with, see above). Then there are the "Lean Startup" people which start with the actual problem space and cycle in "build measure learn". Makes absolute sense if you are a startup and have to find _something_ that sticks. The problem: teams that act like this are doing the job of actual business founders and require the trust to change the business itself. This doesn't work within a traditional company when you have executive teams and a management hierarchy. So what could be done if these things don't work? Dig deeper and formulate _values_ everyone should follow. Examples: - "decide as late as possible" -> do not lock yourself in hard technical dependencies (this will only run with MariaDB v123 on Google Cloud with Setup ABC) early on, or else you will have a hard time being flexible (like migrating to AWS Lambda because some compelling technical/business reasons). Yes this way is not able to leverage minute features of a ultra specialized solution, but chances are high something generic will do (like: we need a sql database) - "build quality in" -> in many cases it does _not_ take significantly longer to build something that is well-tested, decoupled and documented than to hack something together, especially when you are building it right now and have all requirements in your head currently. In fact, most code that is designed with maintainability is more on the side of an asset (you can build on it) instead of a liability (should be replaced in the future/does not get used because noone understands it or its purpose/... bitrot.). So when your building blocks are actually solid, you may even become faster, which often shows in mere _weeks_ after a project starts. - "Eliminate Waste" -> the posterchild value of LEAN... but the quintessence. Everything that prevents the team/individual to make relevant progress right now must be stopped. Relevant progress is anything that produces value for the customer (read: _not manager_!). Waiting hours for feedback if a code snippet works? Make it fast. Sitting in pointless meetings or ceremony processes? Cancel them. Deployments/Builds need mental energy to execute? Automate it. "Feature Ideas" from managers? Let them prove that it WILL bring customer value, ideally: how much. Can't stress this enough: do not build anything that does not clearly increase customer value, no matter who demands it internally, never follow the "what if..." rabbit hole or you end in feature creep and potentially dead code areas that still cost maintenance. ... and so on. You can google more infos about "LEAN Software principles: if you want. The main takeaway: act based on clearly defined values _enables_ actual agility, acting based on arbitrary processes (like Scrumfall) _decreases_ actual aglity. But even this (my) approach has a big downside: success is measured in ... success. Whatever the Team does, they must show that there is a measurable business impact, or share why something failed (so that bad ideas will not get tried again later... and again...). This is a stark contrast to the "virtue ethics" approach many are happy with, where "trying with best (displayable) effort" is good enough and gets rewarded. I will just look at the outcome: what did you do, was it executed as good as possible within given constraints, and which impact did it have, followed by the question: what did you learn and therefore what is the next logical step? Many people still prefer to work without the "pressure for success" for 8 hours per workday and go home, where working is just the thing one does for earning money. No issues with that, but chances are even LEAN will not work when you only have people with this mindset. Not disciminating, just my experience.