It is now 10 years this month that I started work with Microsoft in the Team Foundation Server product unit. In my first week I was given the specification for the tracking software and asked to review it. On the 4th day I went to my boss, Keith Rowe and told him, "this product isn't designed to work the way real software teams work. Real teams do not adopt prescribed, defined processes wholesale on a single day, instead they adopt practices incrementally and their process evolves." The issue was with the mechanism for loading a process definition and a set of work item type definitions for TFS to track. It had to be done at the start of a project. Once loaded the project would use the same set of work item definitions, they couldn't be changed mid-project. Mechanisms like this act as an impediment to process improvement. This problem isn't unique to Team Foundation Server, it is common across many of the popular work tracking products.
The reason work tracking software works the way it does, with very static work type state transition definitions, is that firstly, the product managers specifying these products don't have to use them in the way that developers, analysts, architects and testers have to use them, and they don't have to manage software development teams adopting process changes. And secondly, building a flexible tool that enables work type state changes to be modified on-the-fly is actually quite hard. Visualizing the change is trivial but what do you do with all the existing data? What do you do with work items in-progress? These work items need to transition through a new set of states from that envisaged when the work item was created. And how do you handle metrics reporting when the state transition model changed during the time period to be displayed in the chart or graph?
Kanban tools such as Kanbanize and SwiftKanban were designed and architected from the ground up to handle this problem. Kanban tools were designed to facilitate evolutionary process improvement and to do so gracefully.
When clients engage with my firm as consultants, or attend our LeanKanban certified training classes, they are implicitly saying they wish to adopt the Kanban Method for managing their creative knowledge work services such as software development. In doing so, they are saying they believe in an evolutionary approach to improvement but often they are using a work tracking product that does not facilitate evoltionary changes and for cost or political reasons they are loathe to switch. A failure to adopt a proper Kanban tool that is engineered to remove impediments to change will have the effect you might anticipate - the existing software creates inertia and becomes an impediment to successful Kanban adoption.
It gets worse! Typical tracking software does not produce the metrics that are required to manage with Kanban. The popular JIRA product doesn't even produce time phased metrics by default. You can choose to export data into Excel and MiniTab to produce a lead time histogram or a cumulative flow diagram. Alternatively you can use the API and write code. At least TFS can do most of this natively.
With some clients they quickly adopt a two mode approach where they have physical boards as well as their existing tracking software. The physical boards evolve and quickly the process in use does not match the process definition in the tool. This creates further problems - when to update the tool and when simply to move a ticket on a physical board? And meanwhile, metrics gathering now has to be manual.
If you are serious about managing your creative knowledge worker businesses better, if you are serious about enabling evolutionary improvements to enable better fitness for purpose and better customer satisfaction, then you have to invest in a proper Kanban software product. You have to make the investment to switch tools. Do not be distracted by the "Kanban" offerings from your existing tool vendor. The Kanban template for TFS is a good start for a team that has no process and wants to try a kanban system but the underlying architecture hasn't changed. TFS with thhe Kanban process template isn't a tool that facilitates evolutionary improvement. Neither is JiraAgile. Too many tool vendors thought that Kanban was about providing better visualization. They didn't architect their products to enable evolutionary improvement. Only the true Kanban software products made by people who were an active part of our community over the past 5 to 7 years, are actually designed to do Kanban properly.
So ask yourself, are we truly serious about improvement and about continuted fitness for purpose and excellent customer service? If you are, then do yourself a favor and get a proper tool to enable you to succeed. If you are not prepared to adopt a proper tool, ask yourself again, are we really serious about improvement and better customer service, or is all this activity just a smokescreen of pretense?