Branch-Per-Feature with Team Foundation Server (TFS) Series Links

1. How we got here…


2. Kanban Stages


3. Lessons Learned

In the previous post (“How we got here”) I provided a small intro into why and how my team arrived at a Branch-Per-Feature/Kanban development lifecycle.

In this post I’ll describe each stage of our current development lifecycle.

1. Triage – Initial drop point for most features.
   • I say most because some head straight into other steps further along in the pipeline.
   • Items are categorized by area or department (These map to an actual TFS Area)
     EX: Infrastructure, Operations, Billing, Client Services, etc…
   • Items are prioritized.
     Each department head & higher gets the opportunity to prioritize within each Area.
   • The WIP in Triage is basically N/A.
2. Backlog – Items in the Backlog have been deemed important enough to begin their life in the pipeline and start being pulled through each stage.
   • These items need extra research, design, and requirements gathering.
   • This is where items that were priority #1 in their respective Area go head to head with the #1’s in other Areas and can be further prioritized.
   • We try to keep the WIP in the Backlog to about 10 or less.
3. Queue – Items in the Queue are items that have no further design/requirements gathering needed and when a developer is ready can pull an item straight into development.
   • We keep the WIP in the Queue to about 7 or less.
4. Development
   • When the developer pulls an item from the Queue into development we create a branch in a Branches folder and give it a name related to the feature being developed. All development for the feature is done in this branch.
   • In our current workflow, after the development of the feature is complete, the developer does a first pass of testing. (We have a fairly small shop, where all of the developers are testers and all of the testers are developers.)
   • When the developer is done testing the feature is (pushed) into Tester Pass 1. (this is part of why I stated above we have a semi-kanban & not a true pull based kanban)
   • IMPORTANT NOTE: frequently forward merge from the trunk into the branch this helps to avoid issues later, and is a requirement before the next stage (testing).
5. Tester Pass 1
   • A different person from the implementing developer needs to be brought up to speed as to what the feature is and the needed changes to accomplish the feature.
   • The tester here pounds away at the changes and gives feedback to the original developer of any issues/changes that may need to be made.
     

   TFS Hint: When I become Tester 1 for a feature, one trick I use is to “pretend merge” the branch back into the trunk. I say pretend merge because I take all the normal steps to merge into the trunk up until the check-in part. I do this so I can see all the changed files easily and can diff each file with the trunk to find the exact source code changes. After a visual code review is complete I undo any changes and begin testing the branch.

6. User Acceptance – Before we merge the feature into the trunk, we do a review with the customer.
   • This allows us to get solid feedback before it gets merged into the trunk, one more testing pass, and deployed to production. This way we DON’T get feedback like “this is not what I need because it needs to do/be like…“ (after it’s been deployed) and instead get more of a “could you tweak it to be like…” which allows us to deliver what the customer actually needs and not what we interpreted the design to be.
   • Also since it’s not merged into the trunk, any changes requests as a result of the User Acceptance review allow us to take our time to get the change done right and not feel like we have to hurry the feature to catch the week’s deployment. We are able to correctly make the changes, and we can usually communicate to the user at the meeting what changes to the system mean, (if we change Feature A and add/remove/change how it operates it may not end up shipping in the next scheduled deployment (or next etc…))
7. Merge Into Trunk - original developer is now responsible for merging the feature branch back into the trunk.
   • If the changes made in the branch are more system-wide or architectural in nature, we will pair on complicated merges.
   • There is usually some coordination that may need to happen before a merge can be done. We don’t want to merge a new feature into the trunk when we’re creating a deployment snapshot and anything else that may determine we hold off on merging the feature.
8. Tester Pass 2
   • After merging the new feature into the trunk is complete we have one more tester take a shot testing the newly merged features. We added this step to the kanban to help reduce potential regression bugs and help keep the quality band high before the feature was marked as done and queued for deployment.
9. Deployment – After all testing and user acceptance is complete the feature is moved to Deployment.
   • This step is only to keep track of what is queued up for the next deployment cycle.
     

   When we started this new process, we attempted to deploy each feature as soon as it became available. This caused some issues, in part related to source control management and timing of pending Merges; however, the biggest issue revolved around deployment and interruption to the users. When we deployed once every 4-6 weeks with our old process, this wasn’t much of a problem for the users. However, deploying whenever a feature was ready caused some issues with our users. We settled on a weekly deployment (same day and time every week), if there is something to be deployed it’s now on a regular schedule.
   

   One other benefit of deploying on a regular weekly schedule is the cadence the team has adjusted to. There’s less confusion around “are we deploying today, tomorrow” etc… With deployments scheduled for a regular cadence, it’s much easier for us to create a process that is consistent, efficient and less error prone.

10. Completed - After the deployment is complete the task is moved to Completed and considered DONE!

Below is a screen shot of how it looks in our TFS work item view.

Yes, we hacked and crammed our kanban into the MSF-Agile template, and although it’s rough, it’s working better than our previous non-kanban ways.

To move a feature though the kanban we select it in the “iteration path” drop down.