Le blog d'Archiloque

Extreme project management

I’ve spent several years doing audits and other missions and I noticed that many organizations seem to care more about the planning and reporting of projects than about the content of the project (i.e. what the project is supposed to deliver).

My suggestion is to admit it, and have the courage to draw conclusions from it.

My idea is to try what I call “eXtreme Project management”: focus on the project management part of the project, and just drop the other parts.

In a XP management, the project is composed of exactly two tasks:

  1. Planning

  2. Reporting

The same two tasks are recreated for each iteration.

Each project iteration is composed of four parts :

  1. A backlog grooming where you review the project’s backlog, which is composed of the two aforementioned tasks.

  2. A poker planning, where you estimate how long the two tasks should take.

  3. A steering committee, where you share the project’s reports with the stakeholders and you can decide on the next steps.

  4. A retrospective where you can gather feedbacks from the team and try to find improvements for the next iteration.

A typical XP management team should be composed of two person:

  1. A project owner, in charge of creating and updating the project tasks

  2. A scrum master, in charge of managing the Jira workflow and permissions

With an experienced team, an XP management iteration should typically take no more than 3 hours:

  1. Backlog grooming: 15 minutes

  2. Poker planning: 15 minutes

  3. Steering committee preparation: 30 minutes

  4. Steering committee: 60 minutes

  5. Retrospective: 60 minutes (including an ice-breaker)

It means that 10 iterations per week should be a low bound.

As each iteration contains the two same exact tasks, the project should be perfect to apply project management best practices: velocity measurement, burn-down chart analysis, and estimations vs time spend comparisons.

Once an XP management project has been established in an organization, it could be used to challenge other projects. The goal would not be to antagonize the other teams, but to inspire them so they improve themselves.

Unfortunately I’ve stopped doing consulting so I’m not available to help you implement this idea in your org, but if you try to do it I’m curious of any lessons learned you can share.