1. Project Tracking Why and How to Do It

2. The Dilbert View

3. 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?

4. 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.

5. 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.

6. Example: Governance of Agile Projects – Event 1 Alarm raised at week 4

7. Example: Governance of Agile Projects – Event 1 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.

8. Example: Governance of Agile Projects – Event 1 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

9. Example: Governance of Agile Projects – Event 2 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.

10. Example: Governance of Agile Projects – Event 2 Alarm raised regarding the automated acceptance tests.

11. Example: Governance of Agile Projects – Event 2 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.

12. Example: Governance of Agile Projects – Event 2 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

13. Example: Governance of Agile Projects – Event 3 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.

14. Example: Governance of Agile Projects – Event 3 Alarm raised at iteration 2.3

15. Example: Governance of Agile Projects – Event 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

16. Example: Governance of Agile Projects – Event 3 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

17. 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.

18. The Dilbert View - II