Tuesday, January 10, 2006

Lean Principles for Branching

A recent thread on the scrumdevelopment YahooGroup about "Scrum releases and SCM" got me thinking about a set of "Agile SCM" slides I prepared, one of which tried to apply principles of lean thinking to branching and merging for version control and their relationship to some of the SCM Patterns.

That was using an earlier version of the principles when Tom and Mary had 10 or so of them. Now they've narrowed it doesnt to seven, so I figured I'd take another stab at it:
  1. Eliminate Waste – Eliminate avoidable merge-propagation (multiple maintenance), duplication (long-lived variant branches), and stale code in infrequently synchronized workspaces (partially completed work)

  2. Build Quality In – Maintain codeline integrity with (preferably automated) unit & integration tests and a Codeline Policy to establish a set of invariant conditions that all checkins/commits to the codeline must preserve (e.g., running and passing all the tests :-)

  3. Amplify Learning – Facilitate frequent feedback via frequent/continuous integration and workspace update

  4. Defer Commitment (Decide as late as possible) -- Branch as late as possible! Create a label to take a "snapshot" of where you MIGHT have to branch off from, but don't actually create the branch until parallelism is needed.

  5. Deliver Fast (Deliver as fast as possible) -- complete and commit change-tasks and short-lived branches (such as task-branches, private-branches, and release-prep branches) as early as possible

  6. Respect People (Decide as low as possible) -- let developers reconcile merges and commit their own changes (as opposed to some "dedicated integrator/builder")

  7. Optimize the "Whole" -- when/if branches are created, use the Mainline pattern to maintain a "leaner" and more manageable branching structure


Did I get it right? Did I miss anything?

4 comments:

Robert Cowham said...

Re build quality in I think you should reference test suites, test drive development explicitly as they are probably the biggest drivers to maintaining quality I have seen.

Brad Appleton said...

Good point Robert! I'll go add that right now (many thanks!)

Bob Corrick said...

As worded, 'Eliminate Waste' is something of a catch-all for the other points.

From the Poppendieck link principles of lean thinking, I got the idea to suggest instead 'Add Nothing But Value', as the other side of eliminate waste.

In other words, only add items and labels that are necessary - it's so easy to create "cruft" by adding stuff just in case.

John Carter said...

Use a simple teamwide convention for tag names. eg. a convention like "TAGNAME_ABC_checkin" flags to all others that developer ABC believes the code at that point should compile & run.

Have an automated background process that pulls each _checkin out into a fresh empty directory, compiles for all platforms and product variants, runs a static analysis tool like splint, links and runs the unit tests and any automated functional tests. CPU time is cheap, developer time exhorbitant.

Report the failures to a warm body that will facilitate a return to a clean build in the fastest, productive and blame free manner.