Developing on Staxmanade

Branch-Per-Feature with Team Foundation Server (TFS) – Part 2 – Kanban Stages…

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.


I don't disagree with the impression that another pass of testing once a branch has been merged could seem a little redundant. However, I think it really depends on your development shop and the context of the work being tested. We have a small shop (5 devs, 0 testers). So each pass of testing done by a different dev is a completely different set of experiences/backgrounds taking a look at a feature under test. In fact we've found the second pass of testing to be extremely valuable and cost effective (finding/fixing bugs before they get deployed).

About the automation part - we run a full automated test suite & integration tests after each check-in to the trunk. However, (in our context -- 6yr old code base - very little code coverage, etc...) automated tests are just not enough to give the confidence that every merge means everything's green.

There are many factors to take into consideration when deciding how your kanban should be setup and all the stages you will need. I'm am certainly not speaking with authority on the subject, just experience (and only a small experience at that). But one of the great parts of this process is it's ability to change when a need is discovered.
Interesting approach. The main issue for me is the merge back into the trunk. You solve that with a 2nd round of testing.

I'm not sure if this is wasteful though. It's definitely needed to check the merge went ok, but it's a lot of inspection.

The developer inspects his code, after working on it. Then a tester inspects it. Then another round of inspection takes place after the merge.

That said, automation would solve a lot of that. The same tests could be re-run quickly (plus a bit of manual testing) to ensure everything was ok.

What we may do in fact, is just have automation tests running constantly on our trunk. Do the merge, and if nothing breaks it's ok. If there were conflicts in merging, then we may do some manually testing around that area.
Have you seen the kanban process template over at codeplex?

I haven't taken a thorough look at the template myself, just know it's out there...
For process template customization, there are some great tips and tricks in this blog post:

I'd really like to see someone develop a Lean/Kanban process template something like the Conchango Scrum template & share it with the community. Maybe even something that integrates with AgileZen or something similar to help visualize the Kanban. Lots of opportunities in this space!
@Jason As far as TFS is concerned my blog title is probably a little misleading... I will have a very TFS centric post coming with the gotcha's and others I've learned while implementing the process. We haven't gone as far as customizing the template or written any specific reports. I have a sql statement that gives a rough estimate of the time it takes for a feature to get through the pipeline, but feels more like a hack than a useful report.

The big thing lacking for us in the tool at this point is the visibility of the kanban. Given time I could probably write a report or something else to display this information, but don't feel my time would best be spent there.

If you have any good tips on how to slowly customize an existing template and morph it into something else, I would like to do things like you state in your comment "remove iterations altogether and replace...".
I like this approach. I'm curious if you've developed any reports around your new template? Have you looked into customizing your process template in such a way that you remove iterations altogether and replace with something like a "Kanban Stage" field?