Why your manager needs CI

From CitconWiki
Revision as of 09:46, 28 June 2010 by Jtf (talk | contribs) (Session notes. Need editing and augmentation.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

What keeps your manager up at night? Fear of not delivering the project on schedule, on budget.

Not a lot of opportunity to do pure agile contract work in Australia: customers want fixed price estimates.

Fixed scope, time, budget. Even thought it doesn't work: knows a team currently on the 40th month of an 18 month project. (Last 10-12 months code & fix, and you can't estimate code & fix.)

Visibility: I can see when the build is broken. Team needs to know I care. Check-ins need to be at least daily.

There was the concern about lack of good ROI models for using the agile approach. Suggested book: The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation.

Political problem: central testing group fighting acceptance test creation on the project. There's a really good set of regression tests that have been built up over the last several years. Problems: (1) nobody is allowed to run the tests but the central group, (2) they run it at the end of the release (no CI). Have been making the case that the acceptance tests are different, they are for new features and are useful during the coding phase. Central testing group still fighting. Can't seem to understand the benefits. They are likely concerned that the acceptance tests threaten their job, so they aren't willing to understand the benefits. Upton Sinclair quote applies: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"

Discussion about risk mitigation. Reference to DeMarco's Slack: by taking preventative action up front we are making the minimum possible time longer but making the likely time shorter. Do you want a 50% chance at 6 months (but high risk of 12+ months) or a 95% chance of 9 months.

"Quality is richness of features" (reference?)

Discussion of the evil of silo incentives. They make the organization work at cross purposes. Silo functions can make their bonus but sabotage the project/company in the process.