In the last couple of posts I've tried to analyze why quite many programmers reject agile even though the agile manifesto should be a program of emancipation for programmers written by programmers out of decades of experience of programmers. In my experience it is not that programmers renounce any of the proclamation of the agile manifesto; it is only that they dislike some of the changes that happen when an organization tries to become more agile. Agile is not an unbreakable monolith, but a set of values, principles, and practices put together into a coherent framework. Not all of these building blocks cause discomfort to programmers. The daily meetings and demos have been performed by good programmers already in the heydays of waterfall. Empowered teams of emancipated programmers led in a democratic fashion has always been the most efficient way of organizing knowledge workers. And letting the process be implemented by those who practice it, either through retrospectives or in any other way, is the most effective way how to introduce meaningful change in any organization, not just in software companies or startups. Finally, having a product development process in place that makes sure the company builds the right product is much more important for the success of the company than building the product right.
Only after we introduce iterations (XP or scrum) or work in progress limits (kanban) the pressure starts to build in the team and things start to explode. I think that it makes a lot of sense to well prepare the team and the organization by introducing practices described in the previous paragraph first, before putting a lid on the pressure cooker that is your team by introducing iterations or kanban limits.