These were teams with basic Agile (Scrum & Kanban) training and been using TFS only as source code repository in the past. Developers had been specialized in each of their own applications and were about to start pooling together to form a more collaborate force. So no branching (and merging), no work items, no work item association at check-in, and of course no standard build and deploy processes and environments yet. What a exciting journey this will be!

“The main thing is to keep the main thing the main thing”      ~ Stephen Covey

I want to keep the interest of early adopters by keeping the system stable and up-to-date. In the meantime, seeing is beleiving. It helps to have environments for me to demo and POC some ideas for my potential users. Then it will come down to prioritize what goes first with limited resources and time. Few important things for me and the teams are

  • A healthy and up-to-date TFS environment
  • Provide custom solutions which also aleign with industry trends and new technology
  • Evangelize and POC for potential proposal

However, business priority overrules technology came to the equation when trying to prioritize the implementation tasks. Furthermore, those priorities changed dynamically as well. This challenge is pretty common in many companies for IT department. The only difference in my case is that now the IT teams are the end users for me while I am also part of IT too.

So we did the upgrade from TFS 2013 to TFS 2015 after applying few updates for TFS 2013. The goal is to keep the system current. Interestingly, the side benefit of the multiple smooth upgrades also helped me gain some trust gradually. There were some big database schema changes between 2015 and 2013 followed by additional changes in TFS 2015 Update 1 & 2. Application layer wise, Release Management is fully integrated into TWA (TFS Web Access) now, TFS extension market place is available, and more supported custom widgets are possible starting in Update 3 now.

To gain more buy-in, I explorerd and eventually customize two version of Work Item card printing solution for some teams using physical boards on the walls with sticky notes. The organizational culture is not too exciting about new technology and changes. So for those teams finally took the leap of faith by jumping on new Agile practice and set up boards on the wall few months ago, printing out cards is a most acceptable step because “moving cards” was what they were trained for Agile. I did get sidetracked on some customization and support for this printing effort. But during the processes, I also got to know more teams’ unique requirements and the chance to show-and-tell some TFS features.

As more and more data moved into TFS from various traditional tracking means i.e., sticky notes, Excel spreadsheets, SharePoint lists, etc. along with improved and more friendly TWA, department head finally agreed to go electronic and move all boards to TFS if we can solve some of his concerns and requirements.

  • Can TFS report departmental work loads, trends, unexpected activitiesetc. to help explaining the delivery to business users
  • Each team has their own unique flows of running the boards. Would it be too much customization for future maintenance. Some of the teams suffered from painful upgrades caused by customization in the past and very sensitive about it.
  • Can TFS boards be flexible enough to fit different teams special needs?
  • Can his teams do this without affecting other more established teams?

Fortunately, we moved on to get everyone on TFS boards for thess multidiscipline teams.

Priority shifted in the middle of the board migration project. Some Dev team members got excited about what TFS can do and promised business users that TFS build service can solve their worsen code delivery issues caused by human mistakes. While TFS does provide the integration and automation, there are definitely more factors to consider when implementing an automated CI.

Branching & Merging

This is not a huge development team but most of the members do not have experience with branching and merging. So we start from scratch to gather current processes, pain points, workspace setup, and needs and wants.

Standardize build processes

From setting up build service (I also noted more details about how to decide the right build service) and cleanup some library referencing errors, standardize output files to manage config files.

Release Management

Not only the development team was doing the deployment in Production, The developer who changed the code is actually the one deploy the code to production. Because of this, deployment approval has to be carefully managed.


Prevent human errors like partial check-in, manual steps, and inconsist deployment flows were the original reasons for this initiative. So we do the work item association at check-in, label them by external ticket ID which is the system for Change Management so both developers and business users can clearly see the details for the delivery from TWA widgets.


It is so great to partner with a reputable PM when rolling out TFS boards. We are basically doing both Agile process refreshment and TFS training at the same time. In addition, we also collect valuable user feedback during the roll-out training for both board Admin and users.


For some of the teams have been using other computer systems like Excel, SharePoint and other 3rd-party ticketing systems, it is just making more sense to help them migrating their records into TFS.


Now that data are all set to go into TFS, we are ready to process them and get it out in a more meaningful ways. As far as tools go, there are some options being discussed.


Priority shifted again here as one might expect. Management is thinking about using different ticketing system for Change Management. Although it is still in its early stage, our leader wants us to prepare the integration between TFS and the new CM system. The goal is reduce the redundent data entry overhead between systems. I decide to use Web Hook as the service hook on the TFS side and is currently exploring to subscribe the other side’s web service.