Topic: Mindset and culture
As the adoption rate of agile and lean methods gains momentum, it becomes increasingly difficult to ensure everyone involved has an accurate understanding of why the various practices work and how they complement each other. Few organizations have a sufficient number of people at the level of team leads and project managers who are knowledgeable about lean and agile methods. They have no choice but to assign traditionally-minded managers to their lean and agile projects. All too often, these managers believe they know exactly what to do and are not open to advice. After all, they have experience with IT projects already, and everything in that experience tells them that every new methodology is pretty much the same as all the old ones.
There is a tendency for traditional thinkers responsible for agile projects to try and "rein in" agile methods by "controlling" them with a traditional management process. I have seen this phenomenon at my present employer on some of our more recent projects as our internal agile practice has grown faster than our ability to keep up with training and recruitment demands. This approach offers an illusion of control, but actually breaks the natural rhythm of agile work in much the same way as a marathoner's natural rhythm would be broken if his/her "manager" paused the race after every third step to assess the condition of the runner's shoes.
Similarly, traditional thinkers responsible for lean projects often try to make their processes "more agile" by compressing the timeline and overlapping phases that should be kept sequential. Although they are iterative and lightweight, lean methods remain dependent on process-centric controls like those of traditional waterfall methods. The waterfall phases within a lean iteration must be followed sequentially so that a formal transfer of information can occur at the phase transitions via quality gates, code reviews, formal documentation, and so forth. Overlapping the phases removes the opportunity for formal information transfer, but at the same time the process-centric management style fails to compensate by replacing it with the direct communication and collaboration of "pure" agile methods.
A common result in both cases is the process anti-pattern known as the Staggered Iterative Waterfall. I've seen this happen myself at my present employer, and I've read and heard many anecdotal reports of similar results at other companies. I explore the causes for the problem in a new article, Slouching Towards Waterfall.