So you were promoted as a project manager some years ago. You have also educated yourself on (PMI’s) golden triangle (scope-time-cost) of project management, and you have “successfully closed” your projects over the years. Now you hear a lot about Agile (project management) as a new way of managing projects! Some claim that Agile doesn’t care much about documentation, hence maybe no documentation! Others claim that the team manages everything, hence no need for managers to “monitor and control” scope or time commitments! Ah – why so many variations in understanding of agility in managing projects?
You know that you had kept your project schedules based on your team’s availability, and you have aligned your schedules with your planned projects to meet your stated scopes. You have managed your projects to meet milestones by “monitoring and controlling” your planned project tasks and deliverables. Then you took training courses about Agile (or Scrum for that matter) where you were challenged with much conflicting information about Agile project management. Add to the complexity if you are a hardware engineering manager where (by experience), you “know” that “time boxing” and short iteration of developing hardware projects will not work!
I have heard many surprising statements from a few hardware (and software) engineering managers. They even persisted on their claims until we further discussed on how Agile (as mindset) would offer many desired results if we apply its principles and values “correctly”.
You see, it’s really easy to learn about Agile in a short training course or workshop. Our experienced managers have had their success in leading their teams using proven structured PM methodologies. There is a reason for the success of PMI Body Of Knowledge (PMBOK), or ITIL, PRINCE2, and the others. Statistically, however, structured (or waterfall) project management yields fewer success rates as tight “command and control” creates slippage in time, or scope, or budget (refer to many online reports by simply searching online for statistics about the success rate of waterfall projects).
When examining change management in any organization, leadership tends to evaluate all possible Agile frameworks that are adaptable in the organization. In one of my (introduction to Agile) workshops I briefly outline the characteristics of over 16 different Agile frameworks and practices. I have always said that there is no magic wand and one-fits-all framework to agility at work. Agile change management is to produce values based on customers most desired needs. I think Agile team building is much like building a community of cross functional members, much like a village where community members roll up their sleeves to build their village. A coach is holding the lantern to brighten possible ways of doing things and helping others when needed.