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 boos, Keith Rowe and told him, "this product isn't designed to work the way real software teams work. Real teams do not adopted 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 LeanKit and Swift Kanban 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.