AITOW

nning of working this way. Or yes, there may be unexpected things along the way. And this is all completely fine. (This last point was a late addition to the manifesto: but I _think_ made before your comment) Can you give a bit more detail on the destructive aspects though? If you mean if an organisation follows this, then it ends up as a stick to beat developers with if they don't deliver value every day? I guess my counter to that is, if management is toxic, they will always find a stick to beat developers with, no matter what. What the manifesto does, or at least tries to do, is encourage developers to think about how larger pieces of work are tackled - so they end up really understanding what the problems are, and so engineer solutions to them appropriately. Wherever possible getting feedback, and if possible on a cadence of at least daily, to me seems such a good way of doing this - but do you have a better suggestion? Edit: I see https://github.com/rayfrankenstein/AITOW and have started to give it a read… and… wow. I certainly understand where you’re coming from, and I would hate to see “Deliver value daily” make all these situations worse. I think I’ve been really lucky - only maybe experienced light versions of the worlds described, and in the past few years have worked in a very supportive environment and had a lot of autonomy. In this environment I/my team decide on a lot, including ways of working like how to tackle bigger pieces of work. And in such an environment, “Deliver value daily” I think can really work, and essentially has. But I think I am sticking with my point - I suspect toxic management will find any excuse, and the three words “Deliver value daily”, will do little to change that. Although - I am tempted to make it clearer up front that autonomy and a supportive environment (and maybe other things?) are crucial, to try to at least limit how it could be “misused”

is, like, two years or something. And the environment is often very adversarial. You can't ahve 4. Japanese manufacturing focused very heavily on having very high quality vendors that make stuff that didn't require a lot of debugging. There was a heavy focus on part re-use in other designs; the same engines would be used in different generations of different models for years. The software equivalent of this would having a fully fleshed out, batteries included stack where little custom-invention would be required because the API's are just so damned good and comprehensive. How many times have you gotten a Not Invented Here or "that's too opinionated for my taste" approach from leads?

that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything. I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova. I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...