Why is Release-per-Feature desirable? This session started with "popping the why stack" on this question. A few ideas we came up with:

1. It's a competitive advantage

2. Bigger ROI, Shorter Payback

3. Flow (pop the why stack on that, too)

4. ?

We then started dealing with the how. A few main topics emerged:

Composite Applications

Features are simply components or modifications to components. We can also turn things on/off. This is important as simply working off the mainline won't cut it anymore. If we release partial features, it's possible that we'll create semantic difficulties or out-and-out defects for users.

Branching Strategies, Distributed CI

Create a branch-per-feature. When a feature is done with development/test we merge back into mainline and deploy from there. There is a "simulator branch" that all feature branches auto-merge into on each commit (or part of the build pipeline). If a merge fails here, we stop the line (Andon) to deal with the merge issues.

We covered the idea that build pipelines (dependent CI builds that take artifacts through a series of work cells) often mimic the layout of your Kanban.

Team Composition

Pooling, feature crews, etc.

#

More coming soon ~ Dave Laribee