Five agile project management migration tips

A lire sur:  http://www.techrepublic.com/blog/tech-manager/five-agile-project-management-migration-tips/2798

By Rick Freedman, January 14, 2010, 12:49 PM PST

Takeaway: Rick Freedman shares five tips for PMBOK, CMM-style shops considering agile migrations. He also recommends an agile PM book that he says is a must-read.

I’ve written previously about the ideas and philosophies that form the foundation of agile project management. The history of project management, especially as it applies to IT, has resembled a pendulum, swinging from the lax controls and do-it-yourself ethic of the early mainframe “glass room” to the rigorous methodological controls and formal software development life cycles (SDLCs) of Project Management Body of Knowledge (PMBOK), Capability Maturity Model (CMM)-enforced practices. Many IT shops have fought painful ideological and cultural battles to make the transition to disciplined project management; in my career, I’ve seen the Project Management Institute (PMI) certification evolve from an obscure and unknown credential to a virtual requirement for employment in many organizations. We’ve also seen CMM certifications become critical differentiating factors, especially for offshore IT service providers, who have used CMM Level-5 certification as an “assurance factor” to help Global 500 firms feel comfortable outsourcing to far-off partners.
I’ve developed project management offices (PMOs) and project management methodologies for large IT firms and service shops, and I’m a strong advocate of adding these disciplines to the corporate toolkit to improve delivery consistency and process excellence. Now that I’m working with firms to train them in agile methods and to help them migrate to agile, however, I’m finding that these same disciplines that brought such strong benefits in project success rates can also be an impediment to agile adoption. Many firms have committed so completely to PMBOK process flows and CMM best practices that many of the core concepts of agile development, such as “barely sufficient” documentation and change-friendliness, seem like heresy.
In fact, I’ve had people in my Agile Project Management classes tell me that their perception of agile is that the key message is “everything you know about project management is wrong.” While this may in fact be the message of some purists in the agile community, I’m much more of a pragmatist, and my counsel to firms migrating to agile methods is that, not only can agile and traditional project methods co-exist, but in fact, in most organizations and for most projects, a hybrid approach is key to success.

Bridge to agile PM

In her outstanding book Software Project Manager’s Bridge to Agility, Michele Sliger walks readers through the PMBOK and relates agile concepts to the well-known Project Management Institute (PMI) knowledge areas and process areas. Sliger’s key message is that both the agile and traditional project management camps have misconceptions about the ideas and capabilities of the other side. Some PMI-focused PMs and organizations believe that PMI and the PMBOK don’t support agile methods, and that migration to agile automatically means abandoning PMI ideals. Conversely, some agile proponents believe that PMPs are so committed to “predictive” project methods that they can’t become agile. By relating the key practices of traditional PMOs, such as time, cost, and risk management, to agile approaches that address the same requirements in a slightly different way, Sliger demonstrates that the foundation disciplines of project management remain intact as your enterprise becomes agile, and that only some tactics and approaches change. For any enterprise considering migration from PMBOK-style project methods to more agile approaches, Sliger’s book is a must read.

Agile lessons learned

From my experience in the trenches, some of my key lessons learned for PMBOK, CMM-style shops are the following points:

• Sell: Evangelizing the benefits and features of agile methods and ensuring that the sponsorship exists to make this often wrenching and difficult transition are prerequisites. Each of your audiences will need a different sales pitch; managers need to understand that agile teams can plan, that we do estimate, and that we can create a long-term strategic roadmap that gives them the information they need to budget and set expectations (ideas that conflict with agile myths). Development teams need to internalize the leaps in self-direction, creativity, and maturity that working in an agile environment can enable. Many agile teams observe that the expectation of self-direction encourages them to take responsibility and ownership of their commitments, and to develop mature skills like facilitation and negotiation. And PMO managers need to understand that their hard-won battles for discipline and consistency were not in vain.
• Train: A robust training program for all audiences is the next key element of a successful transition to agile. The language is different, the development life-cycle is different, and the foundational philosophies of iterative development, constant customer involvement, minimal project management “ritual,” and change-friendliness must be understood and embraced for the organization to be united and prepared for the evolution ahead.
• Pilot: Many organizations transitioning to agile select specific projects, typically suitable for an agile approach due to their innovative nature and their need to quickly respond to changes in the technical, business, or competitive landscape, and run them as “skunkworks” outside the standard PMO line of command. This allows development teams to quickly sidestep some of the process overhead that often accompanies SDLC-compliant programs, without requiring the organization to change its sanctioned approach without proof that agile works, and is suitable culturally for the company. To give a negative example, I recently worked with a team that is experimenting with agile methods, but is still also required to comply with strict PMO documentation and process requirements. This “double duty” is not a fair test of agile methods and, in fact, dooms agile to fail as it requires even more overhead, such as both burn-down charts and Gantt charts, and both story-driven and task-driven project plans.
• Reflect: Once the team has a few agile projects under its belt, honestly reflect on what was best and worst about these efforts. These retrospectives should focus on the process of delivery and the actual deliverables, and should concentrate on the idea of balance and adaptiveness. Which elements of the existing, PMBOK-compliant methods must stay, because they add real value and also provide the predictability and comfort level management needs? Which agile methods have demonstrated that they can enhance the creativity and self-motivation of the team, and boost the collaborative spirit between the development team and the business sponsors?
• Adapt: Adaptiveness is, in my view, the key to successful agile implementations. In fact, Jim Highsmith, a signatory of the Agile Manifesto and the author of the influential book Agile Project Management, uses the language of “adaptive development” as his core explanatory term for these methods. The agile approach that any enterprise adopts must be adapted to fit the culture, the risk profile, the history, and the preference of all the affected audiences. By experimenting with agile methods in some key “skunkworks” projects, honestly assessing their successes and challenges, and looking for the right mix and balance for your organization, your chances of a successful migration increase substantially.

Just as many firms took a long time to evolve from the “glass house” of mainframe development to the disciplined approaches of SMM and PMI, firms should expect migration to agile to be a process, not an event. Small steps are more easily digested by all audiences, and, although they may not bring the quantum leap in innovativeness and speed that a rapid agile adoption might, they make up for that by being acceptable and comfortable, and by preparing the way for success iteratively and incrementally, and iterative and incremental improvement is what agile methods are all about.