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.

Today is your first day on a consulting mission to assess software development practices. Okay, you have experience, you know a bunch of methodologies, and you are familiar with standards, but what would be your very first actions as a newcomer who doesn't know anyone or anything in this organization?

Tough spot.

Here's a hint: it's all about people.

At first sight it may seem surprising that the success of assessments and audits depends more on the ability to relate with people than on the knowledge of methodologies or standards. Although the later is important, it doesn't matter how good you are at it if you can't create good relationships with people. Indeed, to assess you need information, and to collect information you need people to collaborate with you - willingly.

With this in mind, let's see what steps we can take to start this mission.

Meet with the sponsor to ensure commitment and understand the mission

• Gain understanding of the business objectives behind the assessment.
• Establish the scope of the mission, including what has to be assessed and what will not be assessed.
• Identify the stakeholders and how to access them.
• Agree on the deliverables and on the planning.
• Determine the mission's constraints, such as deadline and costs.
• Summarize the meeting with a document, ideally a project charter.

Pitfalls:

• Don't assume that the description of the mission you received beforehand is accurate, even if it is detailed.
• Be ready to challenge the sponsor's assumptions. The sponsor might have a preconceived idea of the assessment process and even of the result. Kindly remind him that you have been called to perform an independent review, not to find evidence for predefined results.
• Avoid stretching the scope based on what you discover. If the assessment points to issues beyond the scope, report this finding to the sponsor.
• Don't confuse the official organization's structure (titles and functions) with the way people interact in reality (roles, influence, and informal channels of communication). Create your own view of the structure and analyze how stakeholders interact with each other.

Meet with the stakeholders to create a sound foundation for collaboration

You have to defuse resistance. The second you step in, the resistance bomb starts ticking. In order to avoid having to overcome resistance later on, take the initiative to communicate.

• Explain why the assessment has been requested.
• Explain how the assessment will be carried out.
• Emphasize the opportunity for improvement and personal development that the assessment will create.
• Make sure that everyone understands that the assessment's objectives are to improve results, not to evaluate people. All information collected are anonymous.
• Be part of the team. Use "we" and "us", not "I" and "you".
• Handle questions.
• Summarize the meeting with a document and send it to all stakeholders to demonstrate willingness to collaborate and transparency.

Pitfalls:

• Don't base your communication on emails or documents. Written communication is used to prepare (for example to present a meeting's agenda) and to report (for example to summarize a meeting's conclusion), not to create trust or enable collaboration. No amount of documents can replace an in-person kick-off.
• Don't communicate without prior consent from the sponsor. Review the content with him beforehand.
• Don't introduce yourself as being called by executives. It will create suspicion and hinder the collection of information.
• Don't provide too much details. Keep it simple. Provide some additional details when answering questions.

Identify the sources of information required to perform the assessment

• Break down the mission's objective in subgoals in order to list the information you will need, then identify people who can help you with each category of information.
• Focus on people as the primary source of information.
• Contact each person individually to personalize communication and to confirm the person's roles and availability to help with the assessment.
• Ask for help to locate documentation.

Pitfalls:

• Don't trust documentation. Documents are seldom current, and what they describe seldom reflects reality.
• Be wary of people who systematically send you documents to avoid meeting with you in person.
• Don't waste your time parsing the files by yourself to find documentation. Ask stakeholders for help.

Be accessible

• Provide your contact information.
• Set up your office among the team. If you have a separate office, keep the door open.
• Be available.

Pitfalls:

• Don't become overly friendly. It might compromise your objectivity and your credibility.

There is a confusion between the terms audit and assessment. Actually I was confused by these two words until not so long ago, so I figured it might help to shed some light on this ambiguity.

An audit is a process to verify the conformance of an entity to a given standard. It consists in gathering evidence of conformance or nonconformance. Therefore, it results in a success or a failure with regard to the scope of the audit. Verification and inspection are synonyms of audit.

Example of audit: Verify that the project management practices comply with a set of best practices defined by an instance of the Project Management Body of Knowledge (PMBOK).

An assessment, on the other hand, evaluates the efficiency and/or effectiveness of an entity and results in a measure of its performance with regard to the scope of the assessment. The goal of the assessment is to gain understanding in order to formulate a recommendation to improve the entity's situation. Appraisal and evaluation are synonyms of assessment.

Example of assessment: Evaluate the CMMI level of an entity.

Note that both audit and assessment can use the same base material, such as a given project management methodology, but their goal and the way they use the reference material will differ.

We can also distinguish audits from assessments by looking at:

• Attribution: An audit might explicitly point at specific people or groups of people as the cause for noncompliance (attribution). An assessment does not evaluate individuals (non-attribution). Of course, the result of an assessment might still be used to infer responsibility for failure or low scores.
• Fault: Whereas an audit results in a success or a failure (fault), an assessment usually provides a score that does not express success or failure (no-fault). With an assessment, one can freely decide which score constitutes a success or a failure if they want to, but this is done to identify the areas that should be improved and not to judge people.

As you can see, the difference doesn't lie only in the goal and in the process, but also in the mindset.

Additionally, we have to mention that the two words audit and assessment generate very different reactions. Audit is associated with distrust and punishment whereas assessment is often seen as an opportunity for improvement. Unfortunately I have personally witnessed audits disguised as assessments. Instead of resulting in a healthy improvement plan the results have been used to blame people and terminate projects.

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!