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.

Have you already had to collaborate with someone who constantly disagrees with you, or with someone who has the uncanny ability to summon a heated argument out of thin air, or maybe with someone who seems bent on undermining your work? With up to 5% of the population deemed as "difficult people", we’re bound to meet them over and over again. Every workplace has its seven dwarves, and not all of them are as funny at the office as they are in a fairy tale. We can’t just ignore or get rid of them therefore we have to manage them.

Note that this issue applies whether you are in management or not. Top-down authority is overrated and will not help much when dealing with difficult people (the only exception being if you are at the very top).

Compared with other people-related issues, coping with difficult people stands out because the problematic behaviour is not associated with a particular topic or situation, but comes from personality. Since there is not a well-defined problem to solve, traditional conflict resolution techniques are of little help. It’s more like a collection of pervasive, grinding, irritating habits that’s inflicted on close colleagues.

Typical problematic behaviours of difficult people include:

• Aggressiveness, arrogance, condescending, judgmental and opinionated attitude.
• Irrationality: even conventional logic doesn’t get through. There simply is not common ground for discussion.
• Nagging: continuous unasked-for remarks about petty details.
• Stubbornness and excessive pride, leading to the inability to accept comments and to collaborate in a team.
• Playing solo, trying to exclude you of everything they do.
• Trying to get involved in everything you do, acting as supervising your work.
• In contradiction with all of the above, constantly emphasizing the importance of professionalism, communication, flexibility and so on (remember the saying "the wise never says he's wise"), therefore rationalizing their behaviour as being for the good of the team/project/organisation.

You might wonder how these people are still around. First, they behave much smoother when they have a larger audience. Their behaviour is not obvious to casual observation. Second, and perhaps more importantly, their behaviour often borders on professional misconduct but never quite gets there. There is always enough ambiguity in order for an observer to give them the benefit of the doubt. Moreover, their behaviour tends to affect only things that do not leave records, such as discussions and everyday collaboration.

What motivates difficult people? To win. And in order for them to win, people around them have to lose. Whether the stakes are high or the topic is mundane, difficult people are obsessed at being right and proving others wrong.

Next: A manager's perspective

Pages: 1 · 2 · 3

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