Read this article in your language IT | EN | DE | ES

If your an agile developer you have probably heard, in passing at least, about the Feature Crew Model of Project Management and Source Control. Even if the literal phrase has not arisen, the concepts might be those that you have been naturally perfecting your Release Pipeline towards.

What is A Feature Crew?

A feature crew is a small interdisciplinary team responsible for producing a feature.

Teams can range from 2-50 developers often assembled based on Skills related to the feature set which is to be worked during an iteration of the Development Lifecycle.

What is A Feature?

A Feature is a set of Bug Changes, Enhancements, or Refactoring tasks that have a strong enough relationship to be considered as a Group, or Category, of Code Updates.

Designing Feature-Sets are a key task, since the ability to Prune/Add Features to a Release depends on how the changes are bundled.

To offer the required Flexibility of Feature Selection for a small Agile Team, consider the following:

• The larger the feature set, the harder it will be to Design, Develop, Document, Integrate, QA, and Release.
• The more dependencies a feature set contains, the more difficult it will be to stabilize Build Quality on Release
• Larger Feature-Sets are more prone to Re-iteration between Development and Staging since the entire Code Set has to be Modified, Stabilized and Retested if QA finds a bug within any of the Sets requirements.

Practical Example of a Feature Set:

1. Bug #2234 Update input Validation for Application View

2. Enhancement #455 Add new Input Field for Address in Application View

3. Refactor Task Clean up code that handles Validation in Application View

 

Why Group Code Changes into a Feature Set?

Within the Agile Development Lifecycle, all code changes, no matter how minor, should pass through a series of well defined steps:

• Requirements Gathering
• Design
• Development
• Integration
• Quality Assurance
• Documentation
• Promotion

Using the Feature Set Model, an initial estimate can be claimed based on Design/Development complexity. Then, once the Feature Set has been deemed ‘solid’ by the developer, an Integration/QA/Promotion estimate for that Feature Group can be communicated back to the business to solidify Release Estimates.

Pros:

• The business will never guarantee a Feature related to an upcoming release until the developer has stabilized the Design/Implementation
• Release Estimation for completed Feature Sets will be only an estimation of Integration Tasks, as well as QA Time, which tends to be much more predictable that Design/Development Time
• Feature-sets are disconnected from a Specific Release Number, which allows the business to weigh the risk of promoting a Development Stabilized Feature Set
• Stabilizing a QA Environment is really easy if Regression Tests are focused on incremental Bundles of Features. It is simple roll-out/back a Feature Set Bundle without compromising the existing integrity of the Product.

Cons:

• Features with pre-requisites of other Feature Sets are hard to keep track of
• The granularity of How the Feature is Grouped defines the flexibility of Promotion

Why use the Feature Crew Model?

• The business does not ever promise a solution that has not been developed
• Estimates are more accurate since Design/Development Time is usually the most complex
• Allows separation of concerns for Bundled Feature-Set Promotion
• Isolates Development, Main (QA), and Production source actions to a series of clear, role restrictive, Forward/Reverse Integration Steps.
• QA focuses on Regression Testing, not Development Integration Tasks.

The Source Control Model

The following is an example of a Small Agile Team’s Feature Crew Source Model. Each Node within the model represents a Branched Code Base that retains the Forward/Backwards Merge relationships with its Source/Destinations Branches.

• Team-Dev – Team Integration Environment (Stabilize Promotion to QA)
• Feature 0 – Feature Crew Work Branch
• Feature 1 - Feature Crew Work Branch
• …
• Main – Quality Assurance Environment (Stabilize Promotion to Release)
• Maintenance – Release HotFix Environment (Stabilize Release Patches)
• Fix 0 – Hotfix Work Branch
• Fix 1 – Patch Work Branch
• …
• Release – Production Environment (Create MSI, Package for Distribution)

The Maintenance Branch

Often in the real world, Legacy Releases are treated with priority for a business. This makes the Release Pipeline difficult to manage if the TeamDev and Main (QA) Branch, for instance, are have been stabilized for an upcoming release.

Although the Feature Crew Model does not offer Total Coverage in the area of a maintenance release, it does allow an accelerated turn-around. Fixes can be maintained beneath the main Maintenance Trunk, Integration Stabilization and QA both happen in the same environment as well.

This type of Maintenance Pattern does, bottom line, open opportunities for Hotfix code to clobber your existing Business Requirements.

Rule of Thumb for Maintenance Branch:

• If you are accelerating Hotfixes out often, you need to bundle the changes for a new release
• If the code-change covers so many areas that a limited regression test will possibly lower the quality of the application, bundle the changes for a new release

The Feature Crew Life-Cycle

1. The business communicates requirements to Team on a congealing SCRUM-Style Work Item list.  Requirements are sorted by priority Descending
• [example dashboard view]
2. Developers add rough estimates for Design/Development Time to Work Items. *Exclude all other
3. steps of lifecycle from this estimate
4. Team/Business have a meeting to decide how to re-order the Dashboard with Development Specs included.
5. Team groups priority Work Items into Feature Sets in a Feature List
• [Example feature set view]
6. Developers complete Work Items on each feature set over period of estimated time.
• If Feature Set is completed in estimated time, an Integration/QA/Doc Estimate is added to the Stabilized Feature
• If Feature Set is not completed, new development estimate is added.
7. Team/Business have a meeting, focusing on the updated Feature Sets in a Feature List
• If amount of completed Feature Set’s can offer enough quality to Update the Product, the Team/Business commit to a Release Timeline based on Integration/QA/Doc Estimates.
• If there are not enough Stabilized Feature Sets to promote a Better Quality Product, the Team goes back to the development phase.
8. Approved-For-Release Feature Sets are Integrated and Stabilized in the Team-Dev Trunk; this is valid if you have multiple features planed for a single push.
9. Merge task between TeamDev promoting Feature Changes into Main (QA)
10. QA Testing begins on Main Codebase.
• If QA Finds a Feature Set that does not meet ALL of the intended requirements, the ENTIRE FEATURE SET is rolled-out of the Main Trunk. Developers fix issues in the Feature Branch, but do not update Main.
• QA Testing does not stop if a single Feature Set fails validation. This allows the product to claim a Quality which, in many cases, is acceptably better with a known feature bug than a faulty Product.
11. At end of QA Testing, intended Feature-Set-Complete or not,  the business weighs if the Quality of the Build is acceptable.
• If the Build is not acceptable, the release time-line is extended based on an estimate for Feature Fixes
12. Upon Quality Acceptance, Merge task takes place between Main (QA) trunk and the Release Trunk.
13. Setup Engineer works on getting the MSI/ClickOnce/WebSite out the door.

A diagram to explain the process in detail:

Conclusion

The Feature Crew Source Control Model is designed with a few issues in mind:

• Code Isolation
• Build, Development, Test, and Release Tasks should never have knowledge of the other environments of the Development Lifecycle
• Clear Promotion Path
• Promotion from Development to Stage, or Stage to Release is a single Merge task that only a restricted set of user can execute
• Promotion is Associate, Machine, independent
• Forward & Backward Merge Relationships
• Ability to Promote Forward, Backwards using Source Merge Tools
• Unlimited Feature Development
• Features are disconnected from any specific Release.
• The Business can choose which Developed Features it feels can be Integrated based on the Release Timeline.

The clear advantages are that:

• A Business Release Date is not set until the development has already taken place
• Team Integration, QA, and Documentation do not begin until the Solution has been developed and stabilized
• Estimates are broken into two broad groups (Design/Development, and Integration/QA/Documentation) which will increase the accuracy of a the prediction