Even experience doesn't prevent us from underestimating the effort and the time required to reach an objective.

It all comes down to the definition of "done". Let me illustrate this with a simple example. If I state that "the objective is to implement a new format of project status", most people will assume that once we have a nice template of project status satisfying the needs, the job is done, whereas I expect the project status to be used by the teams, hence a series of tasks for validating, communicating, presenting, and controlling the use of the new project status format. We have a natural bias to focus on (1) analytical work and (2) work than mainly involves ourselves and not others. In other words, we tend to overlook tasks that require collaboration and communication, and more generally how much effort is needed to implement the change in order to reap the benefits.

When estimating how much time and effort are needed, I go through this simple list.

1. Formulate the needs and identify stakeholders. Don't forget to check stakeholders' availability.
2. Validate needs with client
3. Break down into tasks
4. Perform initial analytical tasks (by myself)
5. Adjust deliverables by collaborating with relevant stakeholders
6. Validate final version of deliverables with stakeholders
7. Prepare communication material (ex: PPT, how-to)
8. Publish relevant material
9. Present and promote solution to users
10. Coach users as needed (over specific period of time)
11. Control results, adjust deliverables if necessary
12. Report final results to client

It's like a mini-project, really.

Poor estimates will focus on tasks 3-to-6 and then assume that the work is done. In my experience, in any complex organization the effort for tasks 1-6 seldom exceed 50% of the total effort.

To summarize further the previous list of generic tasks, let's look at the 3 main activities:

1. Initiate (tasks 1-3)
2. Execute (tasks 4-6)
3. Implement (tasks 7-12)

The main effort consists in implementing the solution, i.e. making sure "users" use the solution as intended, without any need for supervision. In this light, we understand that any "small" change, to a process for example, triggers several tasks that go far beyond changing the process in itself. There are actually two dimensions of complexity in any change: analytical and organizational. To me, the organizational dimension is by far the hardest to handle because it involves stakeholders whose reactions (and resistance) is difficult to anticipate.

Many organizations are plagued by half-baked initiatives, things that have been started but never properly completed. They incurred most of the costs, but little of the benefits. Unsurprisingly, it's usually the implementation part that is lacking. Folders of organizations are full of great analyses and recommendations that have not been deployed. Avoid this huge waste: determine what "done" means from day one.

One of the reasons I believe in Agile principles is that it emphasizes what "done" means: it's done when it delivers value to the users. It has been designed primarily for software development but it can be applied to any subject.

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

We will look at a 7-step technique to prioritize a product backlog in order to release a working system in the shortest possible timeframe. This article is presented with a methodology-neutral point of view; it can be used with any Agile-style framework.

Step 1: Describe the target release

The goal of prioritizing the product backlog is to release the desired product as soon as possible. The key here is to define the "desired product". Before even starting the prioritization, every stakeholder has to agree on the the objective of the release. For example, it can be a prototype, a public beta, or a update to an existing commercial version. The characteristics of the release must be expressed in a few lines in the form of benefits or high-level features that deliver value to users and/or clients.

An example for the first private beta of a job searching website would be:

It allows users to search and apply for jobs in the most basic way. It allows recruiters to post a job description and receive applications in the most basic way.

The description makes it clear what features must be included in the release. With "in the most basic way", it also explicitly states that all kinds of features or perks not necessary for these features are to be excluded from the release. Any stakeholder reading this description should be able to prioritize the backlog items.

Step 2: Define the minimal system

If we look at any backlog, we'll notice that it tends to include everything everyone thought might be nice to have. In other words, a lot more than what we want and need for the target release. What we need to do here is to define the minimal system that satisfies the release description. You might be familiar with the categorization of features into "must have", "should have", or "nice to have" (have a look at the MoSCoW prioritization technique). Well, here we want exclusively the "must have" items.

For the remaining steps, we'll only work with the items of the minimal system. We leave the rest for further releases.

Step 3: Even-out the size of backlog items

This step is optional but often comes handy because most of the time the backlog contains items of wildly different sizes (in terms of scope and effort), such as "manage user registration" and "add a date column in the list of jobs". Because it would be hard to compare such items with the simple scale we'll use later, it is useful to split and/or merge items in order to have comparable sizes. To be more specific, it's ok to have items that are (intuitively) 5 times "bigger" than others, but not a hundred times. Typically, many tiny items will refer to related features such as sorting, filtering, adding fields and the like. They can easily be merged based on the functional proximity. An example of resulting item would be "manipulate the list of jobs of a search result". Merged items would become child items or tasks in the new item.

Step 4: Estimate the value of items

For each item of the backlog of the minimal system, we assign a value on a scale of low / medium / high. I suggest keeping the scale simple because it would usually be futile to try to categorize items more precisely. Note that the value refers to the value as defined by the user/client, and does not take into account measures such as return on investment or cost.

Step 5: Merge results from multiple stakeholders

This step is optional but in my experience several people have a say in the definition and prioritization of the minimal system. I suggest that each of these stakeholders performs steps 2-to-4 individually and then get together to compare and merge their results. Indeed I have noticed that this is more efficient than gathering all prioritizing stakeholders to do it from scratch. If you are lucky enough to have only one person responsible for prioritizing the backlog in your project, you can skip this step.

Step 6: Estimate the cost of items

In the same way we estimated the value of items in step 4, now we estimate the cost of items on a similar scale of low / medium / high. Depending on the project, the cost may refer to the development effort or include other components. This categorization should be performed by the people who will actually do the work of implementing the items.

Step 7: Prioritize according to business value

Finally, we prioritize the backlog according to the business value, which is defined as the combination of value (see step 4) and cost (see step 6). Indeed we want to prioritize the delivery of items based on the "best bang for the bucks".

I suggest the following scale:

If you want to quantify the business value, you may for example assign values of 1 to low, 3 to medium, and 5 to high for both value and cost, and then quantify the business value as value divided by cost, as indicated in the "business value" column. The 1/3/5 is a good scale because it usually reflects well the difference in size (both in value and in cost) between items. You can use more detailed scales but you will probably notice that it generates a lot more work for little additional benefit.

After prioritization

Depending on your planning needs, you can for example assign real values to cost, such as a numbers of days of development, and see where it gets you across iterations with your current velocity. It's a good reality check but keep in mind that it's a guesstimate and it's bound to change, so don't over-analyze. Just enough planning is enough planning.