"Individuals and interactions over processes and tools" The issue I have always had here is that in order to go fast and have short cycle times you need quite

"Individuals and interactions over processes and tools" The issue I have always had here is that in order to go fast and have short cycle times you need quite a bit of automation and the more you rely on automation and make it work the easier it is to maintain iterative agile development. That requires processes and tools maintained and the more you rely on individual personal preferences and nuances the longer those cycle times will be. Once you get down to continuous delivery you don't have much choice but to have automated tests written for everything, the basis of which might have been a fantastic interaction with a stackholder with a good back and forth on the right tests, but its far too reductive to just always value people over process when solid engineering is critical to low cycle time for software agility. It seems the manifesto was written from a contract interaction perspective for consultants. With the product mindset however these types of scenarios are a lot less common but the engineering doesn't go away. Its just one aspect that has annoyed me where Xtreme programming got more into defining what a good project actually ought to be able to do and the sort of processes that were necessary to make it work even if some of it was flawed it hung together better than a set of values.