I've been brought in to rescue a number of projects in my career as a project manager. If there is one pattern that I've noticed between them, it's that the former PM in charge was essentially an Agile zealot. This is someone who has usually done more reading than managing. They fail because they try to apply exactly what they read in the books or blogs without really understanding the underlying principles and goals of what they are trying to accomplish.
The very nature of Agility is to be able to adapt to the circumstances of the project and environment. One form of the zealotry comes when a PM, fresh from reading a pile of blogs or from a conference, decides to come into a new project and implement a whole bunch of nifty practices that they learned. They won't attempt to explain why they are doing what they are doing, and in reality they may not truly know, outside of an intuitive feeling that it would be a good thing to do. Ultimately the practices may not fit in the project or environment that they are working in, but they will continue to stick to their guns, saying things like "this is a best practice that has worked elsewhere". That might very well be true, but are the circumstances the same?
The biggest offense I've seen is the implementation of the self directed team, or rather the lack of implementation. The PM takes the principle of the self directed team, and looks at it as a self-implementing mechanism. Literally, they think by leaving the team to their own devices they will figure out what the best process is for themselves. The problem is that the team will spend a lot of time spinning their wheels, detracting from their true mission of developing valuable software.
The approach I have found to be far more successful is to get the project team up on their feet, with a set of agreed upon principles and known best practices to get started, and then once up and running let them shift direction as they see fit. I've often described this as "priming the pump", but my colleague Tiffany Lentz uses the term "putting on the training wheels" which I think is a more appropriate analogy. The retrospective is the mechanism that allows the team to make their adjustments, and should not be discounted. Most people are better at critiquing than creating anyway.
Making is Part of Design
1 week ago