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.

While working on developing a software development audit method, I faced the necessity to structure software development roles in the form of a simple list to make sure that (1) everyone shares the same understanding of roles and (2) the list can be used to setup user profile in the Agile Benchmark web application.

Remember that roles are not individuals. There is an n-m relationship between roles and individuals.

The short list of software development roles:

• Product manager
• Manager (upper)
• Project manager
• Business analyst
• Software architect
• Developer
• QA/QC/Tester
• Deployment manager
• UX specialist
• Subject matter expert
• User
• Client representative
• Sales representative
• Administrative support
• IT support
• Other stakeholder (anyone else interested in the outcome of the projects)

In my presentation for Agile Tour 2009 in Montreal, I will explore how we can elevate Agile to the business solution level. Agile shines in software development, but should it stop there? I had the opportunity to push Agile beyond its comfort zone.

At first it involved including purchased products, or make-or-buy decisions, in the Agile development process. While doing that, I noticed that we had to separate effort from cost. Originally, work time (or effort) is the only "cost" in Agile. But when we purchase a COTS (component off the shelf) as part of the solution for example, the relationship between cost and effort becomes insufficient. I solved this by attaching to work items a cost tag that is independent from effort. With this simple extension, we elevate Agile from software development level to software solution level.

In subsequent projects, I wanted Agile to encompass the entire project. The project can for example require adjusting business processes, marketing services and products, deploying software products, training people, and yes, developing software. However, work items that do not pertain to software products require more extensions to reflect these characteristics. The demonstration of work done, for example, is not as obvious as for a product feature. The results of non-product work items are less tangible and are sometimes observable only at later iterations. A marketing work item (shown below with a Scrum-style story index card) is a good example. Part of the cost ($3000) does not depend on the effort (50 hours), and part of the demonstration of "done" will only appear in later iterations when feedback can be measured. The capability of taking any value-producing activity into account, and not only product features, brings Agile to the business solution level.

Elevating Agile beyond software development is not just about expanding existing frameworks. It's first and foremost a question of mindset. Indeed still now Agile is used, introduced, and promoted essentially by software developers, who have a bias for diving headfirst into software development and neglect looking at a broader - and better - approach to the solution. Exposing Agile developers to business will expand their view and help elevate Agile to the business solution level.