Professional Documents
Culture Documents
Good Bad
Goal to Plan - Getting down the cycle
Sure, turning the wheel faster would make some things, like
merges, easier.
But without addressing the scope problems, the flow
wouldn't be any better and would continue
to interrupt releases.
Things wouldn't be any more predictable and the whole
cycle would just fall apart (more puddles, less of a stream).
Goal to Plan - Controlling Scope
The pace of the schedule sets the boundaries for the amount
of work that can be completed.
It's important to have specific points in the schedule to
review features and cut scope.
Establish clear expectations (and engineering practice) to
developers that any features not ready to ship at branch will
be disabled (i.e. we only cut post branch, never add).
Plan to Pitch
Reached out to the various cross functional groups on the
Chrome team, who would all be impacted, before
approaching our executives.
Engineering, QA, Product, Marketing, Support,
Localization, Security, etc...
There were a lot of concerns to address, but the exercise
forced a lot of thought on the implications of the schedule
change.
It took time, but it made the pitch easier to present to the
leadership and the rest of the team.
Concerns
Would large feature development still be possible?
We basically wanted to operate more like trains leaving Grand Central Station
(regularly scheduled and always on time), and less like taxis leaving the Bronx
(ad hoc and unpredictable).