Project Tracking Why and How to Do It. The Dilbert View.

Project Tracking

Why and How to Do It

The Dilbert View

Example: Governance of Agile Projects

• Problem: – PMs usually supervise multiple projects

simultaneously, cannot dive into the details of each project, but are expected to keep all projects on track by identifying and resolving issues as they arise.

– How to reconcile agile principles – including whole, self-organizing teams – with enabling proper governance?

Example: Governance of Agile Projects - 2

• Example: – large-scale, enterprise-critical system, intended

to be used by a large and varied user population developed for the Israeli Air Force.

– the project’s leadership defined a set of metrics. The formal role of tracker was established in the team, as responsible for the quality and continuity of measurement.

Example: Governance of Agile Projects – Event 1

• Monitoring: – Burn down is a well-known metric used to measure

a team’s progress towards commitments made to the customer during the planning stage.

– Risk addressed: team gets bogged down in perfecting project details, and misses major deadlines/deliverables.

– Project was divided into 2 month releases

– Each release was assigned resources and deliverables.


• Alarm raised at week 4


• Root cause analysis: – a gap in a burn down chart can mean that the

team is not delivering as fast as expected, or that there was a significant estimation error.

– an this case, it was a combination of both: • the team was still evolving the development and

build environments, and inefficiencies still existed;

• some of the high-level commitments which were assumed (and estimated) as simple experienced feature creep during the release.


• Control response: – get help from senior engineers from other

projects about the development environment – reevaluate some of the new feature requests

with the customer

• Result: – these combined actions had the impact of

reducing the remaining work to within the available resources within two weeks


• Monitoring: – The pulse metric monitored the number of code

check-ins per day.– Risk addressed: people sticking to their old

habits of coding on a private branch and integrating with the rest of the team only late and when a delivery is due .


• Alarm raised regarding the automated acceptance tests.


• Root cause analysis: – one person was writing acceptance tests in the

team, and was doing the majority of that work in the last two work days of each iteration, with check-ins happening on the very last day.


• Control response: – fight for more testers – train some developers to write acceptance tests – allocate tasks in the next iteration to complete the

testing of new features – these tasks received priority not only by the team

but also the customer, who is present when metrics are discussed and shares the interest of maintaining a fully tested code base

• Result: – Major leap in automated test productivity


• Monitoring: – The product size metric is measured as the size

of the automated acceptance test suite.– Risk addressed: not producing a customer-

ready deliverable at the end of every iteration.– This metric was intended to send several

messages to the project team: Only tested features count, only customer facing features count, and only integrated code counts.


• Alarm raised at iteration 2.3


• Root cause analysis: – the reason for this decline was the team’s

dependency on one high performing tester, who wrote, maintained, and ran a majority of the team’s acceptance tests.

– in the middle of iteration 2.3, this person was reallocated to help with an emergency in another project


• Control response: – remove the team’s dependency on one tester – the team invested in getting trained on writing

and running tests– developers and business analysts committed to

write, maintain and run acceptance tests

• Result: – by the next iteration they had fully recovered

What is the Point?

• We track projects so that we can control them!

That is why we have Gantt charts, WBSs, budgets, etc.

The tracking mechanisms must be objective, supported by data.

This is the PM's most important activity.

The Dilbert View - II

Project Tracking Why and How to Do It. The Dilbert View.

Documents

Transcript of Project Tracking Why and How to Do It. The Dilbert View.