While working on Agile software development projects, we often hear that we should "avoid writing useless documentation", or "write the minimum amount of documentation".

However, teams usually fail to interpret this principle in the situation at hand. More often than not, the team only produces documentation that is strictly required to deliver the software to production. This is a case of developer myopia.

It's a matter of correctly interpreting the right amount of documentation beyond what seems obvious for developers. In other words, the documentation that should be created is not determined solely by the development team, but also by other stakeholders.

The following needs for documentation can be used as a checklist.

• Users need a user manual.
• Maintenance team needs a document that describes how the product works in order to fix bugs and make it evolve without depending on the team that developed the product.
• Teams developing or maintaining other systems need to know how to interface their systems with the product.
• IT infrastructure team needs to ensure reliable product installation and updates, to understand how to remove, start, restart, and stop the product's services, to implement application security, and to understand the systems and network requirements.
• Controllers and auditors need to assess applicable controls according to internal standards or standards such as ISO, without depending on the development team.

The more complex the organisation, the more diverse stakeholders are.

As you can imagine, it is usually after the development team is disbanded that the lack of appropriate documentation starts causing problems – big problems.

Agile doesn't remove the need for documentation, it helps optimize what documentation should be produced (as little as possible while satisfying the needs) and when (as late as possible).

Interestingly, it brings us to broaden the definition of value – a central Agile concept. If it has to be produced, then it does deliver value. Therefore, value is not just "working software", it's everything that stakeholders need.

Wouldn't it be nice if we could make an educated guess about the Agile potential of an organisation without doing a full scale assessment? Let's look at signs that any observer can notice when spending a few hours in the workplace.

1. Detailed procedures about everything: They assume that there is a reusable recipe for any situation. They ignore that many situations are unique because needs and context change everyday. Procedures and processes are not bad in themselves, detailed directive procedures are.
2. Client out of sight: In some workplaces the client is a kind of abstraction, an entity we contact by email and the occasional meeting. Collaboration is reduced to a few key events such as capturing requirements, reporting at milestones, and validating tests results, without much else in between.
3. Coworkers out of sight: Individual cubicles with high walls, narrow corridors, and the like. Workplace arrangement significantly influences how people behave and collaborate. If it fosters individual, analytic work, don't expect much collaboration beyond the few formal meetings and emails.
4. Meeting mania: A by-product of the other points, meetings are scheduled for any reason. Most of these reasons would be better served by a brief face-to-face discussion. Unnecessary meetings introduce delays (rooms and people are overbooked) and tend to waste the time of many participants.
5. Detailed timesheets: They epitomize the belief that work can be forecast in detail. People consciously or unconsciously alter their behaviour in order for their daily work to fit in timesheets. Note that timesheets are not bad in themselves, detailed timesheets are.
6. Restricted access to internet and to personal email: Security hazard vs. work/collaboration tool. For me the choice is obvious, but apparently not for everyone.

I don't pretend this short list replaces a professional assessment, but it might provide a few hints.

How can we adopt Agile if the organisation seems at odds with Agile prerequisites?

Note that it is highly uncommon for an organisation to be just ripe for Agile. I have yet to see a workplace where Agile practices can be implemented quickly and on a full scale. In most cases, follow these simple guidelines:

• Choose scale: Identify pilot projects, teams, or organisational units
• Choose practices: Determine which Agile practices make sense and implement agile progressively
• Assess added value: Always keep in mind that Agile is not an end in itself. Assess objectively if and where it can add value.

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

Risk management is a critical part of project management. However, in the real world, it's simply not cost-effective to manage risks thoroughly over all aspects of the projects. Similarly, when configuring the project management processes, we have to determine which areas deserve more attention than others. The more risks in a given area, the more controls we need.

When initiating a project, I always thought it would be great if we had some kind of guidelines as to what areas we should focus on based on the characteristics of the project. Indeed if we look at a project management method such as PMBOK, RUP, or Prince2, we notice it's rather exhaustive, if not abstract, compared to our specific needs. The task of customizing the method according to our needs can be daunting. Hence the idea to look at how risks affect different project management areas based on characteristics. More generally, the characteristics typically translate into increased workload, higher occurrence of changes, and of course increased risks.

For example, a project with a large team might require more work in managing communications, schedule, costs, human resources, and execution, while a project with high technical complexity will require special attention to manage quality, schedule and costs.

The following table summarizes my first thoughts on the subject.

* Relatively to team's experience.

Low indicates that the area deserves some specific attention. High indicates that it requires great attention. Otherwise (no indication), the are doesn't deserve any special attention.

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.