Last update: 03-12-2020 19:54

Steerco — Comité de pilotage

Steering committee — Comité de pilotage. Un comité consultatif généralement composé des parties prenantes (stakeholders) et/ou d'experts de haut niveau qui fournissent des conseils sur des questions clés telles que la politique et les objectifs de l'entreprise, le contrôle budgétaire, la stratégie de marketing, l'affectation des ressources et les décisions impliquant des dépenses importantes.

Articuler et maintenir des objectifs à grande échelle est l'une des tâches des cadres qui parrainent ou supervisent les équipes XP. Un autre travail pour les cadres qui parrainent ou supervisent des équipes XP consiste à surveiller, encourager et faciliter l'amélioration. Comme l'objectif d'XP est de faire du développement de logiciels exceptionnels la norme, les cadres ont le droit de voir non seulement de bons logiciels venir de l'équipe, mais aussi une amélioration continue. Les cadres sont libres de demander des explications sur n'importe quel aspect d'un projet XP. Les explications doivent avoir un sens. Si elles ne le sont pas, le cadre doit s'attendre à ce que l'équipe réfléchisse et fournisse une explication claire. Les cadres doivent attendre de l'équipe qu'elle fasse preuve d'honnêteté et qu'elle explique clairement les options possibles dans tout processus décisionnel. L'exécutif doit garder du recul face aux problèmes, en se concentrant sur les besoins réels de l'organisation et les exigences du projet, même lorsqu'il est confronté à la nécessité de réduire le champ d'application. Grâce à une communication fréquente et ouverte, lorsqu'une telle décision est nécessaire, l'exécutif dispose déjà des informations nécessaires pour prendre une décision en connaissance de cause

Kent Beck and Cynthia Andres in Extreme Programming Explained

Le texte qui suit est temporaire

%SPONSOR%s are the ones funding a project. They want to know what the project team has already constructed with the money that was spent (and whether the project will remain in its original envelope), what are the difficulties ahead that may jeopardize the good ending of the project (and in which ways they can help). They want to know whether the Business value they have anticipated will materialize at the time they will need it. They want to know these kinds of things in the most accurate way! And the %RT% must provide this to them! That, and nothing more, because we need to avoid over-processing, over-production and inventory (see %LEAN-8%). This is the purpose of the %-STEERCO% (SteerCo), which is a formal link between %IL% and %AL% as the following illustration suggests:

On top of simple reporting, there can be several advantages to organize a real feedback loop in a bi-directional way, which is even better when organized in a systemic way (at all times and integral part of the process). The %AL% itself can also distill useful information to the projects. This is the case when external changes happen and modify the context of the projects, in which cases the %-RT% may need to enter the %RTH%. Such link is present in L(i)VID as sketched below:

The Steerco is a formal link between the IL and AL
The Steerco is a formal link between the IL and AL. Click to enlarge.

Usually, there are 5 topics that must be presented to keep the sponsors informed about the way the project goes:

  1. Progress reported to the current horizon of the %-RT%: the %CYCLE-I%
  2. Budget, according to 5 complementary views:
    1. Allocated
    2. Burned/Actuals
    3. Estimated to complete
    4. Estimated at Completion
    5. Burn rate
  3. Ressources/Staffing
  4. Risks & Issues
  5. Plans for the immediate next phase

Progress: Timeline and Milestones

Ce que les %-SPONSOR%s veulent savoir est essentiellement une indication de tout retard (éventuel) encouru par les %-RT%. Dans la métaphore d'un train de valeur, il n'y a pas de retard : le train part toujours à l'heure et arrive à l'heure également (c'est-à-dire que les %CYCLE-I% et les %SPRINT% ont une durée fixe, 13 semaines pour le cycle et 2 semaines pour l'itération qui s'appliquent aux équipes, mais qui est en fait le cœur de tout le train). Cependant, tout le fret attendu n'arrive pas à destination, comprenez la portée : certains ont été chargés dans le train, d'autres non. C'est le paradigme le plus important des méthodes agiles ! Par conséquent, les progrès doivent être comptés dans le nombre de %FEAT% qui ont atteint leur %FEAT-DOD%.

Back in 2004, Ron Jeffries wrote a great article about a metric leading to Agility. This is the metric L(i)VID recommends: %RTF% (RTF).


Being agile is often a question of being "visual". By being visual we expose our intentions, we make it easier for the others to read us and the information we built to their intention (see %VPM%).

%-SPONSOR%s want to be kept current with the progress of the projects they fund and they automatically convert this progress to a timeline: %"l%where do we stand compared to what we planned%"r% is the question that keeps running through their heads, even if that sounds awry to most agilists.

So why not helping them to build the right image with a prechewed timeline that can be built automatically (see the %COMMANDO% Team for building this for you, with the help of the %PMO% most naturally.

Here is an example of such a (detailed) timeline with an horizon of about 1 month (see %1-MONTH% for more details):

One-Month Timeline example
One-Month Timeline example

Given its level of detail, this timeline may not really suit the needs of the %-SPONSOR%s. If you need a more high-level view, try the 6-month timeline sample, which is demonstrated here below.


What the %-SPONSOR%s want to see is a minimum horizon of 6 months, possibly extended to one year or even more. This clearly conflicts with the %COU%, at least to some extent: everything which is beyond six months is highly uncertain (and should be considered as such); everything that is between now and three months has a growing proportion of uncertainty but high-level plans remain probably valid and applicable.

To be continued


To be continued


Much more important than timeline and milestones is the notion of value (see %VUSI%)! An %RT% is a train full of value, which is transported from the factory to the end-user. End-users are not concerned by timelines, by costs, etc. They want value; they want to hire/buy services and products that will help them do their %JTBDs%! (HERE SEE CLAYTON CHRISTENSEN ABOUT THAT POINT; PROVIDE A CITATION OR TWO)

In our humble opinion, we believe that the %BURN-UP% is one of the best ways to present accrued value in a visual manner:

Illustration of a Burnup chart
An example of a burnup chart putting in close relation the value that was expected vs. the actual value

One must never forget that the burnup chart expected by the %-STEERCO% is about delivered value, not about what the train has built (which is basically waht the previous chart shows), or to put it differently, even if the %-STEERCO% may be interested in seeing what a train has successfully built they value more what the train has delivered!

Illustration of a Burnup chart (delivered value)
An example of a burnup chart that shows the value that has been delivered (big circles vs. big diamonds). The graph that is presented show a situation where the value delivered is about 2 STEERCOs behind compared to what was projected and the situation deteriorates slowly after the second delivery (LIVE)

Budgetary Situation

As said before, the budgetary stuation is often examined from 5 angles (see topics of a steerco meeting):

  1. Allocated
  2. Burned/Actuals
  3. Estimated to complete
  4. Estimated at Completion
  5. Burn rate

You will often come across organizations that count budgets in man days. This is all OK when such organizations face the same real cost for all their resources. The problem is that it is rarely the case, especially in the world of financial services. To this end, consider the following real life story. During a SEPA project, the team that handled the important part of the payments, discovered they were behind schedule. As it is often the case, they decided to hire new personnel, in that case mostly externals due to the urgency of the situation: after all, they got the budget to do that. Consequently, they went to the market trying to hire a number of high-skills individuals for a number of days, people they didn't have to train because of their intrinsic skills in the domain of payments. The bank found such resources from one their preferred suppliers, a big consulting firm. Only after 3 months the team manager realized her budget shrank considerably, which was primararily due to the fact that the real cost of the people who got hired didn't fit the average daily rate calculated by the company. This forced the team manager to fire most of the team in a week time with the foreseeable consequence of losing a lot of knowledge.. L(i)VID has a preference to itemize budget in real money: euros, dollars, ….


This is the annual budget of the %-RT%, plus all extra money that the were consented.


This is the part of the budget that is already spent. In a fix-capacity mode, which is the preferred mode of a %RT% for SAM, the actuals are pretty predictable.

ETC: Estimated To Complete

This is the budget that we feel will be needed to commplete the project (from now 'till the end). Here again, in a fix-capacity mode, it should be fairly easy to estimate the ETC based on the actuals and the Burning Rate.

EAC: Estimated At Completion

After you have summed the Actuals and the Estimated To Complete parts of the budget you obtain the %"l%EAC: Estimated At Completion%"r%. It should be entirely automatic. The EAC is the most important information for %SPONSOR%s, or to turn it differently, this is the info they're after!

Burning Rate

Speed at which the budget is spent. Indication of the possibility to reach the end of the project with the remaining budget giving the present burning rate. Once again, in a fix-capacity mode where (most) resources are allocated to a single train, the burning rate is easily predictable and should not vary much once the train has started.

Global View of the Budgetary Situation

The more such report is automated, the better (it should be linked to %TW% and Project Expences). Here is a sample view of a global Budgetary Situation, completely automated in the Sentanai Project Management tool:

Budgetary Control illustration (source: Sentanai)
Budgetary Control illustration (source: Sentanai)

This view provides also an history that may be very interesting for the project and the %SPONSOR%s.

Resources / Staffing

As the train is supposed to work with dedicated teams having fixed-capacity, obtaining resources should not be too much of a concern. Therefore, almost by nature, resource concerns normally do not reach a %-STEERCO%, which is very much unlike what happens with resources who are shared between multiple projects, all having their own rhythm, and all having possible delays.

Usually the questions of resources do not reach the %-STEERCO% as they can be reported every day during the %SoS%, at which point they must be treated as point of attention or even impediments. It is the responsibility of the %RTE% to bring solutions (not only escalate).

In organizations transitioning to Agile, if the %-RT% paradigm and the %-SoS% cannot solve resource availability issues, it may be interesting to think of setting up a quick meeting such as the %RAM% where all resource demanding parties strive to obtain consensus about the conflicting situations.

In the unlikely event that a problem of resources still reaches the level of the %-STEERCO% in projects handled in asset-mode (understand release train oriented), it means that it is that serious that the train itself could not solve it.

Risks and Issues

To be continued

Plans For The Immediate Next Phase

To be continued

The %-PMO% is of Great Help

The train %PMO% helps prepare the %-STEERCO%. Things like the budget and Risks & Issues can be entirely automated (one of the things the %COMMANDO% can take care of).

An Idea of a Portfolio Information Radiator

Whatever the format can be, there is always some way to make the information visible for the ones who may need it.

For example, in an Insurance company, we have put in place what we called a Portfolio Kanban where all the information Management needed was synthetized:

To be continued


The %-RTE% Leads the %-STEERCO%

The person that chairs the %-STEERCO% is the %RTE%. The %-PMO% is there to assist the %-RTE%.

Don't Do If Not Needed

After some time you may observe that the %-STEERCO% becomes an empty gesture ceremony. This happens when the stakeholders (including of course the %-SPONSOR%s) become imbued with the culture of Agility, participating to the usual ceremonies, understand the importance of the %SYSD%, the %SD%,the %ACCD%, the %I+A%, the %RTPS% etc. having their say at any given time (see also %-RS%).

When this becomes the usual life of a train, all stakeholders are kept current with the rhythm of the train, what goes well, what goes wrong, what is that the train made with the money it got, etc. Less and less formal reporting is needed, at least in terms of meetings. Of course there remains the need to keep track of the official minutes so that the organization can demonstrate compliance with all regulatory constraints.