Last week I had the pleasure to present La Gestion de Projets Agile (Agile Project Management), in French, at PMI Montreal chapter. I was impressed that close to 200 people showed up, making it the most popular PMI Montreal event this year so far. The main purpose of the presentation was to explore how PMBOK and Agile can be combined, particularly in large organisations/projects subject to compliance and conformance needs.

Speaking about Agile in a PMI event is bound to trigger some irrational reactions. After all these years Agile has been around, some people still feel the urge to take sides. But overall comments were contructive and I was pleased to meet with many knowledgeable people in the attendance. Agile is a big player now.

Gestion de Projets Agile V1

IT governance is about the stewardship of IT resources on behalf of the stakeholders who expect a return from their investment. It comes from the need that "corporate managers should be working on behalf of shareholders to allocate business resources to their optimum use (Alan Greenspan)."

Governance drives the need for compliance. The compliance requirements can be either internal or external to the organization. Internal compliance requirements refer to a set of rules that the organization defined for itself based on the belief that it will reduce risks and increase performance. For example, an organization could decide that it has to comply with CMMI level 3, in which case it will set this standard as an internal compliance requirement. On the other hand, external compliance requirements are usually imposed by external bodies such as governments. For example, a government can mandate organizations to comply with a set of rules such as Sarbanes-Oxley (SOX).

Ultimately, governance is a top-down approach driven by financial results and reporting. It is supposed to have financial impact and is defined at the corporate level and implemented throughout the lower levels. SOX is an excellent example. The goal of SOX is to ensure the accuracy of financial reports. We might wonder what's the relationship between SOX and IT governance? Given the critical role that IT plays in organizations, it is not difficult to imagine (see Wikipedia: IT controls and the Sarbanes-Oxley Act).

To comply with Sarbanes-Oxley, organizations must understand how the financial reporting process works and must be able to identify the areas where technology plays a critical part. In considering which controls to include in the program, organizations should recognize that IT controls can have a direct or indirect impact on the financial reporting process. For instance, IT application controls that ensure completeness of transactions can be directly related to financial assertions. [...] Application controls are generally aligned with a business process that gives rise to financial reports.
- Wikipedia, Information technology controls

We can ask ourselves how can an organization adopt a structured approach to implement controls in order to comply with regulations such as SOX? To do so, it can rely on popular IT governance frameworks, models, standards, or collections of best practices such as:

• IT Infrastructure Library (ITIL) focuses on services management.
• Control OBjectives for Information and related Technology (COBIT) provides a set of generally accepted information technology control objectives for day-to-day use by business managers and auditors.
• ISO 27001 and ISO 27002 essentially focus on the IT security. ISO 27002 and COBIT complement each other.
• CMMI is a model for process improvements. CMMI-DEV specifically addresses product and service development processes.

However, these IT governance frameworks only describe what should be done to address IT governance needs, in the forms of criteria, objectives, levels, and so on that express compliance requirements. Therefore, organizations have to translate these requirements in practices for their specific context. Real-world implementation includes business processes, technologies, information systems, and so on. One way to help implement the required controls is to rely on product and service development governance methods (also called project governance). The two most popular product and service development methods are Project Management Body of Knowledge (PMBOK) and Projects in Controlled Environments (PRINCE2). PMBOK and Prince2 are widely regarded as standard project management methods, PRINCE2 being used mostly in Western Europe and PMBOK predominantly in North-America.

There is much discussion as to how to transition from the Project Management Body of Knowledge (PMBOK) to Agile or - and that's wiser - how to combine them into a sensible solution.

I just wanted to share links to articles written by Michele Sliger:

Relating PMBOK Practices to Agile Practices - Part 1
Relating PMBOK Practices to Agile Practices - Part 2
Relating PMBOK Practices to Agile Practices - Part 3
Relating PMBOK Practices to Agile Practices - Part 4

Although we can map agile practices to PMBOK processes and activities, it is a futile effort. Indeed the key difference resides in the approach: PMBOK is process-centric whereas agile is people-centric. To give you an idea, topics such as team dynamics and motivation make up only 20 pages of the 300+ page (without appendix) PMBOK guide, and the word "collaboration" appears only twice.

Looking back at the last few years, I can't help but notice that agilists tend to integrate some traditional techniques as they bump into agile limitations, and similarly traditional methodologies progressively embrace agile principles to reap the benefits of agility.

For example, I am currently working on a presentation that helps agilists make the link with non agile stakeholders and management. How can a ScrumMaster answer the questions "how much will this project cost?" or "should we make or buy?" for example. Some might say that this goes beyond the purpose of agile. They are wrong. There is no valid reason to restrict agility to project execution and leave the rest to traditional approaches. Expanding agile practices to bridge these gaps is actually quite straightforward.

Note that the goal is not to agilify the whole organization, but simply to position agile at solution level, and not just at software development level.

Conversely, traditional methodologies are progressively adopting agile principles. Some, like IBM Rational Unified Process (RUP), made the turn years ago to integrate core agile practices. Others, like PMBOK, only pay lip service to Agile and even avoid using the word. Some methodologies produced agile spin-offs, like OpenUP for IBM RUP.

This is all good news for IT professionals and their clients. Indeed the combination of practices, whether traditional or agile, according to the situation at hand, is certainly more constructive than the bickering of righteous traditionalists vs. agile evangelists (yes, agilists can be narrow-minded too).

I expect the convergence of agile and traditional approaches to give rise to a new generation of practices that expand beyond software development and leverage the collaborative effect of agile organization. Actually I'm not only expecting it, but contributing to make it happen.

(I loosely use the word "methodology". It might refer to software development process, project management, organizational paradigm, or whatever stands for "the way we work" in your mind.)

Since a few months I am involved in the development of Agile Benchmark, a web application allowing users to evaluate their development practices against "best practices" from multiple methodologies (Scrum, RUP, OpenUP, PMBOK, Lean), with emphasis on Agile principles.

I believe Agile Benchmark has huge potential, first because there is a strong demand to answer the question "how agile are we?" and second because to my knowledge there is no such tool readily available on the web (yet).

After a lot of hard work (one of the reasons I didn't post these last two months) the beta release is finally out. It's public and it's free, so have a look at it!

Your comments are appreciated!