CYBERSECURITY AWARENESS MONTH
Save up to 60% on books, eBooks, and video training with discount code SECURITY. Learn more.
With the recent introduction of an Agile Certification for project managers, the Project Management Institute (PMI, home of the Project Management Professional or PMP cert) has upped interest in and attention to Agile development methods, tools, and rhetoric. Here's where I weigh in on the topic, too.
Agile Development techniques are not new -- they've been around for over a decade now, if you want to count this phenomenon from the famous Manifesto for Agile Software Development (February 2001), longer if you want to hearken back to early ideas on incremental and iterative software development techniques. But Agile methods are moving outside of development into the more general realm of project management. With the Project Management Institute conferring its blessing on the approach through a recent announcement of a PMI Agile Certification (see my recent IT Career JumpStart blog on this credential at "PMI Now Offers Agile Certification"), this approach to management and delivery of all kinds of work product should increase its status from cult superstar to generally accepted methodology.
In thinking about the issues that many project and development managers face in changing their ways of thinking about scheduling, monitoring, and delivering work I have come face-to-face with vast "cultural divides" between adherents to the so called "waterfall" methods for software development and project management (where release cycles are longer and more formal, and result in more massive and sweeping changes as and when releases occur) and those who adhere to Agile methods or "scrums" (where release cycles occur frequently--often less than monthly--and result in ongoing incremental changes to code, documentation, and systems).
A colleague and occasional collaborator, Steven J. Vaughn-Nichols, has penned an excellent piece for SoftwareQualityConnection.com entitled "Stumbling Towards Agile" that addresses these kinds of issues with insight and humor. He explains the occasional stumbles and roadblocks that crop up in shifting perspectives to Agile from other approaches as deeply cultural, and rooted in developers' (and project managers') experiences and outlooks. He also describes how Agile really requires letting go of long-term (and often illusory) control over the development process in favor of smaller, more realistic, and often more valuable and telling building blocks that result from each individual scrum as it progresses. The final result can be a major boost in quality and customer satisfaction from work accomplished, something that occurs on an ongoing basis in an Agile environment, rather than a more typical "thumb-up/thumbs-down" judgement at the end of longer development cycles.
With the introduction of more formal training and vetting of Agile project managers, I predict that many more organizations will buy into Agile methods and approaches. I'm hopeful that this will make the IT world a better place for all of us!