INDICATOR-DRIVEN DEVELOPMENT

Every morning, the first developper to come in to work starts his day with a coffee. Then he checks the build which was automatically performed during the night.
From the generated build status web page, he collects the indicators measured during the night and writes them on our big indicator chart at today's date.
The big indicator chart shows the indicators measured every night by the automatic build.
At 9h15, the team gathers for the short daily stand-up meeting. Before running the work status, we comment the fresh indicators and detect those which have regressed and decide immediate corrective action.
Among the indicators, we track

• the percentage of code covered by tests to check it remains high;
• the number of functional requirements tested to measure progress and calculate our velocity,
• the number of lines of code in our components to check it doesn't grow awkwardly,
• that the requirement to test and requirement to code traceability matrices contain no errors or empty slots.

As these fresh indicators have an impact on the day's work, we can assert that our developpment is also indicator-driven.