Why your manager needs CI
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.
I came across this blog today which made a similar point about using CI & Testing to provide feedback that was traditionally supplied by product/project managers acting as status devices:
Project Managing Dev’t
Tools will do a better job than you can. Using the following tools its possible for anybody in the company to readily grasp status:
- A build server with daily/nightly builds
- Automated communication on check-ins of changes (e.g. an email to all of every check-in)
- A project site – basecamp, wiki, sharepoint, etc
- Project mgmt software with bugs and tasks – I love pivotal tracker.
- Automated testing with your build/check-in process so you can see test case coverage.
- Working product – having something bare bones usable so anybody can try it out and see where its really at.
These tools will communicate status more accurately than you, and prevent large time sinks for issue burndowns, bug scrubs, etc. To this day, most business folks don’t realize that development is an extremely complex cognitive task that requires a long ramp-up time to get productive. You should not interrupt a developer in mid-development/bug check-in to get a simple status update that is retrievable from a bazillion sources.
