How Microsoft DevDiv uses TFS - parts 6 (+ addition) and 7

Tracking multiple projects.

Today I am going to show you how our program manager is responsible for managing all projects using TFS, using reports to track changes in several projects at once.
For starters, let me tell you a little about the process itself.
Every week we held meetings of managers, the purpose of which was to check the health of the projects on which we worked.
These meetings were held by Jim Boyle, who was the program manager of our group. He is an excellent program manager with vast experience in monitoring the execution of work.
Every week, Jim showed us a report that looked like this. He displayed all the projects we worked on.
Some clarifications:

• Green - percentage of completed work in relation to the entire project.
• Yellow - percentage of completed work for the last reporting period (usually 1 week).
• Red - the number of hours of upcoming work.
• The end date of work on the functional is accompanied by the name of the executor.

After this report was displayed, Jim started asking questions like these:

• Why is no progress seen over the past week?
• Why is so little done?
• You have only 1450 working hours left, despite the fact that the end date is set for January 3. Do you still think you will meet these deadlines?

Jim did not start banging his fist on the table and asking, “What the hell are you doing nothing?” The data showed a conflict, and he just voiced it.
Here are some answers:

• “I just did not update the data.” Such an answer was not acceptable. After such an answer, verbal flogging began with a reminder of the importance of updating data on time. By the way, this was not done at all by Jim, but by our Product Unit Manager (read - Brian Harry).
• “We were pulled out for other urgent work that week” - this answer was quite acceptable. Although at such meetings there was a change of priorities. In other words, management could understand that this urgent work is not as important as the project as a whole. In such a situation, management had a better idea of ​​the status of the project.
• “If everything goes well and there are no difficulties and problems, I hope we will do everything on time” - here we see how someone is struggling to believe that he can keep the initial date. He does not want to shift the date, because it will not look very good. Basically, the answer was: we need a date by which the work will be done with maximum probability. If you need to move it, we better know about it now than move it later.

You may have noticed that this approach requires a change in culture within the team. Transparency will make you prove yourself. With such a culture of openness, management can take the path of "keeping the completion date at all costs," and the performers must decide whether to show the current status of the project with all openness or to hide the bad news. It was a learning process for both sides.
Gregg boer

Addition.

After the publication of the previous article, I was asked to tell in more detail about the report that I spoke about. I asked a friend who is working on internal reports, and here is his answer (Thanks, Doug!). I also attach the .RDL file that he gave me.
Quote:
“Below is the text of the request, which receives the current volume of completed and pending work for a certain past date (and this date is a parameter). The purpose of using the fields. [All] in our measurement system, which returns the amount of work for a period of N days, is to search for scenarios that have a name, product group, current status, etc. had a different meaning on the indicated date. In fact, we say: give me the volume of completed and pending work for a period of N days, regardless of the filter values ​​for other fields (for example, status, etc.).
WITH
MEMBER [Measures]. [ValueOfCompletedWorkAsOfNDaysAgo] AS
(
[Measures]. [Microsoft_VSTS_Scheduling_CompletedWork],
[Work Item]. [Microsoft_DeveloperDivision_Classifications_Group]. [All],
[Work Item]. [Microsoft_DeveloperDivision_Classifications_Project]. [All],
[Work Item]. [System_Title]. [All],
[Work Item]. [System_State]. [All],
[Work Item]. [Microsoft_DeveloperDivision_Features_RiskLevel]. [All ],
STRTOMEMBER (@MDXDateForWorkCompletedSinceDate)
)
MEMBER [Measures]. [ValueOfRemainingWorkAsOfNDaysAgo] AS
(
[Measures]. [Microsoft_VSTS_Scheduling_RemainingWork],
[Work Item]. [Microsoft_DeveloperDivision_Classifications_Group]. [All],
[Work Item]. [Microsoft_DeveloperDivision_Classifications_Project]. [All ],
[Work Item]. [System_Title]. [All],
[Work Item]. [System_State]. [All],
[Work Item]. [Microsoft_DeveloperDivision_Features_RiskLevel]. [All],
STRTOMEMBER (@MDXDateForWorkCompletedSinceDate)
)
MEMBER [Measures]. [FeatureEndDate] AS
EXTRACT (
NonEmpty (
[Microsoft_DeveloperDivision_Features_DateEnd]. [Date]. [Date] *
[Work Item]. [System_Id] .CurrentMember,
Current [Measures]. Count]
),
[Microsoft_DeveloperDivision_Features_DateEnd]. [Date]
) .Item (0) .Member_Value
SELECT
Non Empty
{
[Measures]. [FeatureEndDate],
[Measures]. [Current Work Item Microsoft_VSTS_Scheduling_CompletedWork],
[Measures]. [Current Work Item Microsoft_VSTS_Scheduling_RemainingWork],
[Measures]. [ValueOfCompletedWorkAsOfNDaysAgo],
[Measures]. [ValueOfRemainingWorkAsOfNDaysAgo]
} ON COLUMNS,
NonEmpty (
STRTOSET (@WorkItemMicrosoftDeveloperDivisionClassificationsGroup, CONSTRAINED) *
STRTOSET (@WorkItemMicrosoftDeveloperDivisionClassificationsProject, CONSTRAINED) *
[Work Item]. [System_Id]. [System_Id] *
[Work Item]. [Microsoft_DeveloperDivision_Features_RiskLevel] . [Microsoft_DeveloperDivision_Features_RiskLevel] *
[Work Item]. [System_Title]. [System_Title],
[Measures]. [Current Work Item Count]
) DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM [Current Work Item]
WHERE
(
[Work Item]. [ System_WorkItemType]. & [Orcas Feature],
STRTOSET (@WorkItemSystemState, CONSTRAINED)
) »

FC-High-Level-Summary-of-Work.rdl

Gregg Boer

Risk tracking

Last time we talked about tracking the progress of several projects at the same time, in this we will talk about tracking risks in these projects.
First of all, let's look at the Progress tab of a Feature record.

In this picture you see two fields related to risks. Risk Level - an indicator of the type of traffic light. Green = we will complete the work on time. Yellow = there are risks. Red = we will not complete the work on time. The second field contains explanatory text.
Each week, the project manager had to check the dates indicated in the record of type Feature and evaluate whether his team could complete the work on the specified dates and then set the Risk Level in accordance with this assessment. If necessary, comments were added to the Risk Comments field.
The result is the following report:

This report was created in Excel, which used a query where Risk Level <> Green. Background color added using Excel itself.
Each week, the team of any project, which itself established itself in a different risk zone than the green ones, had to explain to the rest of the teams how they got to such a life and what they were doing (or should do) to return to the green zone.
If this risk simply reflects changes in the schedule, then it should be installed in the red zone for one week, so that everyone can understand that the schedule was changed, and why it happened, that the end date was updated. Then this risk returns to the green zone.
You might think that the above report resembles a snowfall / ice storm forecast. We in Seattle do not handle snowfalls very well. You may just laugh at it, however, I think that the locals understood me perfectly. :)

How to make this system work?

You may ask: why should someone honestly show their risks as yellow or red? Why not just leave them green? It won't be so hot, will it?
I have two answers to this.
The first. Of course, if the project has problems, the team will have to shift the dates. If suddenly their dates one day shift by 4 weeks without first changing the risks, others may ask: “Why didn’t you know about this before?” Or “If you knew about this before, why didn’t you tell us?”. This helps maintain integrity between teams.
The second is a change in culture. Changing your risk level does not always mean that you were doing something wrong. Very often, risks are beyond your control. However, it is in your power to report status changes. In fact, people were responsible for informing, not for project risks. Of course, if you change your dates very often, someone from the authorities will definitely talk to you.
Next time we’ll talk about how we managed quality gates using this system.