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.

Whether we're asked to adjust a process, redefine objectives, or restructure a team, the ability to manage changes will serve us better than hard skills in the topic.

I've found Kotter's 8-step change model a good guidance to implement changes. However, I'd like to add two ideas.

Building a case for change can involve both objective and emotional arguments, such as:

• Cost-benefit analysis
• Success stories
• Enable organisation's strategy
• Solve frustrations
• Leverage pride

The ability to make changes also depends on the ability to convince or influence others. In this area, I suggest working at both the group and the individual levels, with appropriate techniques. For example, the people we can convince with a formal presentation are very different from the people we can convince with an informal face-to-face conversation. The message that we want to convey also conditions the technique.

The "techniques" include:

• Formal presentation, larger audience and limited interactions
• Meeting with a few people, open discussion
• Spontaneous face-to-face discussion
• Discussion over lunch or coffee
• Email

It is a good idea to meet with sceptics individually, as it may help to better address their concerns in order to bring them on board. Similarly it's a good idea to include a champion (convinced person) in a meeting with people who are not yet convinced.

Just look back at your own experience to identify a situation when you were able to convince people to buy in your idea. You can guess which techniques were effective. Most of us use these "techniques" unconsciously. Great influencers naturally mix and match the techniques for great results. If you have such a person around you, try learning from him/her – it's the best way to improve this skill. Have also a look at the related topic of stakeholders management.

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.